Открыть список
Как стать автором
Обновить

Комментарии 3

Была подобная практика на одном проекте. Правда обычно без обсуждения с командой и командного ревью: архитектор ревьвил то, что вы называете техническим решением. Мне не понравилось — он требовал более детальных описаний, которые я предоставлял только уже решив задачу почти полностью и скопипастив код. Причём подходы у нас были разные и часто мне приходилось переделывать.

На сколько я понял смысл в том, что бы не переделывать ;-)
Сначала рисуется диаграмма последовательностей, потом алгоритм взаимодействия, потом входные/выходные параметры на каждом этапе и потом все это согласовывается. После апрува можно переходить к разработке. И не переделывать потом решение так, как кто-то из принимающих не так объяснил, а кто то из реализующих не так реализовал.
По итогу получится хорошая документация. В которую можно посылать будет направлять, что бы меньше задавали вопросов ;-)

Вот это всё рисование (у нас больше было текстовое описание) занимало у меня больше времени чем сделать MVP, а потом переделать… В разы больше времени — нифига я не художник мышкой. Под конец уже троллил откровенно: рисовал ручкой на бумажке, сканировал/фоткал и прикреплял к задаче

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Кипр
Сайт
www.exness-careers.com
Численность
501–1 000 человек
Дата регистрации
Представитель
Ekrutova

Блог на Хабре