it-swarm-eu.dev

Jak normalizujete styl kódování mezi několika izolovanými vývojáři?

Jsme malá/středně velká společnost s asi tuctem vývojářů softwaru, vyvíjejících vlastní interní software pro vlastní použití. Vzhledem k tomu, že je nás tak málo a je třeba udělat tolik práce, z velké části každý vývojář zpracovává samostatnou část systému a svou práci moc nesdílí s ostatními vývojáři. Každý z nich má svou „doménu“.

Domény se však občas překrývají a musíme spolupracovat; a také uspořádání znamená, že je těžké nahradit lidi a když se něco pokazí, musíme tam být, abychom věci napravili, protože to nikdo jiný nemůže udělat (alespoň ne rychle). Toto uspořádání je tedy Nice (každý z nás má plnou tvůrčí kontrolu) a ne Nice (jsme v podstatě nuceni být v pohotovosti 24/7, i když v praxi je to trochu uvolněnější než to).

Nedávno jsme mezi sebou vyzkoušeli malou „dílnu“, abychom podpořili některé lepší standardy kódování, konkrétně testy jednotek. (Jo, jsme jeden z lidí, kteří to zatím nedělají ...) Během 2hodinového setkání jsme se snažili vytvořit malý ukázkový program s jednotkovými testy, jen abychom získali pocit, že to uděláte.

Byla to zábava 2 hodiny a nakonec se nám podařilo vyrobit trochu kódu, ale zajímavý problém se stal bolestně zřejmým: když jsme tak dlouho žili tolik izolovaně, každý z nás má v podstatě svůj vlastní kódovací styl.

Teď nemluvím o kartách vs. mezerách, o velbloudu, o hadi nebo o nějakém takovém jiném kosmetickém rozdílu. Mluvím o zásadách uspořádání kódu. Jak pojmenovat věci. Do jakých složek a jmenných prostorů je umístit. Rozdělím tento kód do 3 tříd nebo jen do jedné? 5 malých souborů nebo 1 gigantický? Abstraktní to pryč s rozhraními a továrnami, nebo to nazývejte přímo? Getters a setters nebo nahá pole? Atd.

Občas se psaní absolutně triviálního programu téměř proměnilo v křikový zápas, i když jsme byli nakonec naštěstí schopni udržet naši chladnou na konci a žádné pocity nebyly zraněny.

Takže mě to zajímalo - jak normalizujete styl kódování mezi více zkušenými vývojáři, přičemž každý má vlastní silné preference? Různé styly určitě jso obtěžující, když do potřebujeme interagovat s ostatními kódy, nemluvě o záměně pro všechny nováčky. A když se některý kus kódu dostane z domény jednoho člověka do druhého, vždy existuje silná touha přepsat jej tak, aby odpovídal vašim vlastním způsobům.

Nejprve existují nějaká pravidla, jak rozvrhnout váš kód? Nějaké standardy? Doposud jsem viděl jen kosmetické věci o prostorech a bednách. V podstatě jak formátovat kód, jakmile je napsán (alespoň v hlavě). Existují však návody, jak napsat kód, jak jej zařídit a jak jej pojmenovat? Kde a jak jej rozdělit na kousky a jak přimět kusy, aby vzájemně reagovaly?

Pokud neexistuje standard a my si musíme vytvořit vlastní, jak to děláte, když má každý silný názor na to, co je správné a co je špatného? Teď, myslíme si, jsme všichni ostřílení vývojáři; uvědomujeme si, že žádný z našich přístupů není ve své podstatě lepší nebo horší než kterýkoli jiný - jen to, že každý z nich má určité silné a slabé stránky. Máme ale také silný názor na to, na kterých silných a slabých stránkách záleží nejvíce. Jak se tedy rozhodnete pro The Right Way ™ a jak zajistíte, aby se všichni drželi, aniž by vám ublížili (příliš mnoho)?

Jedním ze způsobů, o kterých jsem slyšel, je vybrat slavného vůdce, který potom přinutí svůj preferovaný styl na ostatní (prostřednictvím kontroly kódu a schůzek a podobně), ale ... potřebujete opravdu dobrého slavného vůdce, který je skutečně hlavou a rameny nad ostatními. . Co když nemáte, a my jsme tady všichni rovni?

