Выбрасывая свой первый черновик работы - есть ли совместимая методология?

Question

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

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

Answer 1

Прототип , похоже, решает проблему каким-то образом. В статье в Википедии о прототипировании назван подход, называемый «Быстрое прототипирование», который, кажется, соответствует вашему образу мышления.

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Это именно тот аргумент, который Брюс Экель выдвигает здесь .