МФ
мало где знают или думают что знают
Size: a a a
2021 October 05
МФ
у меня под статьей писало пару ребят, что приходили в ДДД преокты, а там анемия и мрак
SP
на словах все львы толстые, и даже на гитхабе можем быть...
SP
да, ДДД всех спасет...
SP
я бы предпочел устраиваться в компании где понимают разницу в подходе "дать задачку разработчику" и "описать проблемы инженеру" и предпочитают второе
МФ
но если ты идешь найти хороший ДДД и просишь показать код, как ты поймешь6 что это хороший ДДД ?
SP
потому что без этого никакого толку от ваших этих ddd не будет.
SP
если "аналитик тебе пишет задачку в джире" о каком ddd идет речь
SP
собирутся такие программисты и играются в единый язык и единый он только для них
ЮW
у всех свое понимание DDD (и переписка здесь это подтверждает), в коде смотрю на намного более приземленные вещи - типизация, тесты, комментарии, отсутствие методов по 100 строк и т.д. Плохой/хороший код виден сразу, DDD может быть, может не быть - не важно.
Для меня важно, чтобы люди хотя бы смотрели в эту сторону. Дальше уже все решается в обсуждениях и на конкретных примерах кода.
Для меня важно, чтобы люди хотя бы смотрели в эту сторону. Дальше уже все решается в обсуждениях и на конкретных примерах кода.
SP
так "в эту сторону" для всех разное - у кого-то ddd это обмазаться антикорапшен лэйерами и там репозитории сущности. А у кого-то сидеть с продуктом и рисовать process mapping (event storming) или там domain storytelling собирать. Это редко про рядовых разработчиков...
SP
ммммм... не понял, "что бы ТЗ умели писать" - кто умел писать ТЗ? Зачем мне ТЗ?)
SP
а зачем тебе ТЗ когда у тебя есть ДДД?)
SP
ну или по другому вопрос - зачем тебе писать какое-то ТЗ если ты там модели моделируешь и в код их переносишь?)
SP
и кто пишет тз в конце концов)
MM
ТЗ нужен для обезьян. Для программистов нужно описание проблемы, которую нужно решать. А детали и все прочее уже мало волнуют заказчика.
✨
как удачно зашла ))
шо, опять!? ))
шо, опять!? ))