Jak docílit shody mezi programátory?

před 2 lety

Barvoj
Člen | 60
+
+4
-

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? :)

před 2 lety

matopeto
Člen | 400
+
+2
-

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.

před 2 lety

Barvoj
Člen | 60
+
0
-

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.

před 2 lety

filsedla
Člen | 58
+
+1
-

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.

před 2 lety

CZechBoY
Člen | 3308
+
+1
-

Si dohodnete schuzku a poreste code style jako celej, definujte cs fixery atd. Nebo posli otazku emailem kdyz jedete remote…

před 2 lety

Hurass
Člen | 114
+
+2
-

Osobně doporučuju dohodnout se, nastavit si stejně IDE a využívat nějaké nástroje, např. codesniffer, phpstan, atd., které bude kontrolovat CI.

před 2 lety

CZechBoY
Člen | 3308
+
0
-

@Hurass phpstan ale nekontroluje code style ale realne chyby v syntaxi, spoustenem zdrojaku.

před 2 lety

Hurass
Člen | 114
+
0
-

@CZechBoY to máš pravdu, bral jsem to spíš jako další doporučení. Testovat jen code style nestačí. :)

před 2 lety

CZechBoY
Člen | 3308
+
0
-

@Hurass no jasne, code style byste meli mit dohodnuty..
pak samozrejme prichazi problem jak modelovat problem, co pouzit za knihovny a jakej pristup. na to je dobry si sednout a projit pripad od pripadu – jaky to ma vyhody, jak dlouho zabere seznameni s tou knihovnou atd.

před 2 lety

Tomáš Votruba
Moderator | 1154
+
+5
-

@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)