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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вариации на тему XP (Мартин Фаулер)
• Экстремальное программирование (различное на с2)
• Экстремальное программирование для одного (различное на с2)

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

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