ЕК
Ну и да, в процессе такого обсуждения всплыть может гораздо больше подводных камней, которые до реализации прям незаметны и аналитик легко может упустить
Size: a a a
2021 April 13
ЕК
Или я ошибаюсь?
PD
Ну вот не понятно мне, как можно быть хорошим разработчиком и не уметь писать код?
Вот и SA - структуру БД проектируют, а запросы писать не умеют. Результат обычно очевиден....
Вот и SA - структуру БД проектируют, а запросы писать не умеют. Результат обычно очевиден....
PD
Что значит 'все в команде'? Зачем все, достаточно одному написать техдизайн )
ЕК
Кому? Бэкендер фронт не знает. Фронтендер - бэк. Дизайнер - ни то ни другое)
PD
Вот дизайнер - это больно, он бизнес должен понимать даже лучше разработчика...
ЕК
Бизнес - да. Ну типа реальная ситуация когда была поставлена задача, в процессе решения выяснилось что бэкендер не до конца понял как фронт будет с ним взаимодействовать (что бы реализовать user-friendly интерфейс)... В результате на фронте и бэке несовместимые API - и бэку пришлось переделывать уже проделанную работу. При этом все это сопровождалось диким колличеством обсуждений.
ЕК
Бэкенд просто не мог понять как я как фронт реализую даже не дизайн - а интерфейс скорее) Поведение интерфейса)
PD
А, так для этого техдизайн и нужен )
ЕК
Так а кто его пишет?
PD
Ответственный за фичу (иногда бэкендер, иногда фронт, иногда архитектор, обычно вместе)
ЕК
Ну вот у нас архитектор. А в чем отличие от СА его тогда?
PD
У меня обычно бэкендер пишет, отправляет фронту на проверку, тот дописывает, потом я смотрю сверху - и вперёд
ЕК
Грамотно.
PD
У вас - не знаю. Может и никакого )
G
А вы OpenApi не пробовали?
ЕК
Вообще. Ну то есть тот кто пишет техдизайн временно берет на себя роль СА?
PD
А при чем тут формат описания api?
G
Договориться на берегу об api, дальше разойтись и писать, не надо сверяться друг с другом
PD
Ну, скорее системного архитектора + СА, но на ограниченном скоупе