Ковбойское кодирование

редактировать

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

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

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

Содержание
  • 1 Недостатки
    • 1.1 Отсутствие структуры выпуска
    • 1.2 Неопытные разработчики
    • 1.3 Неопределенные требования к проекту
    • 1.4 Неполнота
  • 2 Преимущества
  • 3 См. Также
  • 4 Ссылки
  • 5 Внешние ссылки
Недостатки

В ковбойском кодировании отсутствие формальных методологий управления программными проектами может указывать (хотя и не обязательно) на небольшой размер проекта или экспериментальный характер. Программные проекты с этими атрибутами могут демонстрировать:

Отсутствие структуры выпуска

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

Неопытные разработчики

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

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

Неопределенные требования к дизайну

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

Неполнота

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

Преимущества
  • Разработчики поддерживают свободную форму. рабочая среда, которая может поощрять эксперименты, обучение и бесплатное распространение результатов.
  • Это позволяет разработчикам пересекать архитектурные и / или многоуровневые границы для устранения проектных ограничений и дефектов.
  • При обсуждении архитектур, написании спецификации и проверка кода требуют своего времени, один разработчик (если его достаточно) может быстрее создать хорошо работающее приложение с помощью ковбойского кодирования. Такие задачи, как исследование или создание прототипов, могут не требовать качества кода, обеспечиваемого более сложными методами.
  • Поскольку кодирование может выполняться в свободное время разработчика, проект может быть реализован, чего в противном случае не было бы.
См. также
Ссылки
  1. ^Хьюз, Боб и Коттерелл, Майк (2006). Управление программными проектами, стр.283-289. McGraw Hill Education, Беркшир. ISBN 0-07-710989-9
  2. ^«В защиту водопада: разбирая манифест Agile» (PDF). Получено 1 февраля 2016 г.
  3. ^«StickyMinds - STAREAST 2000: Признания (восстанавливающегося) ковбоя-программиста». StickyMinds. Проверено 2 февраля 2016 г.
  4. ^«Изучение гибкой разработки». Информационный бюллетень Pragmatic Software.
  5. ^«StickyMinds - Не просто ломайте программы. Создавайте программы». StickyMinds. Проверено 2 февраля 2016 г.
  6. ^K, Alex. «20 процентов времени Google в действии», официальный блог Google, 18 мая 2006 г.
Внешние ссылки
Последняя правка сделана 2021-05-16 07:19:57
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте