Meg ha nem is kituntetett fejlesztok hagyjak jova, hanem csak a manyeyeball elvet akarjak ilyen modon kikenyszeriteni, szerintem akkor is karos. Mindenkinel idot es energiat von el a fontosabb dolgokra koncentralastol. En azt gondolom, hogy senki sem azert lesz fejleszto, hogy a nap nagy reszeben kodokat vagy bugokat nezegessen at. Ez egyfelol idegorlo, masfelol egyaltalan nem hatekony.

En azt gondolom, hogy mindenki legyen igenyes a sajat munkajara. Buildeljen, teszteljen, ha kell futtassa a code quality ellenorzeseket is, tegyen meg mindent azert, hogy kifogastalan legyen a kodja, es ha vegzett, akkor gondolkozzon el a commiton. Nem veletlen, hogy en a sajat projektemben tul azon, hogy letesztelem a kodjaimat, egy pre-commit hook meg egyszer lefuttatja a _megfelelo_ teszteket, hogy biztos jo kod menjen be a faba. Sokszor egy utolag megtett “kis” modositas torte volna el az egesz kodot (pl valahol lehagytam egy zaro zarojelet, a javitasban pedig veletlenul kettot tettem, es nem vettem eszre, mert volt ott mar harom).

Egyetértek Veled abban, hogy nem szabad hagyni, hogy emberek szűk keresztmetszetek legyenek egy ilyen folyamatban. Automatizálni kell mindent. Statikus kódelemző eszközök, azokhoz bevezett automatikus szabályok, automatizált tesztek kellenek.

Szerintem motivációs szempontból sem annyira jó, ha a fejlesztők között vannak kitüntetettek, akik jóváhagyják mások munkáját.

Én szerencsésebbnek tartom azt a modellt, hogy több kis csapat van, mindegyik csapathoz dedikált projekt tartozik, amiért az a csapat felel. A csapatnak (katonai kifejezéssel) képessége, hogy a projektet szállítani tudja, tehát (Scrummal élve) keresztfunkcionálisak. Ezek a projektek nem hierarchiába vannak szervezve, hanem egymás mellett léteznek.

Véleményem szerint ugyanaz a nagyobb projekt ilyen módon szervezve sokkal kevesebb emberből megvalósítható, mert az egyes csapatokon belül a motiváció és összetartás sokkal erősebb, mintha az lenne, hogy egy nagy “masszában” a mindenféle szinteken a problémákat menedzserek probálnák kezelni.

De egy ilyet megvalósítani szerintem sokkal nehezebb, mert felülről kell egy megfelelő rálátás a csapatoknak a kialakításához, a nagy projekt megfelelő szétvágásához, és ehhez igencsak kevesen értenek. A csapatoknak motiváltaknak kell lenniük a saját fejlődésükben, ehhez motiváló munkakörülményeket is kell teremteni. Erre kevés menedzsment képes, és ez már a tulajdonosokon is múlik, hogy a cég milyen vízióval rendelkezik. Csak a pénzt hajhássza, vagy esetleg értéket is akar teremteni az emberek számára.

Ha nem tudják megvalósítani, akkor kialakul a droid modell, amiről Te írtál.

Nagy, nyílt forráskódú fejlesztéseknél is ugyanez a helyzet.

Ha tökéletes az SRP szerint az osztályunk felelőssége, nem biztos akkor sem, hogy érdemes mindent tagváltozóba bevinni, mert a legtöbbször az osztályon belüli metódusok hívási sorrendje nem mindegy, és ezt a rejtett időbeliség (Hidden Temporal Coupling) jó paraméterátadással explicitté tenni.

Ha most írnám a cikket, ez nem kerülne bele a TOP 5-ba

Szerintem amúgy a sok paraméter mindenképpen problémát jelöl, de szerintem sok esetben nincs rá normális megoldás a technológiai integrációs problémák és a nyelvi korlátok miatt.

- “The only way to go fast is to go well” (Robert C. Martin)

- ASAP is poison. (Rework c. könyv)

Elvileg előfordulhat az, hogy egy kiterjedtebb grid esetében, ami végzi a tesztek futtatását, a tesztkörnyezetekbe deployálást és/vagy futtatást, hogy “szétcsúszik valami” (pl. nem ugyanaz a fordító van jelen mindenhol). Vagy mondjuk a környezetek más dologban különböznek, és emiatt a build eredménye is más lesz.

Ez persze egy javas/C#-os platformon nem annyira jellemző, de mondjuk egy C/C++-os közegben már sokkal inkább számít. Oprendszer verziója, oprendszeren lévő update-ek verziója, 32/64 bites környezet, ezek mind befolyásolhatják a build eredményét.