…или «Не трогай то, что работает» vs «Не ремонтируй то, что не сломано»

С возрастом и временем приходит понимание того, что эффективность труда повышают обычно даже не ради непосредственных результатов труда. И не ради самого труда же. Главная цель, к которой человек стремится в своей карьере — получать как можно больше, делая как можно меньше. То, что лень двигает прогресс, является общеизвестным фактом.

Как ни странно, в то же время то, что лень является одним из смертных грехов, тоже никто не отменил. Нижеследующим я постараюсь согласовать это противоречие, равно как и показать тонкую разницу между утверждением «не трогай то, что работает» и «не ремонтируй то, что не сломано».

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

В суровой практике, однако, часто мы наблюдаем совершенно другое. На каждый компонент разрабатываемой системы обычно выделен фиксированный бюджет, в результате чего после того, как он был объявлен работающим, а его квота времени исчерпана, опять лезть в его внутренности трудно. Менеджеру проекта будет трудно отчитаться перед заказчиком в том, что время ушло на «доработки» компонента, готовность которого заявлялась месяц тому назад. Списывание потраченного времени на что-либо другое ничем не лучше, потому что в результате легко попасть под обвинение в некомпетентности и неумении держать слово.
Поэтому новые компоненты внедряются в систему уже не с целью поднять всю систему, а с целью не сломать то, что уже кое-как работает. И даже если были допущены серьезные ошибки проектирования, новые компоненты будут скорее подгоняться под них, чем эти ошибки будут исправлены.

Обычно, когда разработчик объясняет менеджеру порочность данного подхода, тот ему отвечает: «Это ведь займет слишком много времени! С другой стороны, старый код ведь работает, с чего ты взял, что проблема именно в нем? Нет, лучше адаптируй новый код так, чтобы все работало. Это займет не так много времени.»

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

Иногда источником столь порочного мышления является сам разработчик. Ведь он написал работающий (кое-как) код, зачем его исправлять? Зачем тратить время на то, на что время уже потрачено? В конце концов, стремление к извечной цели получать все, ничего не делая, берет верх. Уже потом действительность показывает, что разработчик сам себя «развел» на лишнее рабочее время.

С другой стороны, стоит подход «не ремонтировать то, что не ломалось». Казалось бы, это то же самое. Но на самом деле здесь добавляется одно условие: не ремонтировать только, если не ломалось. Это необязательно означает, что все, что не работает — сломано, а все, что работает — не сломано. Здесь другой критерий: ездить на автомобиле можно и тогда, когда покрышка лопнула, и когда под капотом стучит. В известной мере автомобиль работает. Вопрос лишь, сколько времени ему работать в таких условиях осталось и с какими последствиями.

Как соотнести наш пример с программным обеспечением?

Если слово workaround применяется в контексте компонентов, не разработанных третьей стороной, то разрабатываемое ПО сломано. Если при добавлении четвертого компонента первый перестает работать, как описано, он сломан. Если у объектов различное представление об общей модели данных, с которой все они работают, они сломаны. Если нужно поднять годичной давности собственный код, и нужно долгое время разбираться, как же он работает, то он сломан.

А сломанное нужно ремонтировать, не так ли?

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

И этот подход работает на конструктивную лень. В конце концов, чуть больше усилий, приложенных сейчас, сэкономят уйму времени потом, если суметь посмотреть чуть дальше кончика собственного носа в будущее. Конструктивная лень на самом деле является рациональным желанием не прилагать ненужные усилия, деструктивная — желанием не прилагать усилий вообще.
P. S. Конечно же, разработчик не должен превращаться в трудоголика с подходом «Если не сломалось, ремонтируй, пока не сломается». Но это уже совсем другой способ неэффективно расходовать свое время.