Ez hitvita, azért dobtam be, hogy pörögjön a topik és a hup :-).
Véleményem szerint ...
(és ha megnézel ilyen progger influencereket, akkor láthatod, hogy nem vagyok egyedül ezzel a nézetemmel, de az is igaz, hogy nem mainstream)
... a pull request és a hozzá tartozó review csak lassítja a folyamatot, illetve valószínűbbé teszi, hogy lesznek konfliktok. Egyrészt egymásra kell várni folyton, másrészt pedig kontextusváltásra kényszerít mindenkit, illetve arra, hogy ne tudjon azzal foglalkozni amit a saját feladatának érez az ember. Szerintem a mostanában sokat emlegetett gyakori fejlesztői kiégés egyik oka a pull request, (illetve a sprintelgetés, de az egy másik téma).
A pull requestet arra találták ki, amikor totál ismeretlen harmadik fél kódját kell bevenni a rendszerbe. Egy csapatmunkában ha ilyenek a kollegák, az régen rossz. Azt el tudom fogadni, hogy egy újonc az első időkben csak egy senior segítségével kommittolhasson. De ha úgy marad, hogy nem tud önállóan kommittolni, akkor jobb inkább megválni tőle és kész.
Van olyan vélemény is, hogy a continuos integrationt ássa alá, hogy mindenkinek hosszú életű branchei vannak (a pull req-nak mindenképpen ez lesz a hatása, hogy hosszabbak lesznek a feature ciklusok), és emiatt nincsen egyben tesztelve a fejlesztők egymásra hatása.
Azt, hogy ne legyen törött a main branch, az biztosítja, hogy a kommit után gyorsan lefutnak a sanity checkek (jó esetben az összes teszt), és ha eltörik, akkor a fejlesztő hamar kikalapálja, mert tudja, hogy mit változtatott, ki kell tudnia jav javítani. Nyilván mindenki törekszik rá, hogy ne törje el az integratiönt és ez egy ritka esemény lesz.
Ehhez persze be kell vállalni, hogy néha törött lesz a main: szerintem ez nem tragédia. Mert mindig van egy utolsó működő, ilyenkor arra áll mindenki és tud dolgozni. (Jó eséllyel a többség észre se veszi, mert éppen feature branch-en dolgozik.) Nyilván kellemetlen ha délután 5-kor pusholunk és törjük el a maint, mert akkor illene bennmaradni ameddig helyre nem kalapáljuk. De ez az ár kisebb mint a pull req költsége összesen, és az se zárja ki teljesen, hogy eltörjön valami.
Ha nincs pull req-zás, akkor a fejlesztő tud kommittolni percek alatt, senkire nem kell várnia. És senki nem fogja zaklatni semmivel, amikor azt akarná csinálni, ami a saját célja (aktuális sprint vállalás, stb). A lényeg, hogy az ember ne legyen kizökketve abból a munkából amire éppen koncentrál. Ezzel a legjobb a szellemi erő kihasználása.
Ha együtt kell működni valamilyen célból, akkor is ezerszer jobb, hogy pikk-pakk betolhatja mondjuk az interfészt akinek az a dolga, a másik már csinálhajta is az implit. A kimaradt egymásra várásokkal napok megspórolhatók egy olyan helyzetben, amikor többszöri interakció eredménye az előre haladás.
Mivel mindenki gyorsan tud pusholni, az esetleges egymásra hatások, törések a lehető leghamarabb kiderülnek, gyorsan lehet javítani őket.
A review-ra pedig sokkal értelmesebb nagyobb darabokban review-zni mérföldkövekre. A változások merge-je felesleges mentális terhelés, mert 1-2 sorok kedvéért be kell cache-elni fejbe a kontextust amin valaki más dolgozott, tehát jó eséllyel fogalmunk sincs, hogy mi az és mi a célja. És a legtöbb programozó nem is fogja megtenni, és valójában a lényegi dolgok átsiklanak ezeken a reviewkon emiatt. Szemben a hülyeségekkel, amikbe bele fognak kötni, hogy mi a változó neve, meg van egy fölös space valahol.
Mi "lazy review" stratégiával összegyűjtünk sok változást és egyben review-zzuk. Erre elkülönített idő van, nincs stressz. Be kell cache-elni fejbe a kontextust, de van is értelme, mert nem 1 sor miatt tesszük, hanem több változás miatt egyszerre. A review-t mérföldkövekhez kötjük, akkor csináljuk meg, mondjuk egy release-hez. A review-nak ha az az eredménye, hogy szar, akkor piros lesz a kód a review reportban és egy külön kommitban javítjuk, majd újra reviewzzuk amíg jó nem lesz.
Olyan is sokszor van, hogy egy változást követ egy másik, ami felülírja. A köztes változatokat felesleges reviewzni, a végsőt kell. Ezért a "lazy review" stratégia ezzel is spórol.
A lazy review feladatra mi csináltunk egy saját eszközt, ami rendkívül egyszerű, és a fejlesztést nem akadályozza egyáltalán, viszont garantálja, hogy végül a kód review lefedettsége 100% lesz, és minden le van okézva a reviewer(ek) által.