Документирование и получение одобрения перед началом написания кода?

Question

Недавно наш начальник изменил наш метод работы на первый документ, такой как то, что мы собираемся кодировать, как это повлияет на системный код, где мне потребуется внести изменения и т. Д., Получить его одобрение и затем начать процесс кодирования.

Я считаю, что, хотя иногда лучше планировать вещи и визуализировать вещи (особенно для сложных изменений), в большинстве случаев гораздо лучше напрямую кодировать в приложение и сталкиваться с реальными сценариями, а не теоретизировать.

Верна ли моя вера в этом случае?

Answer 1

Это почти полностью зависит от того, почему ваш начальник принял эту политику. Если это потому, что вы кучка ковбоев, которые выкладывают глючный код в производство, не зная, что это значит для пользователя (и репутации вашей компании), ваш босс, вероятно, прав.

Если это из-за того, что вошел какой-то орган с шестью сигмами и сказал вашему боссу, что это правильный путь, я буду осмотрительным.

Как всегда, это зависит от обстоятельств (а вы на самом деле не рассказали нам всю картину). В любом случае, опыт нескольких десятилетий научил меня, что всегда есть способы обойти произвольные ограничения, если вы достаточно умны:-)

Пример: хотя нам не разрешено кодировать новые функции без финансирования, мы можем (как среда лабораторного типа) собрать PoC (доказательство концепции) в нашем собственном центре, а затем обнаружить, что это удивительно легко чтобы получить это к качественному решению.

Answer 2

Я должен пойти с твоим боссом на этот. Вы действительно должны знать ответы на:

• Что (в основном) я собираюсь кодировать?
• Почему я пишу этот код?
• Какие риски связаны с написанием этого кода?

Если вы не можете ответить на эти вопросы, вероятность того, что вы

• приходится несколько раз пытаться получить код, который решает проблему
• написать ненужный код
• сломать что-то

Кроме того, ответ на эти вопросы позволит вам написать тесты, необходимые для нового кода. Вы пишете тесты, верно?

Answer 3

У меня есть оговорка о том, что для этого требуется процесс утверждения, но то, что вы описываете, очень похоже на документ по архитектуре решения.

Я не думаю, что начальник не согласен с запросом об этом, пока уровень детализации является широким и общим. Определение того, как и где вы собираетесь реализовать решение, наряду с демонстрацией того, что вы продумали различные возможные подходы к проблеме, является, пожалуй, хорошей практикой, особенно в больших системах.

По сути, это демонстрирует, что вы проявили должную осмотрительность и приложили некоторые усилия и усилия для поиска наилучшего возможного решения бизнес-проблемы.