52
Vilx-
  1. Máte standard pro kódování. Pokud obchod, pro který budete pracovat, již používá, je ten, který sledujete. Vyhněte se kódování standardů, které jsou dlouhé desítky stran; není to tak složité. Místo toho se podívejte na kód, který se vám líbí na Githubu, a postupujte podle tohoto stylu. Najděte zavedené idiomy pro svůj konkrétní programovací jazyk (camelCase atd.) A použijte je.
  2. Nechte nástroje IDE a styl kódu) vykonávat většinu práce za vás. Například Visual Studio již má nejvíce důležitých pravidel na místě. Nelíbí se vám formát kódu? Požádejte Visual Studio, aby jej přeformátovalo. Problém vyřešen.
  3. Najměte vývojáře softwaru, kteří vědí, co dělají. Budou psát dobrý kód, aniž by museli otrocky dodržovat průvodce stylem.
  4. Mít kontrolu kódů. Hledejte konsenzus založený na funkci a čitelnosti. Nelíbí se vám konsenzus? Jedna osoba je kravata; jejich rozhodnutí stojí.
  5. Nesnažte se o dokonalost; , nikdy to nedostanete (z mnoha důvodů, které jsou mimo rozsah této otázky). Místo toho se snažte o zlepšení.
  6. Snažte se ztrácet spoustu času a peněz na věcech, na nichž nezáleží. Zejména nepřepisujte kód, který již funguje a je již osvědčený, jen aby uspokojil vaše vlastní vnímání toho, jak by tento kód měl vypadat.
  7. Naučte se, jak psát funkce a metody, které dělají jednu věc a dělají to dobře. Pokud to uděláte, vaše pojmenování by se mělo postarat o sebe (jméno je krátká slovesná věta, která popisuje, co funkce dělá).
  8. Pokud děláte OO, naučte se, jak psát malé třídy, které mají jednu odpovědnost /bod modifikace. Pokud tak učiníte, vaše pojmenování by se mělo postarat o sebe (název je krátká věta podstatného jména, která popisuje, co je třída).
  9. Naučte se, jak psát kód, který je snadno testovatelný . Pokud tak učiníte, testy jednotky se o sebe postarají.
  10. Vyberte si bitvy. Opravdu záleží na tom malém, nejasném sklonu, který jeden z vývojářů vykazuje? Vyhněte se náboženstvím a dogmatům.
  11. Nakonec si pamatujte, že kód není váš. Nebuď o tom sentimentální. Měli byste to „vlastnit“ a podle potřeby provádět změny (takže v tomto smyslu je to vaše), ale je to tam, aby sloužilo účelu. Přílišná připoutanost k tomuto kodexu mu brání pouze tím, že brání objektivní analýze kladů a záporů rozsáhlých změn nebo rozhodnutí o struktuře kódu a způsobuje, že budete muset učinit kompromisy.
88
Robert Harvey

Prvním krokem (a zdá se, že už jste na dobré cestě) je dosáhnout dohody všech vývojářů, že je problém, a je třeba ho opravit. Všichni potřebují pochopit, že možná budou muset změnit některé ze svých návyků pro větší dobro. Je téměř jisté, že všichni budou muset změnit alespoň jednu věc o tom, jak píšou kód, ale doufejme, že i nadále budou dělat některé věci tak, jak vždy mají. Každý se musí přihlásit k odběru.

Za druhé, musíte přesně identifikovat, jaké jsou rozdíly a zapsat je do seznamu. Jak správně zdůrazňujete, některé z nich jsou triviální a kosmetické a některé mnohem logičtější. Je však třeba ji zachytit slovy, abyste ji mohli zkrotit.

Za třetí, musíte najít ovoce s nízkým visením, možná mezi vývojáři použít nějaký druh hlasovacího systému. Některé z vašich rozdílů bude obtížné vyřešit, protože všichni vývojáři mají silnou preferenci a je to rovnoměrné rozdělení. Někteří však budou mít více rozdělení 75/25, nebo budou rovnoměrně rozděleni, ale jedna strana se o tom cítí mnohem silněji než druhá. Tyto problémy lze snáze vyřešit. Identifikujte je a vezměte je po jednom. Dejte vývojářům vědět výsledek ankety a to, že všechny nové kódy, které jdou vpřed, budou v souladu s preferovaným přístupem skupiny.

