Comments 3
Была подобная практика на одном проекте. Правда обычно без обсуждения с командой и командного ревью: архитектор ревьвил то, что вы называете техническим решением. Мне не понравилось — он требовал более детальных описаний, которые я предоставлял только уже решив задачу почти полностью и скопипастив код. Причём подходы у нас были разные и часто мне приходилось переделывать.
На сколько я понял смысл в том, что бы не переделывать ;-)
Сначала рисуется диаграмма последовательностей, потом алгоритм взаимодействия, потом входные/выходные параметры на каждом этапе и потом все это согласовывается. После апрува можно переходить к разработке. И не переделывать потом решение так, как кто-то из принимающих не так объяснил, а кто то из реализующих не так реализовал.
По итогу получится хорошая документация. В которую можнопосылать будет направлять, что бы меньше задавали вопросов ;-)
Сначала рисуется диаграмма последовательностей, потом алгоритм взаимодействия, потом входные/выходные параметры на каждом этапе и потом все это согласовывается. После апрува можно переходить к разработке. И не переделывать потом решение так, как кто-то из принимающих не так объяснил, а кто то из реализующих не так реализовал.
По итогу получится хорошая документация. В которую можно
Sign up to leave a comment.
Семь бед — один ответ: как мы решали проблему постоянных исправлений