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

> If no one is using your product, who cares how clean your code is?

> This morning your team can add more code, or add more customers. Which do you want?

Эти цитаты вызвали у меня профессиональный интерес, и желание проанализировать их.

Фразы сильно зависимы от контекста. Непонятно, какой опыт от использования продукта (негативный или позитивный), какая модель разработки и обработки неопределенности (BDUF, спиральная, итеративная), какой экономический эффект от раннего выхода на рынок, и предпочтут ли новые пользователи дефектный продукт перед конкурирующим? Попробуем восстановить контекст.

Во-первых, основная задача Clean Code - это повышение темпов разработки. В таком случае, противоречия между первой и второй частями первой цитаты даже не возникает. Если быть точным, то основная задача Clean Code - это достижение архитектурного качества Modifiability, которое позволяет снизить рост стоимости изменения кода вплоть до горизонтальной асимтоты, что создает экономическую целесообразность эмпирического разрешения неопределенности требований путем Adaptation, а не Prediction, поскольку стоимость реализации решения в таком случае становится независимым от момента времени принятия решения. Таким образом, Clean Code представляет ценность не сам по себе, а только как средство достижения экономической целесообразности итеративной модели разработки. Например, при BDUF он уже не имеет такого важного значения, так как все решения уже приняты заблаговременно.

Во-вторых, необретенного клиента еще можно обрести. А вот потерянного клиента вернуть уже достаточно сложно. Из цитаты неясно, какой опыт обретается из "using your product" - позитивный или негативный. А это уже сильно зависит от внутреннего качества продукта.

В-третьих, качество кода не замедляет темпов разработки, потому что существуют методики сглаживания Design Payoff Line.

В-четвертых, существует 4 типа техдолга. При reckless нужно заниматься не Чистым Кодом, а обучением. А prudent часто допускается из соображений YAGNI, кроме случая prudent-inadvertent, который неизбежен, и часто устраняется в контексте Бизнесовых Сторей, так как окупается в пределах релиза. Сам Фаулер в таком случае советует даже ничего не говорить менеджерам.

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

Основная причина появления багов - это высокий уровень сложности, с которым приходится иметь дело краткосрочной памяти разработчика. В таком случае, он легко может упустить что-нибудь из внимания. Еще Гради Буч говорил, что Архитектура - это многоуровневая система абстракций (где назначение абстракций - управление сложностью).

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

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

P.S.: Кто-то красиво сказал - не важно, сколько вы потратили на написание кода, который не работает как нужно.

#SoftwareDesign #Management #SoftwareArchitecture