Программирование в режиме постоянного рефакторинга
Для чего нужно программирование в режиме постоянного рефакторинга? Очевидно, не для того чтобы задокументировать код. И не только для того, чтобы улучшать код - это цель ревью и "обычного" рефакторинга. Главную мысль можно выразить в одном предложении: "думайте о проектировании только над готовым кодом".
Основной порядок действий
-5. Забудьте о планировании.
-4. Выберите одно внешнее требование к итоговому коду - конктракт, юнит-тест, пользовательскую ситуацию (user case), ТЗ или просто часть своего видения итогового кода.
-3. Пишете код. Пишите в один метод. Не нарушайте хороший стиль программирования. Пока не нарушаете - пишите в один метод думая лишь об итоговом требовании. Помните, что код должен всегда сохранять рабочее состояние, потому компилируйте как можно чаще.
-2. Этот этап наступает тогда, когда вам захотелось нарушить стиль. Например, скопировать код вместо выделения его в метод. Прекращаем писать функцию и идём к следующему этапу.
-1. Теперь у вас есть код длинной порядка 50 строк который пока пытается реализовать требуемую функциональность. Вы уже увидели большинство библиотек которые будете использовать. Имеется заготовка структуры данных и, даже, заготовка структуры взаимодействия кода. Вот теперь настало время проектирования.
0. Проектируйте опираясь на имеющийся у вас код. Если он вам не нравится и у вас есть время - что ж, выкиньте его и возвращайтесь к началу. В противном случае, расскидайте имеющийся код по классам, методам и функциям. Не пишите заготовок. В процессе раскидования инспектируйте код. Вы знаете что искать - при раскидывании код перестает выполнятся в одной последовательности и каждый метод может произвольно вызываться и комбинироваться с другими методами.
1. Продолжите написание кода.
2. Если вы видете, что в классе должен присутсвовать определенный метод - добавляйте только если код короткий. Длинный код пишите в текущем методе и переносите после написания. Относитесь к такому коду как к коду на этапе №0.
3. Закончив с реализацией требования, проведите рефакторинг кода. Вы можете опираться на текущие требования и на свое видение последующих, но не пишете код специально под реализацию будущих требований - только под текущие. На этом этапе также проводится тестирование написанного кода.
4. Выберете ещё одно требование и перейдите к этапу №1.
Что означают слова "хороший стиль программирования"?
Означают стиль удобный для рефакторинга кода. Главное цель подобного стиля - сделать так, чтобы строчка кода была минимальным размером изменений. Вот пример правил для подобного стиля:
Распологать операторы на отдельных строчках не надо. Если вы часто исправляете операторы в своих выражениях - стоит задуматься: "А не выделить ли это в отдельный метод?".
Но имеет смысл давать отдельные строчки для длинных параметров функций. Воспринимайте такой параметр как будущий метод.
Пустые линии ограждают кусок кода который может быть методом. Если вы хотите хотите выделить код в метод, но не успеваете сделать это сейчас - просто выделите его пустыми линиями.
Ограничте использование комментариев. Используйте имена переменных и методов для описания логики работы программы где только можно. Помните что комментарии устаревают, а при вечном путешествии блоков кода автоматически не меняются. Чуть ли не единственные "живучие места" - это пространнство перед определением класса, где записывается его функция, а также, комментарии записанные в одну строчку с комментируемым кодом. Если требуется прокоментировать не строчку, а блок кода - создайте новый метод.
Фиксирование документации
Вряд ли, при таком пренебрежении комментариями и постоянных перемещениях кода вы сможете написать подробную документацию до уровня аргументов методов и, следовательно, сделать релиз кода. Это не означает, что библиотеки нельзя писать в режиме постоянного рефакторинга. Это лишь означает, что при интеграции код должен быть просмотрен еще раз и задокументирован. Такой просмотр является смертью постоянного рефакторинга и для того, чтобы вернуться к нему вам придется выкинуть всю документацию приложенную к коду, оставив только контракт модуля кода.
Если вы делаете это, то цикл жизни кода выглядит так:
0. Получение кода для изменения и приведение его в правильный вид (вырезание комментариев).
1. Проектирование, реализация и тестирование кода в режиме постоянного рефакторинга.
2. Документирование нового кода и его сдача.
Возможно, удаление и написание вновь документации кажется вам слишком обременительным. Это может быть повод не возвращать код в режим постоянного рефакторинга. С другой стороны, это может быть сигнлом к разделению модуля на более мелки части.