Комментарии 10
Я делаю акцент на следующий вывод " Для нас длительность реализации подхода оказалась не столь критичной, ведь мы не потеряли время/деньги/мотивацию, разрабатывая продукт в неправильном направлении, опираясь на субъективные вводные участников процесса. Одна короткая сессия Event Modeling может уберечь продукт от бесконечных часов разработки “в стол” . К сожалению, сейчас многие разработки начинаются с каких-то поверхностных утверждений: "так хочет бизнес" без проработки бизнес-логики. Давайте быстрее-быстрее, что думать - трясти надо. В результате через какое-то время приходит понимание, что надо и подумать.
В этой статье четко доведена идея: "А давайте сначала хорошо подумаем, а потом начнем пилить". Бальзам на мою душу аналитика.
очепятка на картинке с красными и синими квадратиками. в правом верхнем углу должен быть "Event Storming" а не "Event Sourcing", см. оригинал: https://threedots.tech/post/software-dark-ages/system-thinking-solved.jpg
А вы готовите BDD?
Go позволяет одинаково именовать пакет в файлах с кодом модуля и с тестами, тогда у нас есть доступ к внутренней реализации модуля (императив), а не только к API модуля (декларатив). В статье нас призывают к TDD, при этом не спускаясь на императивный уровень, а формулируя тесты перед кодингом только на декларативном уровне. Но при рефакторинге я предпочёл бы иметь покрытие на императивном уровне. В наше время этого легко добиться с помощью ChatGPT. Тогда такие императивные модульные тесты не жалко выбрасывать вместе с модифицируемым кодом, если потребуется. Хорошо. А как бы улучшить Developer Experience для декларативных модульных тестов? Сплю и вижу процесс разработки по схеме: Event Modeling > BDD > Integration/Unit Tests (via gherkingen) > code for development via tests for external API of modules - package module_test / whitebox for refactoring > Unit Tests Coverage for internal functions in modules package module / blackbox for modifications (via ChatGPT).
Как навести порядок в AI-продукте: опыт внедрения методологии Event Modeling