Jak docílit shody mezi programátory?
- Barvoj
- Člen | 60
Rád bych Vám nejprve přiblížil situaci:
Baví mě se učit nové věci a zkoušet si je. Když se ale snažím nové poznatky aplikovat v práci, často slýchám ze strany ostatních vývojářů nedůvěru a neochotu dělat věci jinak.
V posledních měsících například hodně přemýšlím o způsobech, jak psát webové aplikace, aby zůstaly i do budoucna udržovatelné. Chozením na posoboty a pročítáním zdejšího fóra jsem se dozvěděl o DDD.
Zalíbila se mi například myšlenka entit, které nejsou jenom přepravky na data. Entita sama může obsahovat nějakou logiku aby zajistila svou konzistenci. Podobně jako je to zmíněno v https://forum.nette.org/…a-v-entitach#…
Tlumočil jsem tedy tuto myšlenku o entitách ostatním a snažil se vysvětlit, jaké tam vidím výhody. Ale ne všechny jsem přesvědčil.
Při CR se pak stále dokola řeší ty stejné diskuze:
- hloupé nebo chytré entity
- psát phpdoc komentáře ano či ne
- u @var anotace pole psát pouze array a nebo konkrétněji int[]
- mít sjednocené odsazování nebo může být každý řádek kódu odsazený jinak (podle toho kdo ho napsal)
To jsou jen některé příklady z poslední doby o kterých se strhla velká diskuze. Naše diskuze ale často k ničemu nevedou a témata mají tendenci se stále vracet.
Má otázka tedy zní. Jak řešíte neshody mezi vývojáři u Vás v týmu? Vládne u Vás osvícený diktátor, který si poslechne argumenty a nakonec rozhodne? Nebo demokraticky hlasujete? Nebo to (ne)řešíte jinak? Co vůbec má smysl řešit a co by si měl každý programátor rozhodnout sám? Vadí když jeden používá chytré entity a druhý hloupé? Když jeden používá repository a druhý query objecty? když jeden píše komentáře a druhý ne? Když jeden odsazuje mezerami a druhý tabulátory? :)
- matopeto
- Člen | 395
Zaklad je dohodnut sa. Nastavit si spolocne coding standarts a tie dodrzovat. (To ze jeden pouziva medzery a druhy tabulatory by nemalo nikdy nastat)
U nas dost pomaha ze kazdy commit ide cez codereview (robime si ho navzaojom) a ked sa niekomu nieco nepaci tak to vrati. (nebat sa vraciat i za „hluposti“ ako chybajuci komentar, aleto zle formatovany kod.
Tiez sa daju nastavit nejake stylecops, ktore budu codingstandards checkovat a commity, ktore to nesplnaju nemylostrdne zamietat :)
Rovnako ak to vase IDE podporuje nastavit coding styles (to vase odsuhlasene) v nom pri kazdom save.
- Barvoj
- Člen | 60
matopeto napsal(a):
Zaklad je dohodnut sa.
A jak docilit te dohody?
Kdyz jeden programator pri CR zjisti, ze chybi @var anotace u promennych a druhy rekne. Ze mu to prijde zbytecne. Tretimu je to jedno a ctvrty zrovna neni v praci.
To je ta situace, kterou by me zajimalo jak resi ostatni?
Umim si predstavit dve reseni – bud hlasovani nebo diktatura jednoho „osviceneho“.
Hlasovat o kazde blbosti mi prijde casove narocne a zdlouhave protoze se malo kdy sejdeme v kanclu vsichni.
- filsedla
- Člen | 101
Podle mě se to moc řeší…
Oddělil bych především věci, které způsobí nějaký prokazatelný problém, pokud se všichni neshodnou. Ty je důležité stanovit.
Například když jeden vývojař použije taby a druhý mezery a zároveň používají automatické formátování kódu, při změně 1 řádku bude v gitu změněný celý soubor. Tomu je potřeba zabránit.
- Hurass
- Člen | 114
Osobně doporučuju dohodnout se, nastavit si stejně IDE a využívat nějaké nástroje, např. codesniffer, phpstan, atd., které bude kontrolovat CI.
- Tomáš Votruba
- Moderator | 1114
@Barvoj U nás to fungovalo tak, že na čem jsme se dokázali dohodnout, to fungovalo v pořádku.
Ty se ptáš na tu druhou část, když jeden chtěl to a druhý něco jiného V tom případě jsme oba předložili důvody a podklady šéfovi, probrali to a ten rozhodl.
I když s tím jeden nesouhlasil, tehle proces fungoval, protože jsme se nezasekli na 1. neshodě na pár let. Vždycky musí být někdo, kdo rozhodně v případě neshody. To neznamená, že musíš být diktátor.
Někteří šéfové nemají odvahu být převzít zodpovědnost a říkají „to si vyřešte sami“. Myslím že právě to je součástí jejich práce. Pak to dopadá tragi-komicky: Znám i jendu firmu, kde takhle míchají na 2 projektech 3 frameworky (ne komponenty, ale fakt frameworky).
Btw, abych se vyjádřil k tvé situaci. Vypadá to, že tě baví se učit a aplikovat nové věci a firemní prostředí tomu není otevřené. Podobní lidé v mém okolí obvykle museli skončit u výpovědi. Tady si často vzpomenu na „ryba smrdí od hlavy“. Pokud rozvoji a změnám není otevřený šéf, má to tým nastavený podobně a je těžké změnit šéfa (člověka). Největší argument nejsou citované success-story z Clean code, ale zvýšený počet výpovědí za poslední rok.
Až pak si můžeš najít tým, kde na to, co se snazíš prosazovat, přímo lpí. A takových týmů je v ČR kopa. A všechny hledají vývojáře :-)
Editoval Tomáš Votruba (9. 4. 2017 10:29)