Написание сырой реализации как части дизайна - хорошая идея?

Question

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

Итак, я думаю о чем-то вроде:

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

Существует ли методология программирования, которая поддерживает эту философию? Вы лично предпочитаете просто начать кодировать проблему или долго и усердно думать, прежде чем писать одну строчку кода?

Answer 1

Если вы измените «даже если вся работа пойдет напрасно» на «зная, что вся работа пойдет напрасно», вы говорите о прототипировании. Дело не в том, что вы не думаете о проблеме, вы просто знаете, что хотите решить ее один раз, прежде чем решите ее для всех.

Answer 2

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

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

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

Answer 3

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

Недавно я создал свое первое приложение командной строки в VB.NET (просто никогда не требовалось раньше). Было несколько частей, которые мне нужно было посмотреть, смогу ли я приступить к работе, поэтому я написал некоторый код, который даже был полностью переписан. После того, как я начал работать над вопросами, я начал больше планировать и разрабатывать полное приложение.

Answer 4

Я добавлю хорошую цитату, которую я нашел на этой ссылке :

Спайки хороши, когда вы ограничены знаниями, а не ограничены во времени. - КентБек

Answer 5

Во-первых, это называется «шип», и люди делают это постоянно.

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

Обычно я не пишу строку кода, пока не получу достаточно хорошее представление о том, что я делаю.

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

Answer 9

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

Answer 10

Что касается метода, я знаю, что eXtreme Programming использует такую ​​технику для исследования неизвестного домена и называет его spike solution .

ИМХО, это не должно быть предпочтительным способом реализации чего-либо; он должен использоваться, когда вам нужно узнать что-то, о домене, среде, инструментах ...

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

Иногда интересно реализовать его на другом языке, возможно, «проще» - например, читать на языке сценариев - чем желаемый язык.