Скорость на старте - это кредит с процентами на изменениях

Продолжим о стоимости разработки.

«Потом отрефакторим» это одна из самых дорогих фраз в разработке. Нет ничего более постоянного, чем временное, поэтому «потом» откладывается, поверх него пишутся фичи (не, ну срочно же). И наступает в момент, когда менять уже не просто больно, а очень и очень дорого.

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

Из других инженерных практик я вспоминаю пример компании Boeing. Модель 737 - одна из самых массовых, но была разработана в 60-х годах. В борьбе за экономию на низкий устаревший фюзеляж нужно было ставить все более объёмные двигатели. В итоге получился 737 MAX, который из-за специфического расположения новых двигателей имел в системе пилотирования самые настоящие костыли (система MCAS), о которых не предупредили пилотов. Ценой поздних изменений стал не только кризис в компании, но и, к сожалению, две авиакатастрофы.

В разработке цена в абсолютном большинстве случаев несопоставимо ниже. Тем не менее, она очень высока.

В компании, где я работал лидом, в какой-то момент потребовалась бизнес отчетность. Когда компания была в стадии стартапа, отчеты стали собирать на базе логики: «сходить сюда, взять пачку данных и тд».

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

Когда соломинка ломает спину верблюда

Универсального порога включать сирены нет, но есть набор сигналов. Один сигнал - повод задуматься, три-четыре вместе - вы уже в зоне риска.

Сигнал 1: Каждая правка ломает что-то в стороне. Команда делает что-то в одном месте, а отвал выстреливает там, где не ждали. Это значит, что связи в системе уже не помещаются в головах хранителей, а в коде они не выражены. Классический признак накопленного Change долга.

Сигнал 2: Заплатка на заплатке. Система MCAS появилась, чтобы скрыть аэродинамику, которую критически меняло само навешивание двигателей. Если ваше новое решение появляется, чтобы компенсировать легаси, вы не развиваете систему, а подпираете костылями.

Сигнал 3: Оценка простой правки выросла в разы. Раньше правка занимала день, теперь неделю. Объяснение всегда одно: трогать страшно, потому что непонятно, что отвалится.

Сигнал 4: Это знает только Саша. Поведение куска системы держится в голове одного человека, тестов нет, документации нет. Пока Саша на месте, оно более-менее работает. Очевидно, что все развалится, стоит Саше отвернуться.

Что делать?

Я считаю, что надо начинать с практики RFC. Команда должна писать о том, как она планирует делать изменения. На практике одной из компаний, которую я консультировал, мы выяснили, что при кажущейся длительности написания RFC подумать и обсудить решение на среднесроке проще, потому что множество проблем исключается на макете, а не на реальной системе. RFC - это и есть та модель, документ, который описывается командой. 
В нем объясняется, почему, при каком условии были сделаны изменения.

Также никто не отменял тестирование. Но зачастую в легаси системах юнит тестирование встраивается ценой, примерно равной рефакторингу, а создавать контроль качества хочется уже сейчас. В таком случае хорошим выбором будут сценарные и E2E тесты. Они не лезут внутрь системы, но проверяют, что на вход X система отвечает Y. Более того, для старта можно даже взять готовые системы, которые не требуют программирования. Также это фундамент для рефакторинга, потому что без тестов он превращается в создание какой-то новой системы, а не тем самым изменением кода без изменения логики.

Build посчитали один раз. Change платят на каждом релизе, пока живёт фича.

#процессы #разработка #ценаразработки