StasyakOFF Blog

Как долго мы будем сопровождать этот код? - этот вопрос встречается в каждом code review...

Этот вопрос вызывает у меня аллергию. Это часто происходит когда Разработчик А хочет добавить нетривиальный компонент, а в комнате (или в code review) находится Разработчик Б, который выразит озабоченность в сопровождаемости этого кода.

Что понимается под сопровождаемостью? Например, сможет ли новый разработчик понять код просто прочитав его? Т.е. читабельность кода можно рассматривать как важную составляющую сопровождаемости. Но чаще всего рассматривают такие составляющие сопровождаемости как расширяемость, абстрактность, а также интуитивность высокоуровнего дизайна или архитектуры.

Все эти элементы сопровождаемости приводят к недопониманию среди программистов - зачем мы делаем программное обеспечение! Программное обеспечение необходимо для удовлетворения бизнес-потребностей, для добавления бизнесу ценности и, в конце концов, увеличения дохода. Поэтому давайте не будем впустую тратить время на бесполезные дискуссии и разберем что же влияет на сопровождаемость.

Расширяемость

Если обсуждение расширяемости заставляет нас погрузиться в дебри абстрактных паттернов проектирования и языка, то сделайте шаг назад и попытайтесь понять что вас действительно беспокоит. Возможно это связано с размышлениями где будет продукт через 1, 5, 10 лет и отсутствием у разработчика Б шара-предсказаний, а также знания какой функционал в будущем окажется не нужным. Сосредоточтесь на настоящем, на конкретном коде и решении проблем в этом контексте.

Абстракция

Одним из признаков неподдерживаемого кода является наличие "текущих" или не существующих абстракций, которые делают работу с кодом малоприятной. Если у вас нарушены абстракции - исправьте их. Кроме того это серьезный профессиональный риск, делать бизнес по созданию абстракции ради самих абстракций. Постарайтесь понять какие есть варианты и исследовать имеет ли это смысл в данном коде. Хорошее правило, если не найдутся 3-4 полезных примера использования абстракции, то можно опустить её. Сообщество Rails использует мантру PDI ("please do investigate") при добавлении слоя абстракции, чтобы понять имеет ли он смысл.

Высокий дизайн

Всегда есть человек, который будет проталкивать последний из шаблонов проектирования, о котором он слышал, пытаясь втиснуть его в новый компонент. Обычно забота о сопровождаемости это "высокоуровневый дизайн" и у проектировщиков будет внутренняя необходимость отгородить себя от решения текущих задач, снова и снова возвращаясь к Абстракции и Неопределенности. Если это так - отбросьте это! Эти паттерны должны иметь смысл в настоящем. Эти изменения должны быть наглядным примером того как код улучшается в долгосрочной перспективе.

Все вышесказанное это не отказ от абстракций, расширяемости и проектирования - эти идеи лежат в основе разработки ПО. Они помогают сделать хорошее программное обеспечение великим. Однако они не должны скрываться за фасадом сопровождаемости и применение этих принципов на основе неподтвержденных догадок не приближает вас к созданию великих программ!

[От переводчика] Это мой первый перевод. Текст, на мой взгляд, оказался довольно пространным, иногда довольно трудно уловить мысль, поэтому назвать это чистым переводом думаю нельзя. Сохранена последовательность изложения и основные идеи, однако художественные тонкости текста, эмоциональная окраска и подтекст скорее всего были искажены или утеряны.

Оригинал