A konečně potřebujete způsob, jak toto rozhodnutí vynutit, a řešením tohoto problému je pouze kontrola kódu. VŠECHNY změny musí zkontrolovat alespoň jeden další vývojář. Toto je dobrý protokol, i když jste se nepokoušeli normalizovat styl kódování. Recenzenti by měli hledat potenciální chyby, nejasný kód, zavádějící komentáře a samozřejmě dodržovat pokyny ve stylu kódování.

Jakmile je jedna změna uložena, přejděte k další. Jakmile si vývojáři na tento proces zvyknou, budou se při přístupu k spornějším otázkám více orientovat na otevřenost.

13
Pete

Vaším stanoveným cílem pro tuto schůzku bylo projednat Unit Tests pro zlepšení kvality kódu u skupiny zkušených devs. Pak jste zjistili, že se hádáte o:

Jak pojmenovat věci. Do jakých složek a jmenných prostorů je umístit. Rozdělím tento kód do 3 tříd nebo jen do jedné? 5 malých souborů nebo 1 gigantický? Abstraktní to pryč s rozhraními a továrnami, nebo to nazývejte přímo? Getters a setters nebo nahá pole?

Žádné z výše uvedených témat není pro testování jednotek kritické, je to čistě kódovací styl a očekával bych, že jakýkoli zkušený vývojář bude schopen skočit do kódové základny s některou z výše uvedených možností a bez váhání psát stylisticky kompatibilní kód.

Proto bych udělal krok zpět, uvědomil jsem si, že jste se dostali do debaty o něčem opravdu důležitém, a vraťte se na trati s tématem Testování (nejen omezením na Testy jednotek).

Zdůrazněte význam testů mezi vývojáři a poskytněte jim čas/prostor na psaní těchto testů způsobem, který nejlépe odpovídá jejich individuálnímu stylu. Pokud jasně dokumentují, kde/jak najít/spustit testy na svůj kód, jste v pořádku.

6
Graham

Nemáte jiný kódovací standard, než jaký je pro platformu obvyklý. A předpokládejte, že vaši vývojáři jsou všichni dospělí.

Dvě pravidla: Pokud upravujete soubor, přizpůsobíte se jeho stylu kódování. A nový kód je psán ve stylu vývojáře, který jej píše.

A být tolerantní. Není třeba křičet. Kdo křičí, je špatný.

5
gnasher729

Myslím, že se snažíte vyřešit špatný problém. Jak jsem pochopil, vaším problémem je, že každý vývojář pracuje ve svém sila a ostatní vývojáři skákají, pouze pokud jsou problémy vážné. V tomto případě může samozřejmě pomoci společný styl (hluboké kódování), ale myslím si, že lepší možností je nejprve přerušit sila. Dokud pracujete izolovaně, všichni budou nadále kódovat podle svých standardů. Nemusí to být zákeřný záměr (protože nesouhlasíte se standardem), může to být pouze jiná interpretace. Máme naše kódovací standardy po celá léta se stejným hlavním týmem po celá léta, ale stále se někdy setkáváme s problémem, že revize kódu odhaluje různé interpretace kódovacího standardu pro různé lidi. Což mimochodem není špatné, protože pouze diskuse a nesouhlas umožňují vývoj standardu kódování.

Takže moje doporučení je pokusit se nejprve zlomit sila. Možná přichází nový projekt, ve kterém to 2-3 vývojáři mohou vytvořit společně. Možná se můžete spojit více vývojářů na skupinu podobných projektů. Nechte tyto mini-týmy rozvíjet své standardy kódování v praxi a ověřovat interpretaci abstraktní normy praktikováním revizí kódu.

Přechod od vlastnictví jednotlivce ke kolektivnímu kódu (a společným standardem je jeho součástí) se nestane přes noc a nelze o něm na schůzce rozhodnout. Je to cíl, na který se zaměřujete a dosahujete postupným každodenním zlepšováním.

5
Manziel

Protože se nejedná pouze o povrchní styl, ale o způsob, jakým lidé píší, silně mám podezření, že pokud vynutíte způsob svíjení a přemýšlení o všem, ve formě „standardu“, potlačí kreativitu členů vašeho týmu a to by mohlo zabít váš tým/společnost. Co musíte udělat, je pracovat na přeměně těch křičících zápasů na něco produktivnějšího; a naučte se svobodněji držet své silné názory.

Nezavádějte jednu velkou změnu, setkáte se s odporem; namísto toho si stanovte cíl („chceme více sjednocenou úroveň dovednosti v designu v týmu“ na rozdíl od „chceme konkrétní styl kódování“) a zjistěte, jaký je malý krok tímto směrem. Když máte pocit, že jste se tam dostali, přijďte na další krok. Myslím, že můžete všichni souhlasit s tím, že místa, kde kód jedné osoby musí komunikovat s kódem jiné osoby, by neměla být odpovědností jediné osoby, a že za kód na těchto rozhraních je nutné, aby zúčastněné strany byly o návrh pečlivější a aby trávit nějaký čas lépe porozumět problému interakce. Tak začněte tam; představte si, že o kódu na hranicích nerozhoduje ani nevlastní jediná osoba. Nechte je explicitně prozkoumat a dohodnout se na závislostech a „mocenských“ vztazích mezi systémy/komponenty.

Další věcí, kterou můžete udělat, je nechat je, aby začaly začleňovat nějakou formu programování párů do své rutiny (během určité zlomky pracovní doby, případně s nějakým rotačním schématem), způsobem, který nebude příliš rušivý (budete muset přijít na to co to znamená s ohledem na to, jak nyní pracujete). Tímto způsobem si mohou navzájem sbírat dovednosti a mezi sebou „bojovat“, pokud jde o návrh kódu; protože na rozdíl od vytrvalého argumentu na schůzce budou řešit skutečné problémy, a tak si budou moci navzájem zpochybňovat myšlenky a hodnotit a zkoušet je v kontextu. Pomohlo by to také s vaším problémem, kdy nikdo opravdu nerozumí nikomu kódu, ale vlastnímu.

P.S. Protože teprve začínáte s TDD, tak bych to nevynutil ani v týmu. Místo toho bych jim našel způsob, jak si to procvičit na nějakém vedlejším projektu, a pak ho pomalu začlenit do své každodenní práce, protože IMO, TDD vyžaduje určité množství praxe a určitou úroveň (testovací psaní a design) ) dovednost, než může být efektivně využita. V opačném případě by mohli nakonec napsat testovací sadu, která jejich život nezjednoduší, takže ji nakonec začnou ignorovat a/nebo rozvinout nepřátelství vůči praxi. Můžete také zvážit zavedení dobrého konzultanta, mít více seminářů atd.

4
Filip Milovanović

Pokud týmová kultura dobře funguje, protože každý vývojář má svou vlastní doménu a styly a lidé jsou se situací spokojeni, nezkoušejte to změnit. Pokud tato izolace není problém, nerobte to problém.

Dbejte na to, aby bylo obecným pravidlem dodržování místních standardů. Vůdce pro každou doménu by se měl rozhodnout, jaké jsou standardy pro jejich doménu, a pokud lidé pracují mimo svou doménu, měli by respektovat styl kódování vedoucího místní domény.

To neznamená, že byste neměli mít standard kódování. Některé standardy kódování budou poměrně jednoduché a mají rozšířené dohody, takže je standardizujte. Ale pro ty spornější se nesnažte sjednotit názory všech.

3
Lie Ryan

Vzhledem k tomu, že je nás tak málo a je třeba udělat tolik práce, z velké části každý vývojář zpracovává samostatnou část systému a svou práci moc nesdílí s ostatními vývojáři. Každý z nich má svou „doménu“.

To je více problém, než se zdá. Mít pouze jednoho vývojáře na projektu podporuje tento druh nadměrné ochrany a má další rizika „faktoru sběrnice“ - pokud jedinou osobu, která zná subsystém, zasáhne autobus nebo jinak najednou způsobí neschopnost nebo odejde.

Aby se chovali jako tým, musí pracovat jako tým, což znamená rovnoměrnější rozdělení práce. To není vůbec snadné a vyžaduje nepřetržitý vstup do správy, ale z dlouhodobého hlediska je to užitečné.

