Тебе точно нужно проектировать?

Дизайн, или проектирование, программного обеспечения несомненно важный этап разработки. А мы в этом уверены?

В переговорке стоят ворота

• Мой любимый вопрос - «Зачем?». Как думаешь, зачем нужна архитектура?
• Для быстрых прогнозируемых изменений кода? Ну не изменений, а добавления нового поведения.
• Прогнозируемых = интуитивных? Если нет, то мне тогда нужна помощь, чтобы понять ответ.
• Интуитивных? Даже не знаю. Одна из задач, чтоб сверху было примерно понятно что происходит и чем занимается проект. Наверное, ответ - “Да”.
• Похоже, ага. Тогда каким будет самое важное ее качество?
• Ну я вижу самым главным качеством архитектуры — это возможность быстро внедрить или изменить фичу для заказчика с минимальными изменениями т.е. если мы строим какое-то здоровенное здание пользоваться которым будут для работы, чтоб пожить, чтоб поиграть. Чтоб когда те, кто пришел к нам поиграть, не захотели добавить футбольную площадку. И если в результате таких изменений в переговорке стоят ворота, то значит архитектура не очень.
• Клевая метафора. А что в такой архитектуре не очень? Цель ведь достигнута и быстро.
• В результате достижения цели для одного заказчика, мы, не намеренно, изменили части другого заказчика.
• Это тоже, но если это обоих устроило то все ок? Или нет?
• Кажется, это сломало интуитивность. Это не планируемые изменения.
• Вот мне тоже так показалось. А что такое интуиция?
• Ты клонишь к тому, что слова собираются в образы, образы в классы, классы в архитектуру и таким образом читая когда-то слова ты интуитивно чувствуешь код?
• Не совсем. А может и совсем Не. Интуиция это же по сути опыт. Точнее решения, принимаемые на его основе.
• Согласен.
• Только вот нюанс: опыт разработки у всех разный, а нужно чтобы всем было одинаково интуитивно. Что делать?

За что тебе платят?

• Использовать один описанный!
• Можно и так. Пробовал когда-нибудь синхронизировать опыт с кем нибудь? Например, убедить кондуктора что ты расплатишься в конце поездки. Или еще какого-нибудь злобного упертого в том, что тебе можно доверять.
• Тяжело его синхронизировать если каждому пытаться угодить.
• Ага.
• А если один чувак говорит как надо и все делают?
• Чуваки меняются. Что делать когда он сменится?
• Другого взять! Власть меняется, векторы развития меняются. Это закон бытия.
• Перепишем архитектуру? Долго дорого. Бизнес финансировать не будет. А так как принципы никто не знает — привет легаси и не интуитивный код. Ошибки, медленные изменения.
• 🤔
• Вспомни, что ты делаешь в приложении, чтобы сохранить данные?
• Пишем в базу?
• Выносим в выделенное хранилище, ага. Что если поступить и тут так же? Вынести опыт в отказоустойчивое хранилище. А что может быть таким хранилищем в контексте опыта?
• Ну не знаю.
• За что тебе платят?
• За реализацию потребностей бизнеса.
• Я бы назвал чуть иначе, но это детали. Этого достаточно, чтобы определить, что есть наше хранилище.
• Ничего не понимаю.
• Архитектура не нужна если нет приложения, верно? Тогда когда наше приложение потеряет актуальность?
• Когда бизнес сдохнет?
• А получается наш “опыт” теряет актуальность вместе с бизнесом. Так почему бы не поместить архитектуру в него?
• ?…
• Есть такой Закон Конвея: “Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации” (c) Wikipedia. Из него получаем что архитектура станет не актуальной только тогда, когда сдохнет направление в бизнесе. Но если направление сдохло, то код становится не поддерживаемым или его можно выкинуть. Вот этого и позволяет достичь Единый язык.
• Это все хорошо, но не гарантирует главную потребность бизнеса — быстрое изменение системы.

И он заставляет тебя переписать 15 классов

• Я бы сказал что гарантирует. Если быть точным, это способствует отсутствию фрикций при загрузке контекста потому как скорость изменений системы это не только код. Не задумывался из чего состоит решение какой-либо проблемы?
• Не, как-то слишком абстрактно.
• У меня обычно происходит так: Сначала разбираю ее суть. Здесь мы отвечаем на вопрос: “А как это вообще сейчас работает?”. Я это называю загрузкой контекста. Возможно и не я вовсе — уже забыл откуда взял, но сути не меняет. После того как мы осознаем проблему, мы переходим к проверке гипотезы. Здесь мы ищем предполагаем решение этой проблемы. Затем этап дизайна, накидываем решение и под конец это пишем. Кто-то провел исследование. То ли Майкрософт, то ли Оракл, эти обычно что-то такое делают. Выяснили что среднее количество времени, которое уходит на “загрузку контекста” чет около 65%. При этом это средняя температура по палате. То есть в результатах есть как приверженцы XP, так и проекты с огромным техдолгом. Вот и получаем, что за счет крайне низкого времени загрузки контекста мы сильно бустим не только скорость, но и простоту решений
• Хорошо, это понятно. Но ведь не только код может выступать как загрузка контекста. Лучше чтоб этим занимались тесты. Тогда мы можем Единый язык перенести в тесты, а код сделать более абстрактным.
• В теории да, но так мы получим слой “переводчик”. Поговорил с бизнесом -> пошел переводить -> нашел в тестах -> пошел в код. Приколы начинаются когда в исходнике находятся противоречия достижения исходной цели. А когда ты говоришь на одном языке — ты загружаешь контекст сразу в процессе диалога. Это еще и целостность помогает сохранять.
• Да, но тогда людям, которые не впервые в проекте, и контекст проектной абстракции у него загружен, вносить изменения в коде становится значительно сложнее, разве нет?
• Думаю ты прав, однако есть пара нюансов. Во-первых, покажи мне хоть одного человека, который знает контекст всего бизнеса, начиная от среднего размера, и держит его в голове и я поставлю тебе бутылку хорошего вискаря на твой выбор.
• Нет-нет. Бизнес у нас в тестах описан. Но код у нас более абстрактный.
• Ну хорошо. Вот представь себе ситуацию: фраза бизнеса “Теперь Услуга не может быть оплачена без модерации”. В каком классе этот функционал?
• Теперь ты пишешь тест, который не пройдет это условие и заставляешь его работать.
• Ага. И он заставляет тебя переписать 15 классов. Знакомо?
• Вот это знакомо, когда у тебя код не соблюдает базовые законы. Если мы представим, что у нас каждый класс имеют 1 причину для изменений, тогда такого кейса никогда не будет.
• Вероятно. Ну сути то не меняет. Тест тебе не даст интуитивного кода. Он только его зафиксирует и подскажет когда зависимость нужно выделять. А вот в какой тест посмотреть тебе что скажет? Или будешь все 8000 тестов перечитывать?
• В какой тест посмотреть, скажет ровно то, что сказало бы тебе, куда смотреть в коде
• Именно поэтому не имеет смысла делать только одно.
• Я понял! Одно другому не мешает. Абстрактный код не означает отсутствие Единого языка.
• Ага. Ну и «чистую выдумку» никто не отменял. Это как раз было “во-вторых” 😁