Сколько деталей нужно внести в первую итерацию проекта?

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

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

1. С самого начала напишите тщательный, высококачественный код со всеми обработками исключений и такими, которые, как вы знаете, вам в конечном счете понадобятся.

2. С самого начала напишите черновой набросок с минимальной работоспособностью, а затем зайдите, чтобы заполнить все детали позже.

Смежный вопрос: когда можно пожертвовать «аккуратностью» дизайна, чтобы завершить проект?

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

Конечный результат

Вы пишете управляющее программное обеспечение Mars Orbiter? Тогда вам лучше быть уверенным, что вы пишете максимально надежный код, лучше проверить, что каждое исключение обрабатывается в здравом смысле.

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

Как вы ожидаете туда добраться?

Занимаетесь ли вы интенсивным освоением водопада, где вы тратите много времени на выяснение того, что нужно, а затем уйдете на месяцы, развиваясь? Если это так, то вы хотите достичь указанного выше целевого качества довольно рано. С самого начала спланируйте всю свою инфраструктуру проверки ошибок.

Занимаетесь ли вы интенсивной гибкой разработкой, когда вы собираете что-то вместе в течение недели или двух, которые затем будут показаны заинтересованным сторонам, которые могут попросить о радикальных изменениях, и где вы ожидаете, что сможете выполнять многократные 1-2 спринта? пока не попал в цель? Тогда вам, возможно, будет лучше, если вы что-то сработаете, но быстро ломаетесь и добавляете только ремни и подтяжки, когда требования к продукту укрепляются.

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

Теперь найдите свой ответ

Для большинства ответ будет лежать где-то посередине. Ответьте на оба вопроса о вашем проекте, и он должен привести вас в основное русло.

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

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

Все концепции и шаблоны разработки программного обеспечения и кодирования возникают в ответ на некоторые проблемы. Шаблон или концепция является решением этой проблемы. Со временем некоторые шаблоны становятся «общеизвестными» в качестве предпочтительных решений, поскольку они решают проблему способом, который удовлетворяет определенным требованиям по согласованности, привычности, производительности, ремонтопригодности и т.

Из этого следует, что если проблема, которую должен решить программный шаблон, не существует в вашем конкретном программном обеспечении, то вам не нужен этот шаблон. Кроме того, любые обсуждения шаблонов, которые могут понадобиться вашему программному обеспечению, должны также включать подробные обсуждения предлагаемого программного обеспечения: что оно должно делать? Какую проблему это решает? Сколько будет пользователей? Будут ли пользователи каким-либо образом обмениваться данными? И так далее.

Проблема, которую должны решать исключения, заключается в том, что когда происходит что-то, с чем код ничего не может сделать. Примером может служить операция «Файл / Открыть», в которой указано имя файла, которого нет на носителе данных. Исключения дают коду способ сказать вызывающей стороне: «Произошло что-то, что мешает мне продолжить, и я ничего не могу с этим поделать, поэтому я сдаюсь». Если в вашем коде нет мест, где существуют подобные условия, исключения не нужны. Или вы можете просто вернуть код ошибки и вообще избежать исключения.

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

Существует очень простой и практичный подход к этому, который работает для широкого спектра малых и средних проектов. Даже при том, что это вероятно не будет хорошо работать для Исследователей Марса.

Сначала определите, что вы хотите, чтобы система делала, и запишите все отдельные функции. Это может быть как изощренная доска объявлений, так и несколько простых пунктов, набросанных на листе бумаги перед вами. Но важно, чтобы вы знали, чего вы хотите от этого.

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

Из всех этих функций определите, что является ключевым для программы - основные функции.

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

Как только основные функции реализованы, я обычно стараюсь использовать систему как можно ближе к производственной среде. Это дает вам a) любые ошибки, которые вы, возможно, пропустили ранее, и b) вы получите хорошее представление о приоритете следующих функций.

Затем вы можете продолжить реализацию оставшихся функций по мере необходимости.

Качество кода и особенности

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

А как насчет обработки исключений?

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

Однако существует минимальное требование для исключений: убедитесь, что пользователь уведомлен, если что-то пойдет не так - независимо от того, насколько уродливым может быть вывод. Не глотайте исключения где-нибудь.