Zatímco to dělají a přezkoumávají navzájem, skončí diskutováním o podrobnostech - ale dvojicí, spíše než v prostředí velké skupiny. To by mělo povzbudit vznik konsensu. Pokud se nejeví nepřiměřený člověk, který se snaží prosadit svou vůli.

3
pjc50

Není to jasné proč styl kódování je pro vás důležitý. Je to proto, že to vyvolalo nesouhlas, čímž ztrácílo čas a způsobovalo tření, nebo je to proto, že způsobuje problémy při běhu softwaru, nebo je to proto, že je obtížné psát/udržovat software?

Takže první věc, kterou musíte udělat, je vypracovat proč nebo co a jak vás pravděpodobně budou unikat (i když všechny ostatní odpovědi zde máte dobré nápady na věci, které byste měli dělat).

V této situaci bych asi udělal:

  • zápis do rozhraní
  • zápis integračních testů, které potvrzují, že software funguje při používání těchto rozhraní
  • důkladně dokumentovat mou práci
  • to všechno pouze pro moji práci

Dokud nedostanete moc prostřednictvím konsensu nebo moci prostřednictvím autority, jako je pravomoc manažera, jediným způsobem, jak můžete dělat věci, je příklad. Každý, kdo se dotýká vaší práce, bude nyní muset použít specifikace, které jste zadali, což povede k méně chybám ve vaší práci, což prokáže svůj vlastní smysl. Tímto způsobem získáte autoritu (nejlepší způsob).

Nakonec, pokud rozhraní rozešla správné věci, když dostaly očekávané vstupy, proč vám záleží, jestli má kód 3 třídy nebo 5? Protože nemůžete číst jejich věci nebo se vám nelíbí? K vyzkoušení a vynucení stylu potřebujete lepší důvody, než jaké máte.

A konečně, pokud nemáte specifikace/testy, pak nezáleží na tom, zda jste dali opici psacího stroje na kódování a nelíbí se vám její styl, máte větší problémy.

1
Iain

Robertova odpověď je skvělá, ale je tu ještě něco, co lze říci o dopadu vašich technických návrhů na týmovou práci.

jednotkové testy. (Jo, jsme jeden z těch lidí, kteří to zatím nedělají ...)

Testy jednotek nejsou ... nutné, pokud nepoužíváte OO. Pokud používáte OO, testuje help, aby vás varoval, když váš kód skončí. Testy však podléhají stejným pravidlům jako jakýkoli jiný kód a mohou se neočekávaně zlomit stejným způsobem, jaký může běžný kód.

Pokud místo OO používáte funkčnější styl, testy jednotek prostě přestanou existovat. Pokud by existovaly, vypadaly by přesně jako kopírování vašeho kódu, v tom okamžiku to prostě neuděláte, takže si můžete udržet kód malý a čitelný. Viz níže příklad.

Rozdělím tento kód do 3 tříd nebo jen do jedné? 5 malých souborů nebo 1 gigantický? Abstraktní to pryč s rozhraními a továrnami, nebo to nazývejte přímo? Getters a setters nebo nahá pole?

Možná se ocitnete v argumentech proti těmto, ale musíte najít jednu správnou odpověď. Rozhraní, abstrakce, továrny, třídy, getery a setters jsou libovolné pojmy, které znějí dobře, ale musí pochopit, jak fungují a jak se ve vašem softwaru hodí. Režie nutí vývojáře hledat nová řešení tak, aby netrávili tak dlouho řešením hádanek. Protože tyto koncepty nemají žádné měřitelné výhody, můžete je přeskočit úplně, aby byl váš kód snáze čitelný a manipulovatelný.

Vymanit se z těchto argumentů může být složité. Dobře poslouchejte, klást správné otázky, zkracujte své otázky, je přesné a přesné, a včas vystrkujte díry. Pokud někdo navrhuje použití továrního vzoru, možná budete chtít čelit příkladu, který používá méně řádků kódu. Pokud říkají něco, co nelze prokázat, například „méně kódu není vždy lepší“ nebo „není to podle standardů“, můžete je požádat, aby to vysvětlili, aby na vlastní nápad našli chybu, aby našli chybu. Pokud neuspějí, budou zmateni a frustrovaní. Nechte výběr snímek, pracovat s ním a zkuste to znovu jindy. Zlepší se při introspekci pokaždé, když se zeptáte.

