Есть ли обзоры кода в проектах с открытым исходным кодом? Если да, какие инструменты используются для этого?

Я знаю, что есть большой толчок для обзоров кода в коммерческой разработке. Однако используются ли обзоры кода в программном обеспечении с открытым исходным кодом или основаны на доверии? Если так, то как они выполняются? [Является ли это отложенной фиксацией, «средой предварительной фиксации», есть ли инструмент, позволяющий отправлять патч другому разработчику]?

Есть ли проекты, которые используют обзоры кода?

Из моего понимания ядро ​​Linux в основном основано на доверии к коммиттеру. MySQL был основан на одобрении основного автора и влиянии на производительность.

Почти все проекты с открытым исходным кодом используют какой-то рабочий процесс привратника, когда человек или группа людей должны подписать все изменения, чтобы перейти к официальной сборке. Некоторые крупные проекты, такие как ядро ​​Linux, имеют уровни привратников. Вы отправляете изменения кому-то, кто управляет областью подсистемы, они отправляют свои изменения кому-то, кто управляет всей подсистемой, и они отправляют свои изменения Линусу Торвальдсу, который иногда сам просматривает код или иногда доверяет своим лейтенантам. Эти обзоры обычно не имеют формальной структуры. Это просто кто-то просматривает код, прежде чем он будет объединен.

Что касается инструментов, посмотрите на механизм запросов на получение запросов на github для хорошего примера. Вы делаете запрос на извлечение, и на веб-странице, посвященной этому запросу, люди комментируют, а автор вносит изменения, пока он не станет достаточно хорошим для принятия. Другие привратники просто используют обычный git для применения исправлений из списков рассылки или объединения запросов на извлечение из общедоступных репозиториев, что является одной из главных причин, по которой были изобретены такие DVCS, как git.

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

Что касается проверки кода, опять же, это зависит от сообщества, но руководящие принципы часто разъясняются. Некоторые примерные рекомендации для вкладов, не принадлежащих коммиттерам, варьируются от «выигрышей рабочего кода» до «вкладов должны иметь полное покрытие тестами и документацию с тестами, выполняемыми одновременно с кодом» и всем, что между ними; Независимо от этих руководящих принципов, единственное подразумеваемое руководство заключается в том, что основные коммиттеры рассмотрят любой и все вклады не-коммиттеров, прежде чем их принять.

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

Вот несколько быстрых ссылок на некоторые примеры документов сообщества для проектов, которые я знаю лучше всего, где вы можете найти ответы на свой вопрос, относящийся к этим проектам (вы скоро заметите тему):

• Принципы сообщества проекта Blacklight
• Рекомендации по внесению кода в DSpace
• Техническое руководство для разработчиков Apache

Крупные проекты OSS будут иметь ряд основных коммиттеров. Так что, я думаю, они де-факто "рецензенты кода".

Кроме того, поскольку код OSS по своей природе открыт для всех, вероятно, будет гораздо больше дискуссий по поводу кода, который вы пишете. Хотя это может быть не в форме формальных проверок кода, вы наверняка узнаете, не рассматривается ли ваш код с нуля для конкретного проекта OSS.