Czy w projektach typu open source są recenzje kodu? Jeśli tak, jakie narzędzia są do tego wykorzystywane?

Wiem, że istnieje duży nacisk na recenzje kodu w rozwoju komercyjnym. Czy jednak recenzje kodu są używane w oprogramowaniu typu open source, czy są oparte na zaufaniu? Jeśli tak, to w jaki sposób są one wykonywane? [Czy jest to opóźnione zatwierdzenie, „środowisko przed zatwierdzeniem”, czy istnieje narzędzie, które pozwala na przesłanie łaty do innego programisty]?

Czy są jakieś projekty korzystające z recenzji kodu?

Z mojego zrozumienia, jądro Linuksa opiera się głównie na zaufaniu osoby odpowiedzialnej. MySQL został oparty na aprobacie głównego autora i wpływie na wydajność.

Prawie wszystkie projekty open source używają pewnego rodzaju przepływu pracy strażnika, w którym osoba lub grupa osób musi podpisać się przy wszystkich zmianach, aby przejść do oficjalnej wersji. Niektóre większe projekty, takie jak jądro Linuksa, mają warstwy strażników. Przesyłasz zmiany do kogoś, kto zarządza obszarem podsystemu, a on przesyła swoje zmiany do kogoś, kto zarządza całym podsystemem, i wysyłają zmiany do Linusa Torvaldsa, który czasami sam sprawdza kod lub czasami ufa swoim porucznikom. Przeglądy te zwykle nie mają formalnej struktury. To tylko ktoś, kto ogląda kod, zanim zostanie scalony.

Jeśli chodzi o narzędzia, spójrz na mechanizm żądania ściągania na github, aby uzyskać dobry przykład. Składasz żądanie ściągnięcia, a na stronie internetowej poświęconej temu żądaniu ściągasz komentarze, a autor dokonuje poprawek, dopóki nie będzie wystarczająco dobry do zaakceptowania. Inni strażnicy używają zwykłego gita do nakładania łatek z list mailingowych lub łączenia żądań ściągania z publicznych repozytoriów, co jest jednym z głównych powodów wynalezienia DVCS takich jak git.

Projekty typu open source często mają (i powinny, jeśli nie mają) jasno opublikowany zestaw „wytycznych dla społeczności”, który często zawiera opis przepływu pracy w projekcie oraz sposób, w jaki wkłady są akceptowane (a tym samym sposób ich testowania), a także jako proces stawania się głównym sprawcą.

Jeśli chodzi o przegląd kodu, znowu zależy to od społeczności, ale wytyczne są często wyjaśnione. Niektóre przykładowe wytyczne dotyczące wkładów podmiotów niebędących osobami zatwierdzającymi obejmują zakres od „wygranych działającego kodu” do „wkłady muszą mieć pełne pokrycie testowe i dokumentację, przy czym testy są przeprowadzane w tym samym czasie co kod” i wszystko pomiędzy; bez względu na te wytyczne sugeruje się, że główni podmioty przekazujące dane przed dokonaniem ich przeglądu dokonają przeglądu wszelkich wkładów podmiotów niebędących podmiotami zobowiązującymi.

Projekty open source z grupami głównych podmiotów przekazujących często również odbywają wirtualne spotkania lub poświęcają czas na omówienie wszelkich uwag, które mogą wymagać dodatkowych zestawów oczu - podobnie jak proces SE polegający na wielokrotnym głosowaniu przez użytkowników o określonej reputacji przed zamknięciem pytania, oraz dyskusje na temat wątpliwych rzeczy za pośrednictwem meta lub czatu.

Oto kilka szybkich linków do przykładowych dokumentów społecznościowych dla projektów, które znam najlepiej, gdzie możesz znaleźć odpowiedzi na swoje pytanie dotyczące tych projektów (wkrótce zauważysz motyw):

• Zasady społeczności projektu Blacklight
• Wytyczne dotyczące wkładu kodu DSpace
• Przewodnik techniczny dla twórców Apache

Większe projekty OSS będą miały szereg głównych podmiotów odpowiedzialnych. Sądzę więc, że są de facto „recenzentami kodu”.

Ponadto, ponieważ kod OSS jest z natury otwarty dla wszystkich, prawdopodobnie będzie więcej dyskusji na temat pisanego kodu. Chociaż może to nie mieć formy formalnego przeglądu kodu, z pewnością dowiesz się, czy Twój kod nie jest brany pod uwagę w konkretnym projekcie OSS.