AK
Каждый раз когда вижу DDD еле сдерживаюсь, чтобы не сказать DEVELOPMENT driven DEVELOPMENT 😂
Size: a a a
2020 July 13
AK
(не судите строго)
f🤔
я соглашусь, если исключить ddd
потому что если остальное несёт в себе идею, что тебе нужно немножко upfront planning, то ddd вообще несёт идею про единый язык
потому что если остальное несёт в себе идею, что тебе нужно немножко upfront planning, то ddd вообще несёт идею про единый язык
согласен тут
AD
я соглашусь, если исключить ddd
потому что если остальное несёт в себе идею, что тебе нужно немножко upfront planning, то ddd вообще несёт идею про единый язык
потому что если остальное несёт в себе идею, что тебе нужно немножко upfront planning, то ddd вообще несёт идею про единый язык
Да, но только единый язык и понимание бизнес флоу через тот же эвент шторминг несёт такую же идею. Так как ты изначально описываешь поведение проекта, а потом делаешь. Но делаешь на разных уровнях и разными абстракциями
AD
И в этом идея как раз, поэтому ддд от бдд в моем понимании отличается только инструментом
IN
Народ, я только что странную мысль придумал: tdd, bdd, rdd (readme driven development) и ddd - это вообще об одном и том же, только разными инструментами. При этом, каждый является своеобразной абстрактной основой для следующего dd подхода.
Интересно узнать в чем я не прав и на сколько уже головой поехал
Интересно узнать в чем я не прав и на сколько уже головой поехал
Есть шанс что это ты стареешь ) С возрастом начинаешь видеть метасвязи между казалось бы несвязанными штуками. И для тебя капец все логично, начинаешь другому говорить про это, а он на тебя смотрит как на дурака.
И тут на самом деле хрен поймешь это ты такой умный стал или такой дурак )
Это я говорю как опытный дед
И тут на самом деле хрен поймешь это ты такой умный стал или такой дурак )
Это я говорю как опытный дед
AD
Да, но только единый язык и понимание бизнес флоу через тот же эвент шторминг несёт такую же идею. Так как ты изначально описываешь поведение проекта, а потом делаешь. Но делаешь на разных уровнях и разными абстракциями
Подробнее звучит так:
Тдд - сначала пишешь интерфейс и поведение метода, потом делаешь этот метод, потом рефакторишь
Бдд - сначала описываешь поведение юзерфлоу и публичный интерфейс, потом имплементишь
Рдд - сначала описываешь интерфейс и поведение библиотеки через ридми файл, потом имплементишь
Ддд - описываешь интерфейс и поведение с точки зрения бизнеса (используя общий словарь, что бы натягивалось лучше), потом имплементишь систему (или кусок)
Тдд - сначала пишешь интерфейс и поведение метода, потом делаешь этот метод, потом рефакторишь
Бдд - сначала описываешь поведение юзерфлоу и публичный интерфейс, потом имплементишь
Рдд - сначала описываешь интерфейс и поведение библиотеки через ридми файл, потом имплементишь
Ддд - описываешь интерфейс и поведение с точки зрения бизнеса (используя общий словарь, что бы натягивалось лучше), потом имплементишь систему (или кусок)
AD
Есть шанс что это ты стареешь ) С возрастом начинаешь видеть метасвязи между казалось бы несвязанными штуками. И для тебя капец все логично, начинаешь другому говорить про это, а он на тебя смотрит как на дурака.
И тут на самом деле хрен поймешь это ты такой умный стал или такой дурак )
Это я говорю как опытный дед
И тут на самом деле хрен поймешь это ты такой умный стал или такой дурак )
Это я говорю как опытный дед
Вот да, соглашусь
AD
Интересно донести идею
AD
Подробнее звучит так:
Тдд - сначала пишешь интерфейс и поведение метода, потом делаешь этот метод, потом рефакторишь
Бдд - сначала описываешь поведение юзерфлоу и публичный интерфейс, потом имплементишь
Рдд - сначала описываешь интерфейс и поведение библиотеки через ридми файл, потом имплементишь
Ддд - описываешь интерфейс и поведение с точки зрения бизнеса (используя общий словарь, что бы натягивалось лучше), потом имплементишь систему (или кусок)
Тдд - сначала пишешь интерфейс и поведение метода, потом делаешь этот метод, потом рефакторишь
Бдд - сначала описываешь поведение юзерфлоу и публичный интерфейс, потом имплементишь
Рдд - сначала описываешь интерфейс и поведение библиотеки через ридми файл, потом имплементишь
Ддд - описываешь интерфейс и поведение с точки зрения бизнеса (используя общий словарь, что бы натягивалось лучше), потом имплементишь систему (или кусок)
И тут заметно, что реализация растёт и инструменты меняются, но подход: опиши, потом делай остаётся
IN
Ну ддд - это не сначала опиши, потом имплементь, а скорее описывай и имплементи одновременно. иначе вотерфол получится )
AD
Ну ддд - это не сначала опиши, потом имплементь, а скорее описывай и имплементи одновременно. иначе вотерфол получится )
Не, ты же сначала словарь сделать должен и какие-то события собрать
AD
Как и в тдд, там не все тесты пишутся с самого начала
f🤔
Не, ты же сначала словарь сделать должен и какие-то события собрать
ддд про супербумажку на старте, да
AD
ддд про супербумажку на старте, да
Вооот
IN
Ну хз, может я просто давно с нуля ничего не начинал
f🤔
не ватерфол, но этап препрода, когда кода еще нет, и идут просто разговоры о процессах с заказчиком, там гигантский в сравнении со всеми остальными методиками в первую очередь _написания_ реализующего бизнес-процесс кода
AD
А теперь супер логический ход: ждать хороших тестов в системе и покрытия идеального от тдд - глупо
Но разработчики от ддд ждут идеальной архитектуры (сам ждал) и все рассказы о ддд напоминают восхваление серебряной пули
Но разработчики от ддд ждут идеальной архитектуры (сам ждал) и все рассказы о ддд напоминают восхваление серебряной пули
AD
не ватерфол, но этап препрода, когда кода еще нет, и идут просто разговоры о процессах с заказчиком, там гигантский в сравнении со всеми остальными методиками в первую очередь _написания_ реализующего бизнес-процесс кода
Все так
AD
не ватерфол, но этап препрода, когда кода еще нет, и идут просто разговоры о процессах с заказчиком, там гигантский в сравнении со всеми остальными методиками в первую очередь _написания_ реализующего бизнес-процесс кода
Вот скажи мне, в моей идее есть здравое зерно или я головой поехал окончательно?