Pokud nemůžete přimět vývojáře, aby introspektoval při více příležitostech a zdá se, že se nezlepšují, máte problémového vývojáře. Pokud je celý váš tým stejný, je nepravděpodobné, že byste situaci mohli zlepšit. Přijměte argumenty nebo najděte jinou práci.

Vy komentoval k Robertově odpovědi

máme příliš mnoho zkušeností a každý z nich má svůj vlastní názor

Na základě vašich popisů si nemyslím, že jste už dosáhli příliš mnoho zkušeností. Když dosáhnete této úrovně, získáte konsenzus s ostatními vývojáři na stejné úrovni, nikoli rozdílné názory. Odpověď stojí a nepředpokládejte, že jste nad ní - najděte někoho, kdo může ukázat, že ví, co dělají, a nechte je, aby vás vedli správným směrem.


Testy funkčních stylů na jednotce

To není pro původní otázku příliš relevantní a je to trochu dlouhé, takže pokud to nezajímá, přeskočte to. Byl jsem požádán, abych to vysvětlil, takže ..

Funkční server by vypadal takto:

//main
http.Listen((request,response)=>{
    response.write(request.username);
});

A test může vypadat takto:

//test that it returns the right value
var username="billy";
http.request({username:username}, response=>{
    if(response!==username){
        console.error("test failed");
        return -1;
    }
});

Ale poté, co můj základní server musí udělat něco jiného, ​​bych test přerušil. Refaktoring je nutný, ale teď to musím udělat na dvou místech.

Test také selhal stejným způsobem jako software! Pokud není uživatelské jméno definováno, snažíme se přečíst nedefinovanou hodnotu a vyvoláme chybu. Můžeme také napsat test, a to skutečně červeno-zeleným způsobem:

//red: write the test first which will find undefined values
http.request({}, (response,error)=>{
    if(response){
        console.error("got a valid response, test failed");
        return -1;
    }
    if(error){
        return 0;
    }
});

a poté opravte kód pro zelenou:

    //main
    http.Listen((request,response, error)=>{
        if(!request.username) error.write("no username");
        else response.write(request.username);
    });

Ale znovu, stejný problém. Jen jsem napsal kód dvakrát, ztěžoval jsem refaktor, přidal jsem další řádky ke čtení a testování neprokázalo nic užitečného.

Kdy je tedy testování užitečné? V OO. Testování je funkční styl sám o sobě, kde funkce hodlá udržet programový tok stabilní a zároveň vývojáře vede k tomu, aby psali menší, čistší kód.

class server{
    listen(IPerson request,string response){
        response.write(request.username);
    };
} 
interface IPerson{
    string username;
}
class Person{
    string username;
}
class TestPerson inherits IPerson{
    string username{
        get{usernameCheckedCount++; return _username;} 
        set{_username=value;}
    };
    string _username;
    int numTimesUsernameWasChecked=0;   
}
static int TestServer(){
    //setup
    var didTestFail=0;
    var srv=new server();
    var invalidPerson=new TestPerson{username=null};
    var validPerson=new TestPerson{username="billy"};

    //test that an invalid person throws an error
    srv.listen(invalidPerson,(string response, string error)=>{
        if(error==null) didTestFail=1;
    });
    //test that a valid person throws no error, the server checks the username, and the response is the username
    srv.listen(validPerson,(string response, string error)=>{
        if(error != null) didTestFail= 1;
        if(validPerson.numTimesUsernameWasChecked == 0) didTestFail=1;
        if(response != "billy") didTestFail=1;
    });

    //return
    return error;
}

Kdybych to nenapsal s ohledem na testování, mohl bych velmi dobře začít vytvořením služby, 2 rozhraní a jiného souboru závislých injekcí, než začnu s prací samotnou, což jistě práci znesnadní. Je opravdu těžké sledovat vše!

0
Willtheoct

Kromě návrhů zde důrazně doporučujeme použít sdílení obrazovky k provádění párových programovacích relací, aby vývojáři mohli spolupracovat. NE celý den každý den, jen pár hodin týdně práce jako pár a smíchání toho, kdo párů, s nimiž bude mít obrovskou odměnu, pokud jde o normalizační praktiky a sdílení tipů mezi sebou.

