Я планирую работать / начать над несколькими личными проектами, которые могут закончиться моей повседневной работой. Это заставило меня задуматься, с чего начать?

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

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

Обновление: Сочетание YAGNI с ответами sunpech и M.Sameer имеет для меня смысл :) Спасибо всем за помощь.

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

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

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

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

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

как обычно...

Это зависит

Если вы создаете прототип для снижения риска или выявления неизвестного, просто закодируйте его и ожидайте выбросить, когда закончите

Если вы создаете прототип для итеративного уточнения, просто закодируйте его и ожидайте частого изменения и рефакторинга

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

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

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

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

Я думаю о кодировании, как о написании статьи:

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

Существует два типа прототипирования:

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

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

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

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

Пишите чистый, оптимизированный и документированный код с самого начала. Я не в состоянии сделать это сам, и это настоящая проблема. Я не программист, но я довольно много работал для компаний-разработчиков программного обеспечения, выполняя задачи, связанные с управлением, и, поскольку они дают мне много хороших идей, я иногда создаю для чего-то прототип. Почти каждый раз этот прототип затем передавался разработчику, который «очистил его» и превратил в отгрузочный продукт. Когда я проверю источник, он все равно будет на 80-90% моим дерьмовым кодом.

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

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

Оба хорошие. Оба мне нравятся. Они не противоречат друг другу.

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

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

Но вы никогда не должны путать прототип с рабочим кодом. Прототип никогда не должен идти в производство. Следует всегда отмечать как прототип. В лучшем случае делайте все прототипы в своей собственной ветке.

Я склонен говорить, что крайности почти всегда плохие.

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

Из моего собственного опыта большая часть кода не живет очень долго. Тем не менее, начните работать быстрее, внедрив свою функцию. Когда рано или поздно (в большинстве случаев раньше) вам необходимо переделать / реорганизовать существующий код из-за следующей функции, которую вы убираете, особенно части, с которыми сложно работать. Обратите внимание на наличие надлежащих автоматических тестов, чтобы сделать беспроблемный рефакторинг возможным. Относительно вышеупомянутых платформ, таких как Android: часто они делают автоматизированное тестирование не таким простым из-за тесной связи и отсутствия дизайна для тестирования. Затем вы можете поднять свою тестовую базу на более высокий уровень, например, интеграционное тестирование.

Я написал статью, которая может дать некоторые подсказки о запуске: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d