Введение
Много слов уже было сказано о разработке и программном коде. Некоторым уже начали приедаться такие слова как: рефакторинг, гибкие методологии, тестирование. Большая часть сообщества смотрит на код через призму идеального мира. При этом основная масса разработчиков не может четко ответить на вопрос: «Когда стоит переписывать код?»
Основная метафора
Хорошая фраза всегда помогает запомнить какие-либо данные. К тому же, в достаточно абстрактных областях человеческого знания, она позволяет быстрее понять суть проблемы и ее решения.
Долго размышляя над проблемами совместного владения огромным количеством кода, казалось, были ясны все проблемы, но не хватало хорошей метафоры, для закрепления мысли. Она появилась внезапно и всем любителям русского рока хорошо знакома: «А не спеть ли мне песню...» (песня группы Чиж и Ко). Сейчас разберемся, почему она очень хорошо подходит к IT-миру.
Системы
Условно разделим все системы на новые и старые. Это разделение принято за основу для упрощения изложения материала. Существует теория сложных систем, но на то она и теория, чтобы описывать системы достаточно точным и нетривиальным языком.
Разделение систем не касается временного признака.
- Новые системы — это системы, с основной массой кода которых знакома большая часть разработчиков;
- Старые системы — это системы, в которых, порой, можно найти бивень мамонта.
Статья в основном касается старых систем, хотя и для новых будет полезна.
Песни мои
Все разработчики системы — поющие птицы. Система — это лесная песня на разные лады, веселая, грустная, быстрая, медленная. Бывает и такое состояние системы, как полная тишина…Обычная ситуация. Разработчику необходимо реализовать некоторый функционал, на основе существующей системы. Существует два противоположных подхода к решению проблемы:
- «Кто же это все написал, это невозможно сопровождать, все переписать!» (Соло);
- «Вот отсюда скопирую код туда, немного подправлю, вставлю пару строк и пойдет» (Базар)
Соло
Каждый разработчик-соловей оказывается, однажды, в таких местах леса, в которых уже давно никто не бывал.
Начинается быстрое переписывание кода, удаление целых классов, рефакторинг всех не понравившихся участков кода. Система становится все стройнее и стройнее, но «петь» в этой системе может только один исполнитель. Все остальные разработчики уже не смогут быстро войти в нужный поток. При этом возможно появление признаков нестабильности и разрушения системы…
Базар
Каждый разработчик-соловей оказывается, однажды, в таких местах леса, в которых бывают все и очень часто, он тоже не желает здесь надолго задерживаться.
Для таких мест характерно множественное копирование одних и тех же участков кода, огромные методы и функции по 1000 строк и более. Разобраться в общей логике новичку не представляется возможным, поэтому он быстро вставляет еще пару строк в огромный метод и ретируется на другую задачу.
Разработчики, знакомые с системой с пеленок, прекрасно знают, где находится нужное ветвление в методе-гиганте, все остальные никогда не достигнут таких высот.
Музыка
Слаженные действия всех разработчиков. Идеальная система, всемирно признанный «музыкальный» шедевр. Обычно не достижим.
Система имеет четкую структуру, идеальную декомпозицию, простые методы. Любой новый разработчик быстро понимает основы функционирования кода.
Мыслей, что то исправлять в окружающем коде даже не возникает.
Когда же стоит переписывать...
Не стоит говорить о гибких методологиях. Они просто не работают на проектах с 15-и летней историей, десятками тысяч классов. Переписать все это абсолютно невозможно.
Всем известно, что энтропия любой системы возрастает, что неумолимо ведет ее к разрушению. Любая система, когда то, закончит свое существование. Она может стать ненужной, может развалиться от обилия разрозненного функционала, может проиграть в конкурентной борьбе технологий.
Но всегда стоит помнить, что увеличение энтропии можно замедлить. Для этого нельзя вносить гигантские правки в уже устоявшуюся систему. Если возникает такое желание, может, стоит написать новую? Можно и нужно, при внесении дополнительного функционала, модифицировать код отдельных частей системы для упрощения восприятия (необходимо помнить, что «старожилы» могут запросто потеряться в новом коде, нужно оставлять «хлебные крошки»). Никогда не создавать новый функционал, внося дополнения в уже существующие методы, он достоин быть замеченным в новых участках кода.
Заключение
Много раз встречался с ситуацией, когда, измененный до неузнаваемости, код выглядел идеально. Но при этом основной идеолог и разработчик базового функционала просто терялся в нем, ему требовалось время на разбор кода. Поэтому переписывание кода можно признать плохой практикой. Уменьшайте энтропию и пишите новые системы!
Послесловие
Если слушать песню и размышлять о разработке, то приходит на память множество интересных моментов из практики разработки программного обеспечения.
