Comments 14
Статья бред, проблема не в слабости команды а в желании бизнеса сделать продукт за 3 копейки и за 2 дня, если бизнес ставит цель налепить в MVP функционал то вы должны лепить функционал а не тратить время на архитектуру и всякого рода "правильные" решения, .к. все они заточены облегчить жизнь потом а не сейчас, а завтра проект, который не выстрелит могут закрыть, тогда все потраченное время на реализацию правильных подходов будет потрачено зря + есть и другие вещи, например перформанс, "правильные" подходы делают код красивым и читаемым но совершенно не оптимальным, по этому далеко не всегда стоит прислушиваться к статьям написанным явно разрабом но не лидом
Спасибо за комментарий! Он по делу. Реально. Потому что ты прав. Если бизнес ставит цель "налепить за три дня", то никто не будет играться в архитектуру. И правда в том, что не всякая архитектура нужна MVP, и не всегда "чистый код" = полезный код. Для прототипов и одноразовых выстрелов это не нужно.
Но. Как только MVP выжил, многие команды начинаешь платить по счетам. И если архитектура не закладывалась хоть как-то, то дальше проект возникает большой вопрос. И именно об этом статья. О том, что "чуть-чуть неправильно, но пока сойдёт" -> за три спринта превращается в болото. Не про красоту ради красоты. Про выживание на длинной дистанции скорее.
Главное, чтобы подъедать не начало именно то, что было "пофиг, потом поправим")))))
С одной стороны, статья соответствует заголовку (т.е. заявленным целям).
С другой стороны, она несколько однобока, так как (и это очевидно), в такие игры можно играть вдвоём.
Берём легендарную книгу "Путь камикадзе" легендарного автора Эдварда Йордона, открываем на условной 94 странице и начинаем читать.
Читать, что сроки работ нужно удвоить и добавить её чуть-чуть.
Или читать, что такое "китайская пытка водой": кап, кап, кап.
Если уж совсем смотреть реально: почему вы считаете, что
На исправление боли потратили огромное количество времени и по итогу вынесли логику на уровень сервиса.
это плохой результат (хотя из статьи можно сделать такое предположение)? Если бизнес устраивает сначала сделать на костылях, а потом переделать "по-нормальному" (хотя бы условно) - то кто мы такие, чтобы его (бизнес) переубеждать?
Проще нужно быть. Проще!
Очень годный комментарий, спасибо!)))
Бизнес может осознанно выбрать путь "сначала быстро, потом переделаем". И это нормально, если он действительно потом переделывает. Если бизнес готов платить - круто. Тут скорее против иллюзии, что “мы потом всё исправим, когда станет удобно”. Никогда не станет удобно.
Но гибкость это да! Это хорошо)
Вот только когда разработка очередной фичи не влезет даже в три спринта (из-за постоянных багов и распутывания спагетти), а потом ещё выстрелит сбоем на продакшн не, этот же бизнес скажет "вы плохие разработчики",а когда укажешь на технический долг, спросит "почему раньше не сказали"
Бизнес не шарит, какие последствия. Нужно уметь объяснять: тут костыль можно воткнуть, а тут нет, если хотите чтобы продукт дальше ехал.
Но проще же воткнуть костыль и валить все на бизнес?)
Вот что то у меня куча других примеров, когда делали всё как сказали архитекторы. В итоге TTM, X8, раздутый штат и убежавшие далеко вперёд конкуренты. Такие проекты закрывают или признают неудачными.
Если технически влезает в одину команлу и БД на старте, то нельзя раздувать и делать "правильно' 5 микросервисов с 6-ю интеграциями. Будет эффект - появятся ресурсы на рефакторинг. Большие монополисты могут позволить себе иные подходы. Видел изнутри, к сожалению.
Да, ты описали абсолютно реальную сторону. Проекты, где "всё как по учебнику", но фича выходит через год. Слепое следование архитектурным заветам без учёта контекста - это такая же ошибка, как и забивание на архитектуру вообще. Поддержу коммент выше - "Гибче нужно быть".
Но и игнорировать явные последствия ради скорости не меньшее зло. Истина где-то между, и именно об этом статья.
Бизнес никогда - нет, НИКОГДА!!! - не даст ресурсов чтобы уже работающее и приносящее профит переделать "как следует". Даже могу рассказать почему так, но это отдельно. Поэтому у технаря есть толька два варианта - либо сразу заложить запас на развитие в своей конструкции либо переделывать уже работающее тихо незаметно в свободное время. А если бизнес отличается "плодовитостью" на гипотезы и эмвипишечки, то технарь обязан быть провидцем и понимать, что из этого перспективно, а что заведомо чушь - и штуки стоящие делать с запасом прочности, а ерунду делать так, чтобы потом как можно дешевле было ее выкинуть.
Что касается технической стороны, основным принципом гибкой архитектуры уже давно признана модульность в сочетании с портами и адаптерами.
Когда вы начинаете работать с одним брокером, создайте порты для взаимодействия с шиной и соответствующий адаптер. Когда приходит время заменить шину на другой брокер, достаточно изменить только адаптер, что позволяет сделать этот процесс максимально безболезненным. Всю сложность миграции можно будет сконцентрировать в слое инфраструктуры не касаясь кода на слое приложения.
Если необходимо разработать сервис уведомлений, его можно организовать модульно: создать модуль для уведомлений о статусе заказа, модуль для оповещений о промежуточных статусах по SMS и так далее. Если возникает задача расчета скидки, вы можете разработать модуль для расчета скидки и оркестратор, который будет последовательно соединять эти модули. Да, какое-то время модуль расчета скидки может находиться внутри сервиса уведомлений, и если функция будет успешной, вы сможете договориться с бизнесом о том, что для MVP мы сэкономили ресурсы, но для долгосрочной реализации необходимо инвестировать сэкономленные ресурсы и вынести модуль расчета скидок в отдельный сервис.
Чем меньше модули, тем сложнее конфигурация и больше гибкости, но чем больше модули, тем меньше гибкости, при упрощении конфигурации. Определить оптимальные границы не всегда просто, но в некоторых случаях это очевидно (скидки vs уведомления). Работа с инфраструктурой должна осуществляться исключительно через порты и адаптеры, и старайтесь избегать прямых вызовов между модулями, используя слой оркестрации (будь то process manager или так называемая saga).
Существуют и другие подходы, но освоение этих принципов позволит решить 80% возникающих проблем.
Что касается коммуникации, ваша задача — предоставить как можно больше обратной связи. Решение о том, делать что-то быстро, но не идеально, или основательно, но медленно, принимает бизнес, а команда разработки предоставляет необходимые входные данные о прогнозируемых рисках/сроках и исполняет команды. Если вы выполняете свою работу качественно (т.е. делаете именно то, что просит бизнес, при этом давая качественную и своевременную обратную связь о рисках и новых вводных), никто не сможет обвинить вас в некомпетентности, даже если проект технически находится в тяжёлом состоянии (если, конечно, внешний аудит не выявит факты саботажа, но это уже другая история). У вас будут все данные вами рекомендации и анализ (будь то чаты, заметки после встреч или, что еще лучше, записи архитектурных решений (ADR) в базе знаний, "подписанные" PO).
По моим наблюдениям, проблемы с говнокодом возникают даже не из-за "хотелок" бизнеса , а из-за недостаточной компетентности руководства в командах. Часто (почти всегда) непосредственный руководитель спит и видит как бы перебраться на более высокую ступень, забивая на поддержание в форме своих технических скиллов(если они вообще были в достаточном объеме), очень часто решения по разработке отдаются на откуп самой команде, в которой синьоры и джуны находятся на одном уровне и, при возникновении конфликтов, некомпетентный руководитель зачастую поддерживает не ту сторону, лишь бы "атмосфера" в команде не страдала, вплоть до увольнения синьоров, которые требуют поддерживать код на высоком уровне, вместо того, чтобы отправить джунов учиться у тех же синьоров. Ну и т.п.
А "правильная" разработка как раз позволяет и фичи делать "вчера", а вот когда все через одно место, то уже все летит под откос.
Как говорится - можем сделать быстро, правильно и недорого. Выберите два варианта.
Как убить архитектуру за три спринта: практическое руководство