Что я должен иметь в виду для рефакторинга огромной кодовой базы?
Как указывает @jcalz в комментарии, метод defaultArguments возвращает либо function, либо string.
В тот момент, когда вы пишете код ...
console.assert(add2(10) === 19);
компилятор совершенно правильно отмечает ошибку, потому что в этот момент вы не знаете, какой из двух возможных типов add2 есть.
Если вы добавите дополнительную проверку типа в свой код, компилятор будет уверен, что вы работаете со значением типа function, и скомпилируется без ошибки.
if (typeof(add2) === 'function')) {
console.assert(add2(10) === 19);
console.assert(add2(10, 7) === 17);
console.assert(isNaN(add2()));
} else {
console.error(add2);
}
9 ответов
Вам также следует взглянуть на статью Майкла Фезерса «Работа с устаревшим кодом»:
Я думаю, что одна из самых важных вещей, которые вы можете сделать, чтобы облегчить это, - это тесты, чтобы убедиться, что все по-прежнему работает после рефакторинга / извлечения в отдельные модули. Добавьте к этому систему непрерывной интеграции, которая запускает ваши тесты, когда вы что-то регистрируете.
18 000 классов действительно движутся к "огромному" концу вещей. Это вызовет у вас определенные проблемы, включая время сборки / компиляции и появление дыма, выходящего из компьютера, когда вы запускаете ide.
Мое первое предположение состоит в том, что с таким большим количеством классов есть много дублирования общих функций и, возможно, неиспользуемые классы или, возможно, даже подсистемы. Я ожидал этого, потому что, когда что-то становится настолько большим, становится все более и более вероятным, что разработчик не знает всю систему или не знает, где находятся эти функции Util, и считает, что проще написать новую. Поиск избыточности для удаления поможет упростить задачу.
Другой возможный источник избыточности - это бесполезно глубокие иерархии классов, или груды бессмысленных интерфейсов (пример - там, где я работаю, есть каталог примерно из 50 классов, большинство из которых> 1000 строк (не мои, не мои!). Каждый из них реализует интерфейс, который является не чем иным, как его собственным методом скелет. Других реализаций этих интерфейсов нет. Все 50 можно без проблем удалить). Есть также те разработчики, которые только что открыли для себя объектно-ориентированный объект и действительно увлечены им - вы знаете тех, единственная конкретная реализация, которая расширяет цепочку из 5 абстрактных классов и 3 интерфейсов.
Наряду с этим я бы попытался взять часть кода (максимум несколько сотен классов) и переместить их в подпроект, который затем я связал бы с основным как jar.
Первое: удачи, она вам понадобится. Это потенциально ОГРОМНАЯ работа, с которой вы столкнулись. Для меня это звучит очень знакомо; Я работал над подобными вещами в прошлом.
Одна вещь, о которой нужно подумать; Прежде чем вы вообще начнете рефакторинг, я бы очень серьезно подумал о создании обширной среды тестирования. Причина в следующем: с хорошими модульными тестами и регрессионными тестами вы можете начать вносить изменения, не слишком беспокоясь о нарушении существующей функциональности. (Тем не менее, всегда есть проблемы, но ...)
Тем не менее: я бы посмотрел на выделение отдельных «вертикальных» срезов функциональности и посмотрел, сможете ли вы написать для них отдельные модульные и интеграционные тесты; как только это будет сделано, я бы начал работать над рефакторингом. Хотя сначала он может быть очень маленьким, просто процесс выделения вертикального фрагмента функциональности и последующего написания кода интеграции и модульного тестирования для него даст вам большой опыт работы с существующей базой кода. И если вам удастся сделать это немного лучше на начальном этапе, то вы намного опередите.
После того, как вы это сделаете, начните рассматривать потенциально более крупные блоки функциональности для рефакторинга. Если невозможно получить чистые блоки функциональности для рефакторинга, я бы начал рассматривать небольшие блоки; если вы можете найти небольшой (иногда ОЧЕНЬ маленький) фрагмент кода для последующего извлечения, модульного тестирования и рефакторинга, вы продвигаетесь вперед. Иногда это может показаться очень-очень медленным прогрессом, и это будет, если у вас действительно большой проект, но вы БУДЕТЕ оставить след.
Но в целом, сначала подумайте о проведении тестов, чтобы подтвердить ожидаемую функциональность. Как только эти тесты будут готовы, вы можете провести рефакторинг с уверенностью (не безупречной, но лучше, чем ничего), что ничего не ломаете. Начните с малого и используйте методы, которые проявляются вне существующей кодовой базы. Это долгая работа, но в конце концов вы ее добьетесь, и кодовая база будет лучше для этого.
Постарайтесь сделать дерево зависимостей как можно более плоским.
Один из хороших способов сделать это - использовать инвертированные зависимости, другой код может зависеть от интерфейса / услуги, но не от поставщика этой услуги. Это нам очень помогло.
Если вы собираетесь извлекать группы классов и превращать их в независимые библиотеки, выберите членов группы и начинают превращать их в единое целое, ограничивая их взаимодействие с внешним миром. Максимально уменьшите зависимости. Когда вы закончите, вытащите эту группу, превратите ее в библиотеку, снова подключите библиотеку и начните с новой группы. Чем больше мусора вы очистите, тем легче понять, что осталось.
На мой взгляд:
- идентифицировать функциональные домены, которые облегчат процесс определения приложений в этом огромном коде base.
, в свою очередь, определяют зависимости между этими приложениями: те, что внизу (которые используются всеми остальными), обычно являются техническими фреймворками или библиотеками.
создают сценарии тестирования (а не единичные -тестирование, слишком много "локализованного" на данном этапе) для выявления важных процессов выполнения и их результатов. Сценарное тестирование больше связано с интеграцией и может также использоваться для нерегрессионного тестирования.
подготовить текущую производственную среду и определить текущие ошибки, потому что параллельные прогоны потребуются, когда вы начнете рефакторинг (чтобы убедиться, что вы все еще сохраняете работоспособность тех же функций), и вы не хотите, чтобы ваши параллельные прогоны были на 100% совместимы (потому что это означало бы, что вы успешно воспроизвели ошибки!)
убедитесь, что вы создали соответствующий рабочий процесс слияния для управления разными ветвями, представляющими разные (и потенциально параллельные) попытки рефакторинга.
Несколько мыслей:
- Ищите общие шаблоны проектирования - попробуйте увидеть, какие классы используются для основной работы, какие из них являются фабриками, какие - фасадами или адаптерами.
- Разделите код на группы классов, которые зависят от состояния приложения или разделяют его.
- Определите, какие классы имеют постоянные объекты, а те, которые сериализованы в / из базы данных (которые должны быть наиболее простыми для изоляции, предоставьте самый чистый транзакционный интерфейс и переносимый между проектами)
Моя идея состоит в том, что после настройки инфраструктуры тестирования вы можете написать инструменты генерации кода для тестовых случаев Если можно сделать абстракцию из общих функций вашего тестового кода, возможно, инструменты статического анализа кода могут быть надстройками помимо инструментов визуализации. Извините, это идея. Я даже не могу назвать инструменты.
Я нахожусь в аналогичном положении с базой кода, над которой я работаю. Очень тесная интеграция между пользовательским интерфейсом Swing и бизнес-логикой. Рефакторинг - это тонкий и трудоемкий проект.
Я настоятельно рекомендую Рефакторинг Мартина Фаулера . Это единственный из обнаруженных мною наиболее важных инструментов, который помог мне улучшить мой подход к работе с дрянной базой кода. Он описывает логичный и простой процесс рефакторинга любого кода. Полезно прочитать это от того, кто делал это много раз.