0
Chuck Krutsinger

Pokud jsem pochopil vaši otázku, samotný fakt, že lidé mají různé kódovací styly a designové preference, není problém. Problém nastane, pouze když

domény se překrývají a musíme spolupracovat

a tyto styly a preference se vzájemně kolidují. Nyní je vaším plánem vyřešit tento problém „normalizací“ stylu kódování.

Normalizace je pro mě v tomto kontextu poněkud zvláštní slovo, jak by byl jakýkoli styl kódování normálnější než kterýkoli jiný? Jak nejsou současné styly kódování normální? Co definuje normální styl kódování? Možná je to proto, že nejsem rodilým mluvčím anglického jazyka, ale vaše volba Wordu už může být náznakem, že zde trochu směřujete špatným směrem.

Lidé obvykle rozvíjejí styl kódování, který jim pomáhá psát lepší kód. Protože se všichni lidé liší, někdy i více, někdy méně, budou se jejich kódovací styly lišit. Samozřejmě si můžete vytvořit společný styl kódování a donutit každého, aby ho používal, ale to je trochu jako nutit všechny lidi, aby pro psaní používali stejnou ruku, i když někteří z nich jsou praváci, zatímco jiní zůstanou handers.

Společný styl kódování je obvykle kompromis a nebude vyhovovat nikomu tak dobrému, jako je ten jejich. Někteří lidé s tím budou mít menší potíže, protože styl je blízko jejich preferencím, zatímco pro ostatní to bude skutečný problém. To, co se zde v zásadě snažím říct: Vynucení stylu kódování u vyspělých vývojářů způsobí, že budou obecně vytvářet horší kód, někdy jen trochu horší, někdy mnohem horší, záleží na vašem výběru stylu. A nejsem si jistý, zda vylepšení v překrývajících se oblastech kompenzuje ztrátu ve všech ostatních oblastech.

Ve vaší otázce jsem četl, že skutečnost, že každý má svůj vlastní styl kódu, nebyl doposud obecně vážným problémem, nevím, jestli jeho chytrý způsob, jak z něj učinit vážný problém, nutit společný styl kódu pro všechny a pořád vidíš, co tím myslím?

Co se týče spolupráce, okamžitě mi přišel na mysl dobrý starý designový vzor:
Program na rozhraní, nikoli implementace!

Pro spolupráci je nutné dohodnout se na společných rozhraních. Není nutné dohodnout se na společných implementacích za těmito rozhraními. Tady je můj návrh:

Ponechte každému svůj oblíbený styl kódování, ale při navrhování rozhraní pro sekce, kde se domény překrývají (nebo se mohou v budoucnu překrývat), se ujistěte, že je nenavrhne žádná jediná osoba. Buď je navrhněte na týmové schůzce, nebo vytvořte pravidlo, protože alespoň tři nebo čtyři lidé musí spolupracovat na každém rozhraní. Tímto způsobem získáte mnohem lepší rozhraní a lepší rozhraní automaticky vedou k lepšímu kódu. Odpovídají také na otázky, jak rozdělit své problémy na kousky nebo jak pojmenovat prvky a nejdůležitější, jak kusy budou vzájemně reagovat.

A mějte na paměti: Dobré rozhraní může přežít velmi dlouhou dobu, protože implementaci za ní můžete vždy nahradit, aniž byste se museli dotknout jakéhokoli jiného kódu. Proto jsou rozhraní důležitější než implementace, protože nahrazují rozhraní, která jsou opravdu tvrdá práce. Nicméně, bez ohledu na to, jak jste dobří, uděláte při navrhování rozhraní sami chyby. Budete přehlížet problémy, přehlížet chybějící podrobnosti a mít pár dalších očí vedle vás bude opravdu užitečné.

Můj návrh v zásadě následuje další starou vývojářskou moudrost:
Nikdy se nedotýkejte běžícího systému. Alespoň ne, pokud nemusíte. Vynucení stylu kódování na každého by přepracovávalo váš systém od nuly, přestože se zdá, že doposud funguje velmi dobře, že? Neopravujte část systému, která není rozbitá. Zaměřte se pouze na skutečný problém a to jsou oblasti, kde se domény překrývají.

0
Mecki