Comments 21
А потом приходит заказчик и говорит: я просто хотел получать уведомления каждый раз, когда кто-то покупает мой онлайн-курс "Keep it Simple, Stupid!"
+
С таким подходом, можно проект никогда не закончить. Хорошо, если это будут оплачивать.
Заказчику это может быть на самом деле не надо.
А может быть он не в курсе, надо это ему или нет.
И дело специалиста, профессионала в своей области, показать заказчику что тут надо сделать, а потом убрать те части, которые заказчик посчитает ненужными - когда они понадобятся заказчику, тогда и запилим.
Итог - вместо того, чтобы реализовать самый первый, самый простой, но жизнеспособный вариант, разработчики первый месяц занимались каким-то проектированием...
Кстати, прочитав исходные два требования, я не увидел, что уведомления должны браться из БД. Я их понял так, что в БД нужно сохранять лишь факт отправки уведомлений.
еще одного этапа проектирования
Хорошо проиллюстрировано почему нужен второй этап проектирования. И даже отношение технических требований первого и второго уровней довольно типично. И конечно да можно проектировать до бесконечности, но обычно трех согласлованных уровней хватает : требования заказчика, спецификации системы и ее компонент.
Ну и описан вариант недоработки второго этапа при разработке архитектуры. Я, кстати, из текста тоже понял, что база только для логирования "отправок", сижу и думаю, чем может нагрузить добавление одной записи в минуту? Потом ТС разъяснил, что и сам не вьехал (ну когда писал). Ну и непонятно, что за такой кэш (ну и как он так по глупому построен), что может "потерять" запись, пускай даже на время? В общем - неоднозначно все у ТС-а...
А целом - типичная задача ну и решений полно, да у загашнике у каждого более-менее "долгого" спеца есть свое собственное.
Откуда взялось 10-20-100 модулей, которые читают уведомления и отправляют их? Зачем дублировать код отправки в 100 местах? Это должен быть один модуль, с настраиваемым кол-вом одновременных потоков, от 1 до n. И уже экспериментальным путем подбирать оптимальное кол-во потоков. Зачем кэш?
Короче, ничего не понятно с самого начала.
Перечитал еще раз. Малец хаос. Уведомления - это журнал, все туда пишут, когда им захочется, пачками или по одному. И отдельный поток (или несколько) это дело читает и рассылает. Тоже по одному или пакетом.
Можно прикрутить rest api, чтобы пополнять журнал, а можно подписаться на брокера сообщений.
На первое время журнал можно сделать в виде таблицы в реляционной БД. Когда перестанет хватать - перейти на кафку. Но это случится, когда если проект станет очередным фейсбуком.
Если надо как в UDP (отправил и забыл) - то никакого логирования, только указатель на последнюю прочитанную запись из журнала или флаг "обработано".
Если надо как в TCP - тогда да, придется писать логи, что было отправлено, что нет, последнюю ошибку, политики повторов и так далее. Но тут сразу проблемы с пакетной отправкой - из пакета в 100 штук могут упасть только 10.
Никаких кэшей. Можно ежедневно мониторить размер не обработанной очереди. Если она растет - значит мало серверов на отправку. Добавляем или настраиваем авто масштабирование в облаке по этому признаку в облаке.
Другие модули не отправляют сообщения. Об этом нет речи в статье.
Не придирайтесь к описанию решения описан гипотетический пример, он не был взят из жизни. Статья о том что простое: "сесть и подумать до написания кода" вскрывает много подводных камней.
Прошу не воспринимать как критику, просто информация к размышлению.
Но опытный разработчик посмотрит и скажет, что это плохое решение. В системе может быть много модулей: 10, 20, 100. Если каждый модуль будет обращаться к БД раз в минуту, это может вызвать перегрузку БД, и печальные последствия для системы.
Вот тут я бы попросил уточнить: а опытный разработчик из этой истории сам примет решение относительно требований к системе (получил задачу и ушёл творить)? Если да, то это очень плохо, т.к. надо было бы подключать заказчика, архитектора, аналитика или кого-то, кто владеет информацией о реальных потребностях.
Иначе может так статься, что вы будете стрелять пушкой по воробьям, проектируя максимально надёжное и высконагруженное решение, хотя на деле потребность может оказаться 0.01 ops. Тут как раз архитектор (или кто-то иной из названных выше товарищей) и мог рассказать о нефункциональных требованиях.
На 2 явно озвученных функциональных требования было сформулировано еще 10 неозвученных;
Вот те 10 требований по факту можно рассматривать как проектное решение. Заказчику эти вещи, видимо, были не сильно интересны на входе в проект. При наличии обратной связи от него что-то и могло потом "просочиться" в требования. По крайней мере я не увидел по тексту, что кто-то потом подтвердил необходимость в оных.
А вообще, проектирование — это не про схемы... Вместо схемы Вы можете использовать текстовое описание. Главное понятно донести до команды суть вашего решения.
И да, и нет. Естественные языки страдают от избыточности и неоднозначности, вот тут диаграммы (особенно в понятных нотациях) и полезны. Безусловно, одних диаграмм не бывает достаточно, слова потребуются, т.к. хорошо, когда эти 2 бойца работают в паре.
Закроем это требование добавлением кэша...
Это и последующие решения я бы согласовывал с архитектором. Может оказаться, что кэш нужен вполне конкретный, что он уже есть в ИТ-ландшафте и нужно использовать именно его, не привнося ничего своего; а что-то может вообще противоречить целевой архитектуре и архитектор просто поставит крест компоненте; логирование же может быть просто ненужным, т.к. сервис не рассматривается критичным (отправка и доставка сообщений не является критерием успеха) и пр.
P.S. Допускаю, что, на самом деле, всё это было учтено и сделано, просто в тексте в целях сокращения материала эти моменты были пропущены. Мне лично их не хватило. Успехов!
Статья не про проектирование, а про то что оно дает разработчику.
О том что даже простые требования, в реальности таковыми не являются. К.Вигерс в своей книге это хорошо подмечает.
Конечно, здесь не затрагиваются вопросы сбора и согласования требований заказчика, согласование решения с архитектором и т.д. Не об этом статья.
Проблема в том что проектирование в вакууме, без согласований с заказчиком, архитектором и т.д. приведет к потере времени и денег. Можно спроектировать отличную распределенную систему, написать идеальный код, для сайта цветочного магазина у остановки, но зачем ему все это?
Проектирование это инструмент, общение с заказчиком тоже своего рода инструмент. умение пользоваться одним инструментом без использования другого приводит к забиванию гвоздей микроскопом.
Нельзя отрывать проектирование от сбора требований от заказчика и согласованности решения с другими командами.
А где схемы создавали?
А если через UML описывать - сильно сложнее/дольше получается? Как будто им обычно паттерны всякие описывают (но могу ошибаться)
Первая схема - это для печати на А2 и где-то повесить, чтобы было.
--------------------------
Для разработчика конкретно что нужно:
Описание контракта сервиса, который он делает.
Понимание стека
Иные соглашения (наименования, логирования, безопасности, ...)
Нефункциональные требования к сервису
Чтобы к этому прийти, архитетор и ДЕЛАЕТ разработку архитектурного решения. Как именно, если кратко, вам сюда: The C4 model for visualising software architecture. Там указан роадмап, как рисовать схемы. Если и другие ресурсы, но идеи схожи. Можете погружаться и копать вширь и вглубь
Схемы являются результатом проектирования и позволяют проверить, что решение в целом будет работать и будет соответствовать нефункциональным требованиям, которые собираются на первом этапе.
Но не схемы критичны, как таковые - а подход, о чем вы и написали в конце статьи. Но, к моменту проектирования конкретного сервиса у вас уже должно все остальное быть "на борту". Это странно, в этом момент уже думать о том, как делать кеш, многопоточность, идемпотентность и т.д.
Ну и в вашем описание этот "сервис" все время путается под ногами архитектора. Вы либо сначала "архитетктурите", а потом уже сервисы, либо делаете одновременно, получая каждый новый сервис, который базируется на чем-то своем или улучшенном. Либо так статья написана, типа на негативном примере, что ли
Это не "неявные требования", а аналитические вопросы, требующие соответствующей проработки. Большая часть вопросов, к слову, может отсеяться после получения контекста о требуемой системе.
Более того, никто не запрещает сделать на коленке первый вариант который уже через неделю будет решать бизнесовые задачи, и развить его по мере необходимости в нужный (!), а не предполагаемо нужный вариант.
Так, значит, раздуваются требования к системе в заказной разработке? А клиент "просто хотел получать уведомление когда у него купили курс".
В том то и дело что не все аналитики в состоянии проработать технические вопросы. Не владеют "контекстом о требуемой системе"
Описывают просто бизнес процесс и логику оставляя технические вопросы полностью на усмотрение разработчика.
Что касается: "Cделать первый вариант на коленке, а потом доделать" - зависит от условий в которых реализуется проект. Хорошо если у Вас есть такая возможность.
Вам ведь в любом случае на старте необходимо понимать куда и как будет развиваться решение, заложить какую-то то базу, а для этого надо сесть и подумать.
Иначе, вы будете получите ущерб от того что часть работы придется выбросить.
Еще более худший вариант, разработчик полениться и начнет достраивать поверх какое то другое решение.
Ну вот видите, множество "неозвученных требований" в этой задаче на поверку оказываются "it depends". Пример сферического коня в вакууме.
На моем опыте не раз приходилось видеть как посредственные разработчики за посредственные оклады делают системы которые работают, и приносят реальные деньги (я в их числе). Менеджмент к тому же говорит, что это такая бизнесовая модель - быстро проверять гипотезы и развивать те, что выстреливают. Ни о каком проектировании или надежности речи не шло. It's just work.
Пока вы будете проектировать систему тратя недели/месяцы на согласования, утверждения, встречи, протоколы, более гибкие участники рынка уже займут нишу.
Вы вольны выбрать сами глубину проработки для разработчиков, речь в статье о минутах и часах (если идет согласование). Важно не доводить процесс до абсурда на месяцы и годы ;)
К стати, если есть возможность, загляните в приложение Enterprise Arhitect, там процессу проектирования уделяется очень большое внимание - реализация пром.стандартов.
Нужно ли разработчикам проектирование?