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


10

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

  • Постійна інтеграція
  • Ніколи не додайте функціональність на початку
  • Тест-керований розвиток
  • Виберіть системну метафору
  • Використовуйте єдину точку інтеграції
  • Перевірте всі помилки
  • Постійно рефактор
  • Встановіть стійкий темп
  • Простота
  • Часті випуски

Мені цікаво, якщо я не пропускаю нічого конкретного, що могло б бути придатним для роботи з одним проектом розробників?

Крім того, зважаючи на ідею простоти та тестового розвитку, чи краще використовувати створені, багатофункціональні готові платформи?

Або я повинен працювати з нуля, коли це можливо, щоб не стикатися з проблемами, представленими такими правилами, як постійне рефакторинг і ніколи не додавати функціональність на ранніх термінах?


5
Elsesite, на c2.com (веб-сайт, створений рано для обговорення спритних (і особливо XP) концепцій) - Екстремальне програмування для одного

Це дивовижний ресурс, дякую. Особливо мені подобається ідея XP Залог вірності.
Kody Manharth

Якщо ви читали уважно, ви знайдете такі імена, як Рон Джеффріс і Кент Бек коментують ... і добре, що це вікі Уорда .

Так це написано творцями парадигми, це фантастично. Не знаю, як я ще не наткнувся на це. Я використовував www.extremeprogramming.org
Kody Manharth

2
У вашому запитанні немає жодної кулі, яка б була обов'язковою для успішної розробки програмного забезпечення. Справжнє питання: які з них вам насправді потрібні?
Роберт Харві

Відповіді:


5

Зрештою, Екстремальне програмування - це сукупність практик та методологій, що призводять до поліпшення вартості бізнесу. Найкраща ілюстрація цього, що я знайшов, - з http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart

Екстремальна програма програмування

Все в синьому кольорі є частиною ядра XP.

Є його частини, які знаходяться на його стороні, які допомагають ввімкнути речі в межах синьої області і є частиною XP в цілому, але не є критично важливим для цього. Зауважте, що я особисто не є практикуючим XP, і я прочитав неабияку критику людей, «майже» після XP, про які різні люди говорили, що це не XP. Давайте трохи відведемо цей аспект догми про XP і подивимось, що ми маємо.

Зрозумійте, що одне з перших, і для більшості речей - це зобов’язання клієнта про процес. Ключовим компонентом XP є залучення замовника. Це відображається в багатьох місцях, таких як планування випуску, невеликі випуски, оцінка покупців за межами місця. Це речі, на які вам потрібно буде підписатися, якщо ви збираєтеся досягти успіху в XP як соло-розробник. Якщо вони запитують замість дизайну, а потім періоду розробки, а потім тестування тощо, ви не будете зобов’язатись іти далі.

XP не означає ніякого планування. У цьому є кілька моментів, де планування є частиною цього - визначення пріоритетності, оцінка історій користувача, планування ітерації та визначення завдань. Незважаючи на те, що ви один розробник цього питання, вам знадобиться співпрацювати зі своїм замовником над доставкою.

Такі точки, як колективне володіння кодом та парне програмування - це речі, які передбачають більше одного. Вирішити такі речі, як стандарти кодування, набагато простіше, але це не означає, що вам не доведеться їх виконувати. Право власності на колективний код все ще застосовується - його лише те, що право власності також є наступним розробником - не пишіть код, який призначений для вас і для вас одного. Зауважте, що це в певній мірі суперечить "коду розкриває всі наміри", який увімкнено парним програмуванням - у вас немає такої особи, щоб перевірити, чи пишете ви рентабельний код, тому документація коду також є критичною.

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

Зрозумійте, що персональний XP займає стільки ж або більше дисципліни, як звичайний XP. XP часто вважають методологією високої дисципліни, оскільки він вимагає від людей суворого дотримання кращих практик, які він намагається втілити. Якщо у вас немає тренера чи інших людей, які б підтримували цю дисципліну, яка потрібна, вона може перетворитись лише на практику, що нагадує XP.

Пов'язане читання:

Я хотів би витягнути цитату з першого із c2 посилань:

Відзначений світилом мови Perl та божевільний вчений, Даміан Конвей вважає, що Екстремальне програмування насправді є неправильним. Оскільки він уособлює багато хороших практик програмування, яких навчають програмістів, але майже напевно ігнорують, він вважає, що це справді повинно було називатися ультраконсервативним програмуванням


Найменш просвічуюче. В даний час я маю справу з питаннями щодо TDD, у Flash, використовуючи Starling. Я використовую FlexUnit, і він не має можливості обробляти графічне тестування, оскільки він без голови. Чи було б доцільним у таких випадках просто делегувати ці тести вручну (наприклад, тест на логотип зосереджений на екрані.) Чи вважатиметься це тестуванням інтеграції? (тобто належним чином модуль екрану заставки працює зі сценічним модулем Flash?) Чи повинен я використовувати глузливий фреймворк для імітації необхідної ситуації? Чи можуть тести бути чисто ефірними конструкціями?
Kody Manharth
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.