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

Я знаю, що в комерційній розробці є великий поштовх для перегляду коду. Однак чи використовуються огляди коду у програмному забезпеченні з відкритим кодом або ґрунтуються на довірі? Якщо так, то як вони виконуються? [Чи є відкладений фіксатор, "середовище, яке попередньо виконує", чи є інструмент, який дозволяє відправити виправлення на інший розробник?

Чи є проекти, які використовують огляди коду?

З мого розуміння, ядро ​​Linux в основному базується на довірі комітента. MySQL базувався на схваленні головного автора та впливовості на продуктивність.

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

Що стосується інструментів, то для хорошого прикладу подивіться механізм запиту на тягу на github. Ви робите запит на притягнення, і на веб-сторінці, присвяченій цьому запиту на притягнення, люди роблять коментарі, а автор вносить зміни до тих пір, поки це не стане достатньо прийнятим Інші воротарі просто використовують звичайний git, щоб застосовувати виправлення із списків розсилки або об'єднувати запити на витяг із загальнодоступних сховищ, що є однією з головних причин DVCS, таких як git.

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

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

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

Ось декілька швидких посилань на приклади спільних документів для проектів, які я найкраще знаю, де ви можете знайти відповіді на своє запитання, характерне для цих проектів (незабаром ви помітите тему):

• Принципи спільноти Blacklight проекту
• Настанови щодо внесення коду DSpace
• Технічний посібник для авторів Apache

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

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