РЕФАКТОРИНГ – ЭТО НЕ ФАМИЛИЯ
Старайтесь постоянно следить за состоянием кода.
Сколько раз каждый из вас, участвуя в разработке программного обеспечения, мог слышать нечто подобное такому: «работает – не трогай» или «лучшее враг хорошего» и т.п.? А кто из вас сам такое любит постоянно приговаривать?
Итак, я не разделяю уже ставший, к моему сожалению, «классическим» принцип о том, что если что-то работает, то ничего не надо трогать. Вроде все здраво, однако, я бы хотел обратить внимание на следующее.
Если пристальнее рассмотреть этот постулат на фоне процессов разработки программного проекта, то моя практика показывает, что некоторые люди просто скрываются за ним, чтобы не делать продукт, который они производят, еще более лучшим, а в некоторых особо запущенных случаях это может быть прикрытием банальной лени и/или нежелания что-либо делать вообще и даже профессиональной некомпетентности в особо запущенных случаях.
По моим наблюдениям, очень все похоже на то, что все дело просто в сложившейся ментальности человеков, так как они ведут себя по этому вопросу одинаковым раздолбайским образом, как к корпоративному продукту, где они в наемниках, так и к своим собственным проектам, где они считают себя вольными ковбоями.
Практически всегда есть, что можно улучшить. И даже в том случае, если люди понимают это, они выкладывают свой последний козырь – на это у меня нет времени! Тогда я спрашиваю, а на разбор скопившегося говна в коде потом будет время?
Все считают свое время прямо сейчас, а это, как минимум, недальновидно с точки зрения жизненного цикла программного продукта. Сколько будет времени потрачено завтра предпочитается тупо не задумываться. И вот когда в один прекрасный день в программу начинает стучаться новая выгодная функциональность или какое другое улучшение, что мы слышим? От «это слишком долго», до «это невозможно, проще переписать все с нуля». Знакомо? Не обидно за бесцельно прожитые годы? (с)
Программы, которые мы с вами разрабатываем очень похожи на живые организмы. В том плане, что как и последние, если не будут внутри себя постоянно регенирировать живые клетки (код), то будут обречены на процессы старения, распада и в результате полное исчезновение с жестких дисков пользователей.
Мое решение: всегда надо стараться постоянно следить за состоянием кода, начиная от его оформления согласно принятым соглашениям и заканчивая уничтожением зависимостей в нем. Если не знаете с чего начать рабочий день – начните его с проверки и последующим рефакторингом существующего кода!
В заключение, позволю себе процитировать Роберта К.Мартина из его книги «Быстрая разработка программ». Слова в верхнем регистре выделены самим автором.
Настоятельно рекомендуется ВСЕГДА применять процедуру рефакторинга к КАЖДОМУ написанному разработчиком модулю, а также ко ВСЕМ сопровождаемым вами модулям. Затраты времени будут поистине смехотворными по сравнению с теми трудозатратами, которых избежите вы и ваши компаньоны в ближайшем будущем.
Целью рефакторинга является ежедневная «уборка» кода. Не следует допускать накопления беспорядка. Необходимо сохранить возможности для расширения и изменения системы с минимальными усилиями. Во главу угла всегда следует ставить цель, заключающуюся в обеспечении «чистоты» кода.
Автору, имеющему большой опыт работы в качестве программиста, надоели бесконечные стрессы. Все принципы и шаблоны, описанные в этой книге, превращаются в ничто, если код остается неупорядоченным. Поэтому прежде всего стремитесь к достижению «чистоты» исходного кода.
Ссылки:
