Прототипирование против чистого кода на ранних стадиях


43

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

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

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

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


Ответы:


39

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

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

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

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

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


4
Хотя я не фанат полномасштабного TDD, это всегда хороший совет, так как следование TDD заставит вас писать чистый, хорошо документированный код.
Уэйн Молина

1
Я думаю, что он имел в виду, что он бросил бы весь проект, если он не сработает. Если это правда, то этот ответ не кажется отличным от «написать чистый код».
Джереми

@ Джереми, ты предполагаешь, что мой ответ прав. Но этот ответ не тот же. Он основан на строгом программировании, где другой основан на опыте, конечно, в некоторых случаях они похожи, но это не одно и то же :) ну, по крайней мере, с той точки зрения, которую я вижу :)
JackLeo

1
@JackLeo Я думаю, дело в том, что как только вы достигаете определенного уровня опыта, разница между «кодом, над которым я усердно работал», и «кодом, который я только что написал», перестает существовать.
Муравей P

@AntP Действительно. Интересно поразмышлять над этим вопросом 6 лет спустя :)
JackLeo

16

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

Это зависит

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

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

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


2
+1 Отличный пост! Я хотел бы добавить, что хотя это может показаться бесполезным после разработки этой функции, НИКОГДА не выбрасывайте свои прототипы. Я всегда контролирую каждый прототип, над которым работаю, потому что иногда я обращаюсь к ним за советами и подсказками.
maple_shaft

1
@maple_shaft: да, «выбрасывать» метафорически, как в «не обязательно пытаться реорганизовать его, планируйте переписать его»
Стивен А. Лоу,

2
Я говорю: «Ленись и напиши это хорошо в первый раз, чтобы тебе не пришлось возвращаться и возвращаться к нему позже».
Blrfl

3-е предложение сделало мой день.
Кристофер Франсиско

10

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

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

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

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

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


+1 Очень хороший ответ :) это случилось со мной в первые дни, поэтому прыжки на больших проектах могут вызвать то же самое ... вот чего я боюсь.
JackLeo

«Как разработчики программного обеспечения, мы настолько увлечены правильной работой и чистотой с первого раза, что не понимаем, что это не код, который мы поставляем, а решение проблемы». Я бы сказал, что все наоборот: «У нас никогда нет времени, чтобы сделать это правильно, но у нас всегда есть время, чтобы сделать это заново».
Кристофер Франциско

6

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

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

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

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


Очень хороший момент, это для того, чтобы показать различные типы прототипов, я не думал об этом :) Пища для меня здесь для меня :)
JackLeo

Согласитесь с точкой!
Ричард Топчий

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

5

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


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

Вы получили хорошее замечание - "зачем переписывать, если это работает?" это проблема для многих молодых компаний, я вижу это даже в моей нынешней должности, когда огромные компании используют 10-летнюю CMS, которая болезненно обновляет до современных стандартов ... Вот почему я задаю такой вопрос, я не Я не хочу делать ошибку здесь. Хотя ваш ответ в основном говорит о том, что я ищу предлог для написания неаккуратного кода. Нет. Sunpech и M.Sameer поняли мою точку зрения. Прототип - это сделать что-то, чтобы увидеть, как на это отреагирует мир. Если это работает - сделай это хорошо.
JackLeo

1

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


0

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


этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
комнат

Можете ли вы предложить, что вы думаете, в чем проблема? Возможно, предложения слишком длинные, как я только что заметил, их всего два. Что-нибудь еще?
Том W

-1

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


-1

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

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

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

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


-2

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.