Экстремальное программирование для одного разработчика [закрыто]


10

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

  • Непрерывная интеграция
  • Никогда не добавляйте функциональность рано
  • Разработка через тестирование
  • Выберите системную метафору
  • Используйте одну точку интеграции
  • Проверьте все ошибки
  • Постоянно рефакторинг
  • Установить устойчивый темп
  • Простота
  • Частые выпуски

Мне любопытно, если мне не хватает чего-то конкретного, что может подойти для работы с одним проектом разработчика?

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

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


5
Elsesite, на c2.com (сайт, созданный на ранней стадии для обсуждения гибких (и особенно XP) концепций) - Extreme Programming For One

Это удивительный ресурс, спасибо. Мне особенно нравится идея XP клятвы верности.
Коди Манхарт

Если вы читали внимательно, вы найдете такие имена, как Рон Джеффрис и Кент Бек комментирующих ... и хорошо, что это вики Уорда .

Так что это написано создателями парадигмы, это фантастика. Не знаю, как я еще не наткнулся на это. Я использовал www.extremeprogramming.org
Коди Манхарт

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

Ответы:


5

В конечном счете, экстремальное программирование - это набор практик и методологий, которые ведут к повышению ценности бизнеса. Лучшая иллюстрация этого, которую я нашел, взята с http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart

Возможность экстремального программирования

Все в синем является частью ядра XP.

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

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

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

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

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

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

Связанное чтение:

Я хотел бы получить цитату из первой ссылки c2:

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


Просветление, если не сказать больше. В настоящее время я занимаюсь вопросами с точки зрения TDD, во Flash с использованием Starling. Я использую FlexUnit, и у него нет возможности обрабатывать графическое тестирование, поскольку он безголовый. Было бы целесообразно в таких случаях просто делегировать эти тесты ручным проверкам (например, является ли тест для логотипа центрированным на экране). Будет ли это рассматриваться как интеграционное тестирование? (т.е. правильно ли работает модуль экрана-заставки со сценическим модулем Flash?) Должен ли я использовать макет для моделирования требуемой ситуации? Могут ли тесты быть чисто эфирными конструкциями?
Коди Манхарт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.