Чи парне програмування усуває необхідність перегляду коду в проекті Extreme Programming (XP)?


14

У проекті екстремального програмування програмісти проводять парне програмування більшу частину часу.

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

Отож, чи є необхідність у перегляді кодів? Я маю на увазі, перестань програмувати і насправді просто робити огляди коду.


3
Парне програмування є лише орендарем XP. Існує багато інших гнучких методологій, які не відповідають XP. Ні в " Маніфесті розробки Agile Software", ні в Принципах Agile Manifesto немає нічого, що зазначає програмування пар. Про відгуки про код також немає нічого. Важливо не вважати, що всі спритні є крайніми.

Дозвольте перефразувати своє запитання, щоб потім включати лише XP.
Едуардо Копат

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

Відповіді:


13

Одним з ключових ресурсів для екстремального програмування є ресурс Ward's Wiki aka Portland Pattern Repository aka C2.com . Саме тут низка людей викреслила різні методології та задокументувала їх під час їх використання.

У цій вікі є сторінка: Рецензії кодексу програм екстремального програмного забезпечення, на яку є кілька учасників, зокрема Рон Джеффріс та Кент Бек.

На це вони сказали:

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

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

ExtremeProgramming вимагає, щоб усі об'єкти мали UnitTests. Вони гарантують, що об’єкт працює і продовжує працювати як змінений.

Деякі мови є рефлексивними. На таких мовах UnitTests можуть безпосередньо перевіряти відповідність важливим стандартам. (наприклад, об'єкти повинні реалізовувати і # = і #hash, або ні.)

ExtremeProgramming практикує CollectiveCodeOwnership, що означає, що об’єкти, які потребують уваги, переглядають багато розробників. Це, як правило, чинить тиск на ті, хто виробляє код, який не відповідає стандартам. Відвідувачам розробникам рекомендується / очікується, що вони приведуть код у відповідність, коли виявлять відхилення. Це також забезпечує розповсюдження знань про код за межами початкової пари програмістів, які його створили.

Тому проекти ExtremeProgramming не потребують явного перегляду. Відкиньте їх зі своєї методології.

Існує також трохи більше обговорень на цю тему від інших.

Ключові моменти, однак, полягають у тому, що за допомогою поєднання тестів, спільної власності та парного програмування ці речі вирішують цілі, які, як правило, мають робити огляд коду, такі як:

  • Розсіюйте знання про те, що робиться
  • Другий (або більше) набір очних яблук на коді, щоб переконатися, що він відповідає стандартам
  • Перевірте правильність функціонування коду

Це робиться постійно за допомогою парного програмування та автоматизованого тестування в екстремальному програмуванні, і тому явна перевірка Фагана не потрібна.

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


4
В іншому питанні я стверджував, що огляд коду - це непотрібна трата (у пісному значенні цього слова), і що програмування пар повинно бути кращим методом надання всіх переваг, які надасть огляд коду. Потрібно сказати, що люди образилися на мій аргумент, тому що я не підкріпив це голосом влади, як у вас. Для групи людей, які щодня щодня займаються логікою, ми - нелогічна купа.
Майкл Браун

6
Ризик робити парне програмування без додаткових перевірок коду полягає в тому, що обидва програмісти сильно задіяні на момент написання, і вони можуть писати код, який здається цілком зрозумілим і логічним на той час, але менше, коли їх знову побачать через кілька днів. Наскільки великий та / або прийнятний цей ризик залежить від вашої організації.
Барт ван Іґен Шенау

@MikeBrown ви можете в рівній мірі стверджувати, що програмування пар - це непотрібна трата, і перегляд коду повинен і т. Д.
AlexFoxGill

Подивіться, що я мав на увазі під ВІДХОДЖЕННЯМИ - це «худорляве» визначення цього слова. Подумайте про типовий процес складової лінії. Ідея полягає в тому, щоб якнайшвидше виїхати на автомобіль і перевірити якість після факту (перевірка коду). Принципи схильності дотримуйтесь трохи більше часу та зусиль, щоб створити якість (парне програмування), так що після перевірки стає непотрібним.
Майкл Браун
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.