Технический долг и бизнес

/ ~9 мин.

Несколько слов о чистой архитектуре и техническом долге, который заложен в архитектуру приложения.

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

Время от времени я почитываю чаты в Telegram, и то здесь, то там я вижу рассуждения о том, что технический долг – абсолютное зло. Особенно на уровне архитектуры. И обязательно находятся люди, которые утверждают, что можно же запроектировать систему с самого начала таким образом, чтобы не переделывать архитектуру приложения и не испытывать проблем. А триггером, который побудил меня задуматься на эту тему, стал доклад “Архитектура должника” на RndTechTalks.Architecture от Дениса Александрова.

Докладчик утверждал, что архитектура не может быть заложником технического долга, что это порочный путь развития продукта и т.д. Как ужасно, когда ты приходишь в проект, а там, ужас-ужас, архитектура не прослеживается. И вот он, разработчик за 299.9к/сек, закатывает рукава, героически правит говнокод и приговаривает, что можно же было сделать всё заранее нормально.

Спроси меня два года назад – я бы утверждал всё то же самое. Спроси меня год назад – я бы не нашелся, что ответить, т.к. примерно тогда я вообще принял мысль, что технический долг в растущем приложении – это нормально. Спроси меня сейчас – и я, скорее всего, скажу, что заранее запроектировать систему для растущего бизнеса так, чтобы было хорошо, просто невозможно. Это можно сделать за обозримое время для предприятия, которое уже знает, как зарабатывать деньги, и не меняет свои ключевые пути заработка. Но и здесь есть нюансы.

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

What is архитектура link

Если честно, строгого ответа на поставленный в заголовке вопрос нет. Есть вот такая вот подборочка (см. PDF-файл) определений понятия “архитектура программного продукта”, и пойди разберись, какое из них устраивает нас в текущем контексте.

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

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

What is бизнес link

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

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

Архитектура vs. бизнес link

Мы живем в VUCA-мире (Volatility, Uncertainty, Complexity and Ambiguity). Если говорить по-русски, то нихрена у нас тут непонятно. То, что сработало вчера, может не сработать сегодня. То, что мы воспринимали как нечто незначительное, впоследствии может сыграть огромное значение. Принять ошибочное решение очень легко. Принять решение, которое приведёт к деньгам, несопоставимо сложнее. В этих реалиях и приходится строить бизнес. Если вы делаете нечто большее, чем раздачу газет за 500₽ на светофоре, то нужно готовиться к этим вызовам.

Именно поэтому, кстати, бесполезно читать истории успеха каких-нибудь чуваков и уж тем более пытаться повторить их точь-в-точь. Ловить вдохновение – да, конечно. Искать интересные решения – безусловно. Но тот, кто едет в условный Сыктывкар, чтобы открыть там суши-бар и начать разработку SushIS, потому что только так можно достичь успеха – ну хрен знает, ребята.

Как волатильность и сложность окружающего мира это влияет на архитектуру? Ну, давайте посмотрим:

Думаю, лучшая иллюстрация нестабильности и непредсказуемости мира – текущая ситуация с пандемией, которая начала разворачиваться ещё в декабре прошлого года, но в итоге к ней никто не был готов. Целые отрасли просто умирают, люди остаются без работы и почему-то просят денег. Дурачки, могли бы и накопить заранее, понятно же было, что ситуация повернется именно так.

Тезис докладчика, который возмутил link

Звучит он так:

Давайте сделаем всё хорошо заранее

Сначала про “заранее”. Когда я его услышал в докладе Дениса, то понял, что мы с ним находимся в разных контекстах – он работает в крупном аутсорсе и приходит на помощь к крупным заказчикам, а я тушу пожары в развивающихся продуктах. И вот вопрос: как заранее заложить перепрофилировку бизнеса на новые рельсы? А главное, нужно ли это делать? Непонятно. Если есть данные о том, что такое развитие событий возможно, то может и можно. Но как, например, заложить перепрофилировку транспортной компании из компании, которая помимо щебня возит теперь ещё и тюльпаны, и не только на грузовиках, но ещё и велосипедами, я не понимаю. Всё это про перевозку чего-то из пункта А в Б, но там очень разные процессы и очень разные ограничения, которые закладывать в систему заранее бессмысленно.

Теперь про “хорошо”. Разным этапам развития бизнеса – разные потребности, разное качество, разные специалисты. Когда есть цель просто выйти на точку окупаемости, команда профессионалов собственникам может быть совсем не по карману, и достаточно какого-нибудь простенького прототипа, который выполняет свою работу. Не строить бизнес, потому что код будет некрасивенький, и программистам за 300кк/сек будет неприятненько? Да ну бросьте. Да, хорошо делать сразу гексагональную архитектуру. Да, хорошо делать сразу DDD. Но! Специалисты, которые умеют это, стоят дороже, и временами для теста гипотезы хватит и продукта, который собрали на коленке два студента в свободное от пар и вписок время. Да, плохо. Да, больно работать с этим кодом. Но зато этот код принёс денег, которыми смогли расплатиться за ваши услуги как за профессионала разработки стабильного ПО с чистой архитектурой – чего жаловаться-то теперь? Наслаждайтесь интересными инженерными задачами!

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

Как гибкие методологии приходят на помощь link

Если вы ещё не читали “Черную книгу Scrum”, то почитайте, полезное чтиво для понимания, что к чему. Я позволю себе привести цитату из этой книги:

Идея Скрам - каждый спринт выдавать заказчику “новую пользу”. Возможно, ты помнишь эту глупую картинку, где покупатель сперва получал скейт, потом велосипед, потом мотоцикл, а потом и авто. Вместо того чтобы сразу и долго ждать машину? Мы тоже ее помним. Мы с нее начинали. Почему глупая? А как можно из скейта сделать велосипед? Только выкинуть наработки и сделать заново, с нуля. Ты понимаешь? Скрам даже не скрывается! Он сразу показал нам иллюстрацию того, что он не работает на большинстве задач. Но мы восприняли ее с воодушевлением!

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

  1. Заговнокодили MVP
  2. Обкатали, как работает
  3. Решили, как дальше с этим жить
  4. Запрограммировали по всем инженерным правилам (или выкинули)
  5. ???
  6. PROFIT!!!

Всё это называется “проверкой гипотезы”.

(да, мне не стыдно тащить в пост мемы из прошлого десятилетия)

Когда всё-таки всё можно сделать заранее? link

Сделать заранее хорошо возможно, кажется, только в этих случаях:

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

Заключение link

Жить с долгом в архитектуре, в коде, да и где угодно – это нормально. Кажется, что отталкиваться от текущих потребностей и возможностей бизнеса для разработчика важнее, чем потратить время и деньги на стабильную архитектуру тогда, когда это может быть и не по карману. Здесь мне куда ближе выражение “война план покажет”. Невозможно предсказать все события, невозможно сделать всё идеально сразу. Можно лишь быть морально к этому готовым и закладывать в архитектуру как можно меньше решений, оставляя их на потом. Это и есть чистая архитектура.

Если бизнес и умрет, то он сделает это не потому, что его запрограммировать не смогли, а потому что не протестировали гипотезы, которые надо было протестить с самого начала (спасибо Аркадию Морейнису за светлую мысль). И тут есть созвучная история – кажется, что когда приходишь в продукт, нужно изучать не код, а бизнес, для которого этот код был написан, т.к. код имеет свойство ошибочно описывать окружающую действительность. Но об этом в другой раз.