it-swarm-eu.dev

Jak se ponoříte do velkých kódových základen?

Jaké nástroje a techniky používáte pro zkoumání a učení neznámé kódové základny?

Mám na mysli nástroje jako grep, ctags, unit-testy, funkční test, generátory diagramů tříd, volací grafy, metriky kódů jako sloccount atd. Zajímalo by mě vaše zkušenosti, pomocníky, které jste sami použili nebo napsali, a velikost základny kódu, se kterou jste pracovali.

Uvědomuji si, že seznámení se s kódovou základnou je proces, který se děje v průběhu času, a známost může znamenat cokoli od „Jsem schopen shrnout kód“ do „Dokážu změnit faktor a zmenšit jej na 30% velikosti“. Ale jak začít?

145
miku

vždy jsem udělal následující:

Otevřete více kopií mého editoru (Visual Studio/Eclipse/Whatever) a pak odlaďte a proveďte řádky pomocí kódu. Zjistěte tok kódu, sledujte zásobník, abyste zjistili, kde jsou klíčové body, a jděte odtamtud.

Dokážu se podívat na metodu za metodou - ale je hezké, když na něco kliknu a pak uvidím, kde v kódu je spuštěn, a následuji. Podívejme se na to, jak vývojář chtěl, aby věci fungovaly.

55
ist_lion

Jak jíte slona?

Jeden kousnutí najednou :)

Vážně se nejprve pokusím mluvit s autory kódu.

64
user2567

Musím nabourat, dokud nedokončím práci

Do velké míry ano (omlouvám se).

Přístupy, které byste mohli zvážit:

  1. Pokuste se zjistit, co má kód dělat z obchodního hlediska.
  2. Přečtěte si veškerou existující dokumentaci bez ohledu na to, jak je špatná.
  3. Promluvte si s kýmkoli, kdo by mohl vědět něco o kódu.
  4. Proveďte kód v debuggeru.
  5. Zavést malé změny a zjistit, co přestávky.
  6. Proveďte malé změny v kódu, aby byl přehlednější.

Některé věci, které dělám pro objasnění kódu, jsou:

  1. Spusťte předzesilovač kódu, abyste kód pěkně naformátovali.
  2. Přidejte komentáře k vysvětlení toho, co si myslím, že by to mohlo udělat
  3. Změňte názvy proměnných tak, aby byly jasnější (pomocí nástroje refaktoringu)
  4. Pomocí nástroje, který zdůrazňuje všechna použití konkrétního symbolu
  5. Snížení nepořádku v kódu - komentářový kód, bezvýznamné komentáře, zbytečné inicializace proměnných atd.
  6. Změňte kód tak, aby používal aktuální konvence kódů (znovu pomocí nástrojů refaktoringu)
  7. Začněte extrahovat funkčnost do smysluplných rutin
  8. Začněte přidávat testy tam, kde je to možné (ne často)
  9. Zbavte se magických čísel
  10. Snižování duplikace, pokud je to možné

... a další jednoduchá vylepšení, která můžete udělat.

Postupně by měl být význam toho všeho jasnější.

Pokud jde o místo, kde začít? Začněte tím, co víte. Navrhuji vstupy a výstupy. Často můžete získat informace o tom, co mají být a na co jsou použity. Sledujte data v aplikaci a podívejte se, kam jde a jak se mění.

Jedním z problémů, který mám se vším, je motivace - může to být skutečný slogan. Pomáhá mi to myslet na celý podnik jako na hádanku a oslavovat pokrok, který dělám, bez ohledu na to, jak malý.

39
Kramii

Vaše situace je ve skutečnosti běžná. Každý, kdo musí vstoupit do nové práce, kde existuje existující kód, se kterým bude pracovat, se bude zabývat některým jeho prvkem. Pokud je systém opravdu ošklivý starší systém, pak je velmi podobný tomu, co jste popsali. Samozřejmě nikdy neexistuje žádná aktuální dokumentace.

Nejprve mnozí doporučili Účinně pracuje se starým kódem Michael Feathers. Toto je opravdu dobrá kniha s užitečnými kapitolami jako „Nemohu dostat tuto třídu do zkušebního svazku“ nebo „Moje aplikace nemá žádnou strukturu“, i když někdy může Feathers nabídnout jen více soucitu než řešení. Zejména kniha a její příklady jsou z velké části zaměřeny na složené závorky. Pokud pracujete s proplétanými procedurami SQL, nemusí to být tak užitečné. Myslím, že kapitola „„ Tento kód nerozumím dostatečně dobře, abych ho změnila, “hovoří k vašemu problému. Peří zde zmiňuje zřejmé věci, jako je psaní poznámek a označování výpisů, ale také je dobré, že nevyužitý kód můžete odstranit, pokud máte kontrolu nad zdroji. Spousta lidí nechává komentované části kódu na místě, ale často to nepomůže.

Dále si myslím, že váš navrhovaný přístup je určitě dobrý krok. Nejprve musíte na vysoké úrovni pochopit, jaký je účel kódu.

Rozhodně pracujte s mentorem nebo s někým v týmu, pokud máte odpovědi na otázky.

Využijte také příležitost podpořit kód, pokud jsou odhaleny vady (i když někdy nemusíte dobrovolně za to ... vada vás najde!). Uživatelé mohou vysvětlit, k čemu používají software a jak je vada ovlivňuje. To může být často velmi užitečný kousek znalostí, když se pokoušíme porozumět významu softwaru. Kromě toho, jít do kódu s cíleným cílem k útoku může někdy pomoci zaměřit vás, když čelí "bestii."

32
Bernard Dy

Když mám opravdu velký zdrojový soubor, rád dělám následující:

  • Zkopírujte celý nepořádek do schránky
  • Vložit do Word/textmate cokoli
  • Zmenšete velikost písma na minimum.
  • Přejděte dolů a podívejte se na vzory v kódu

Byli byste ohromeni tím, jak podivně známý tento kód vypadá, až se vrátíte k normálnímu editoru.

13
sal

Zabere to čas

Při pokusu o pochopení starší kódové základny se necítíte příliš spěšně, zejména pokud používáte technologie/jazyky/rámce, které neznáte. Je to jen nevyhnutelná křivka učení, která nějakou dobu trvá.

Jedním z přístupů je postupovat tam a zpět mezi kódem a tutoriály o souvisejících technologiích. Čtete/sledujete tutoriál a poté se podíváte na kód, abyste viděli, jak to udělali vaši předchůdci, všimli si jakýchkoli podobností a rozdílů, dělali si poznámky a kladli otázky všem existujícím vývojářům.

"Proč jsi to udělal tímto způsobem?"

„Všiml jsem si, že většina lidí na internetu to dělá takto, a vy jste to udělali jinak. Proč je to?“

"Proč jste si všichni vybrali technologii X před technologií Y?"

Odpovědi na tyto otázky vám pomohou pochopit historii projektu a zdůvodnění rozhodnutí o návrhu a implementaci.

Nakonec se budete cítit dostatečně povědomí, že můžete začít přidávat/opravovat věci. Pokud se zdá, že je vše matoucí, nebo se zdá, že se děje příliš mnoho „magie“, nestrávili jste dost času hledáním, strávením a diagramováním. Vytváření diagramů (sekvenční diagramy, vývojové diagramy atd.) Je skvělý způsob, jak porozumět složitému procesu a navíc pomůže „dalšímu chlapi“.

12
CFL_Jeff

cscope může dělat cokoli ctags může dělat pro C, plus, to může také vyjmenovat kde všechna aktuální funkce je volána. Navíc je velmi rychlý. Měřítko snadno na miliony LOC. Úhledně se integruje do emacs a vim.

Počítadlo kódů C a C++ - CCCC dokáže generovat metriky kódu ve formátu html. Použil jsem wc také pro získání LOC.

doxygen může generovat zvýrazněný syntax a křížový odkaz v html. Užitečné při prohlížení velké kódové základny.

9
aufather

Způsob, jakým doporučuji s Drupal a není to opravdu Drupal konkrétní: začněte s trackerem problémů). Určitě budou existovat staré, neuzavřené zprávy o chybách. Pokud ano, aktualizujte lístek a potvrďte jej. Pokud ne, zavřete jej. Najdete zde spoustu způsobů, jak používat software a můžete začít nahlédnout do kódové základny, kde dojde ke zhroucení. Nebo můžete začít krokem prostřednictvím kódu a uvidíte, jak se dostane na místo, kde dojde k havárii. Tímto způsobem nejen začnete chápat kodebázu, ale také hromadíte tunu karmy a vaše otázky budou komunitou vřele přivítány.

8
chx

Jednou z důležitých věcí je použití nástrojů k generování grafů závislosti k prozkoumání architektury kódu shora dolů. Nejprve si vizualizujte graf mezi sestavami nebo sklenicemi .NET, získáte tak představu o tom, jak jsou uspořádány funkce a vrstvy, a poté nahrajte závislosti do jmenných prostorů (uvnitř jedné nebo několika příbuzných sestav nebo sklenic .NET), abyste získali jemnější představu o kódu. Struktura a nakonec se můžete podívat na závislosti tříd, abyste pochopili, jak sada tříd spolupracuje při implementaci funkce. Existuje několik nástrojů pro generování závislostního grafu, například NDepend for .NET , například, který vygeneroval graf níže.

enter image description here

Jednou jsem měl docela fantastického softwarového inženýra, který mi řekl, že nejdražší formou analýzy a údržby kódu bylo procházení kódem, řádek po řádku; Samozřejmě, že jsme programátoři, a to do velké míry přichází s prací. Myslím si, že šťastným médiem je (v tomto pořadí): 1. Získejte notebook, který vytvoří poznámky o tom, jak rozumíte kódu, který bude fungovat, a přidejte jej, jak bude čas pokračovat. 2. Viz dokumentace o kódu 3. Promluvte si s autory nebo jinými, kteří podporovali kódovou základnu. Zeptejte se jich na „výpis z mozku“. 4. Pokud jste do bodu, kdy rozumíte některým vztahům třídy na úrovni podrobností, proveďte určité krokové ladění kódu, abyste provedli nějakou syntézu mezi tím, jak jste si mysleli, že kód funguje a jak kód skutečně funguje.

5
Tim Claason

Nejprve pochopte, co to má dělat - bez toho je pravděpodobné, že to bude blábol. Mluvte s uživateli, přečtěte si příručku, cokoli.

Poté stiskněte tlačítko run a začněte procházet kódem, který se jeví jako klíčové funkce.

5
Jon Hopkins

Rozděl a panuj. Dívám se na každou funkčnost a přidružený kód, procházím je a přejdu k dalšímu, pomalu buduji obrázek celku.

Pokud projekt měl testy jednotek, ráda jsem je procházel, vždy jsou velmi odhalující a poučné.

3
aredkid
  1. Spusťte všechny testy, pokud nějaké máte, a podívejte se, který kód je pokrytý a který ne.
  2. Pokud kód, který potřebujete změnit, není pokryt, zkuste napsat testy, které jej pokryjí.
  3. Změňte kód. Neporušujte testy.

Viz Michael Feathers ' Efektivní práce se starým kódem

3
kevin cline

Zde je můj krátký seznam:

  1. Pokud je to možné, požádejte někoho, aby se na kód podíval na vysoké úrovni. Jaké vzory byly zvažovány, jaké typy konvencí bych mohl očekávat, atd. Může to mít několik kol, jako na začátku bych dostal jeden příběh, který, jakmile se seznámím s kódem, mohu mít nové otázky zeptat se, jak pracuji prostřednictvím cibule již existujícího projektu.

  2. Spusťte kód a podívejte se, jak systém (y) vypadají. Je pravda, že může mít více než několik chyb, ale to může být užitečné pro získání představy o tom, co dělá. Nejde o změnu kódu, ale pouze o to, jak to funguje. Jak dohromady různé kusy zapadají do celkového systému?

  3. Hledejte testy a další ukazatele základní dokumentace, které mohou pomoci při vytváření interního mentálního modelu kódu. To je místo, kde bych pravděpodobně navrhl alespoň pár dní, pokud samozřejmě nebude k dispozici extrémně malá dokumentace a testy.

  4. Jak dobře poznám jazyky a rámce používané v tomto projektu? Zde je důležitý rozdíl mezi pohledem na některé věci a pokračováním: „Ano, viděl jsem to tucetkrát předtím a vím to docela dobře,“ a „Co se tady ve světě pokouší? Kdo si myslel, že to byl dobrý nápad?“ druh otázek, které bych jim neřekl nahlas, ale přemýšlel bych o nich zvláště, když se dívám na starší kód, který může být docela křehký a lidé, kteří jej napsali, jsou buď nedostupní, nebo si prostě nepamatují, proč věci byly provedeny tak, jak byly. Pro nové oblasti může být užitečné věnovat nějaký čas dalšímu poznání, jaká je struktura a jaké vzory mohu v tomto kódu najít.

V neposlední řadě: Poznejte očekávání těch, kteří projekt realizují, co se má v každém okamžiku dělat, a to s ohledem na několik následujících představ o tom, co lze očekávat:

  • Uvádíte nové funkce?
  • Opravujete chyby?
  • Jste refaktoringový kód? Jsou pro vás nové standardy nebo jsou velmi známé?
  • Měl byste se jen seznámit se základnou kódu?
3
JB King

Řekl bych, že bych měl začít dokumentací atd., Ale podle mých zkušeností je hloubka dokumentace a místní znalosti často nepřímo úměrná věku, velikosti a složitosti systému.

Jak již bylo řečeno, obvykle se snažím identifikovat několik funkčních vláken. Funkcí mám na mysli takové věci, jako je přihlášení, stažení seznamu zákazníků atd. Pokud jsou vzorce vůbec konzistentní, jedno vlákno by vám mělo poskytnout pěkný, ne nutně úplný průřez systému. Nejlepší způsob, jak zjistit, zda jsou vzory konzistentní, je analyzovat hrst vláken.

Myslím, že to není samozřejmé, ale podle mého názoru je lepší porozumět systému z funkčního hlediska než z technického hlediska. Obecně si příliš nedělám starosti s používanými nástroji (ORM, logovací knihovny atd.) A více se zaměřuji na používané vzory (MVP atd.). Podle mých zkušeností jsou nástroje obecně tekutější než vzory.

2
Casey

Vytiskněte zdrojový kód a začněte jej číst. Pokud je to obzvláště velké, vytiskněte pouze vybrané části, abyste lépe porozuměli a vytvořili tolik poznámek/komentářů, kolik potřebujete.

Sledujte program od začátku jeho provádění. Pokud jste přiřazeni k určité části základny kódu, sledujte provádění v této části a zjistěte, jaké datové struktury se používají.

Pokud používáte objektově orientovaný jazyk, zkuste vytvořit obecný diagram tříd. Tím získáte dobrý přehled na vysoké úrovni.

Nakonec budete muset přečíst co nejvíce kódu. Pokud budete mít štěstí, předchozí programátoři napsali co nejvíce dokumentace, která vám pomůže pochopit, co se děje.

2
Rudolf Olah

Vždy se snažím začít se vstupním bodem do programu, protože všechny programy mají jeden (např. Hlavní metoda, hlavní třída, init, atd.). To mě pak poukáže na to, co začíná, a někdy na to, jak věci souvisejí.

Poté jsem vrtal dolů. Databáze a DAO jsou někde nakonfigurovány, takže chápu, jak se věci ukládají. Možná je také spuštěn nějaký druh třídy globálních instancí, a tam mohu přijít na to, co je uloženo. A s dobrými refrakčními nástroji mohu zjistit, kdo co volá.

Poté se pokusím zjistit, kde je rozhraní nakonfigurováno a zpracováno, protože toto je další vstupní bod informací. Při mém hledání pomáhají nástroje refraktory, vyhledávání a ladění. Poté mohu přijít na to, kde začíná a končí zpracování informací, a projít si všechny soubory třídy.

Pak se pokusím zapsat tok dolů na nějaký papír, jen abych zpočátku zabalil hlavu kolem věcí. Tlačítko Odeslat přejde na obecné ověření, které se poté předá DAO nebo databázi a poté se uloží do databáze. Jedná se o hrubé zjednodušení většiny aplikací, ale je to obecná myšlenka. Pero a papír jsou zde velmi užitečné, protože si můžete rychle zapisovat všechno a nemusíte se starat o formátování v programu, který vám měl pomoci.

2
TheLQ

Některé věci, které dělám ...

1) Pomocí nástroje pro analýzu zdrojů, jako je Sledování zdroje , určete různé velikosti modulů, metriky složitosti atd., Abyste získali cit pro projekt a pomohli identifikovat oblasti, které nejsou triviální.

2) Proveďte kód shora dolů v Eclipse (dobré mít editor, který může procházet odkazy atd.), Dokud nezjistím, co se děje a kde v kódové základně.

3) Občas kreslím diagramy v Visio , abych získal lepší obrázek o architektuře. To může být užitečné i pro ostatní na projektu.

2
JeffV

První věc, kterou musíte udělat, když se učíte novou základnu kódu, je dozvědět se, co má dělat, jak se používá a jak ji používat. Poté se začněte zabývat architektonickou dokumentací, abyste zjistili, jak je kód rozvržen, a podívejte se také na to, jak je databáze v tomto bodě. Současně se učíte architektuře, že je vhodný čas na revizi všech procesních toků nebo použití případových dokumentů. poté začněte potápět a číst kód poté, co jste pochopili velký obrázek, ale pouze kód související s jakoukoli prací, kterou na tomto kódu můžete dělat, se nesnažte jen přečíst celý kód. Je důležitější vědět, kde kód má dělat X, než přesně, jak se X dělá, kód je vždy k dispozici, aby vám řekl, jak jej můžete najít.

Zjistil jsem, že jen snaha skočit a číst kód bez cíle, který by se naučil, je obecně neproduktivní, pokusit se udělat malé změny sami nebo zkontrolovat kód změn někoho jiného, ​​je mnohem produktivnější využití vašeho času.

2
Ryathal

Pokud je základna kódu velká, zaměřte svou pozornost na části, na kterých v současné době pracuje. Jinak se budete cítit ohromeni a možná vaše hlava může explodovat. Myslím, že nějaký přehled na vysoké úrovni je užitečný (pokud je k dispozici), ale je pravděpodobné, že strávíte spoustu času v debuggeru pro následující programový tok. Je dobré získat přehled o aplikaci a vidět ji používanou, abyste pochopili, jak/k čemu je kód používán.

Obvykle na kódu spouštím nějaký nástroj pro složitost kódu, který mi říká, kde jsou problémové oblasti. Oblasti s vysokým skóre se pravděpodobně velmi obtížně aktualizují. Například jsem narazil na funkci, která skóroval 450 na cyklomatické stupnici. Jistě, stovky IF. Velmi obtížné to udržet nebo změnit. Buďte tedy připraveni na to nejhorší.

Nebojte se také klást otázky existujícím vývojářům, zejména pokud pracovali na systému. Udržujte své vnitřní myšlenky pro sebe a zaměřte se na řešení problémů. Vyhněte se komentářům, které by mohly ostatní vývojáře rozrušit. Koneckonců, může to být její dítě a nikdo nemá rád, když mu říká, že je ošklivé.

Udělejte malé kroky, i ta nejmenší změna kódu může mít velký dopad.

Zjistil jsem, že je užitečné přijít s toky programových kódů, takže pokud dělám změny, mohu provádět závislostní vyhledávání a zjistit, které metody/funkce volají co. Předpokládejme, že měníme metodu C.

Pokud pouze 1 metoda/funkce volá C, pak je to docela bezpečná změna. Pokud 100 s metod/funkcí volá C, pak by to mělo větší dopad.

Doufejme, že vaše kódová základna je dobře navržená, napsaná a udržovaná. Pokud ano, bude to nějakou dobu trvat, než to pochopíme, ale nakonec se příliv obrátí.

Pokud je to velká koule bláta, možná nikdy nebudete chápat (nebo chcete chápat) její vnitřní fungování.

2
Jon Raynor

Hodně jsem toho udělal ...

Tady je můj současný přístup pro situace, kdy něco „funguje“, a je třeba, aby to „fungovalo jiným způsobem“.

  1. Získejte cíle, které by tento systém měl vyřešit (pokud nejsou psány) - napište to. Zeptejte se manažera, ostatních zaměstnanců, i bývalých, pokud jsou k dispozici. Zeptejte se zákazníka nebo vyhledejte jakoukoli dokumentaci.
  2. Získejte specifikaci. Pokud neexistuje - napište to. Nestojí za to někoho požádat, jako by neexistoval, pak jste v situaci, kdy se ostatním moc nestará. Takže jediný způsob, jak napsat vlastní (později to bude mnohem snazší odkazovat na to).
  3. Získejte design. Neexistuje - napište to. Pokuste se co nejvíce odkázat na všechny dokumenty a zdrojový kód.
  4. Napište podrobný design do části, kterou potřebujete změnit.
  5. Definujte, jak to otestujete. Takže si můžete být jisti, že starý i nový kód fungují stejným způsobem.
  6. aby systém mohl být postaven v jednom kroku. A vyzkoušejte starý kód. Pokud to ještě není, dejte to do SVC.
  7. Implementace změn. Ne dříve.
  8. asi za měsíc ověřte, že nic není rozbité.

Ještě jeden volitelný úkol, který může vyžadovat mezi jednotlivými kroky: f off manager (vlastník projektu), který vám řekne, že „tyto změny by měly být provedeny již včera“. Po několika projektech může dokonce začít pomáhat získat specifikace a dokumenty předem.

Ale obvykle (zejména u skriptů) to prostě v obchodním měřítku není možné (náklady budou příliš vysoké, zatímco hodnota bude nízká). Jednou z možností není provádět žádné změny, dokud nedosáhne kritického množství a systém neodejde z výroby (např. Přijde nový systém) nebo se management nerozhodne, že všechny tyto činnosti stojí za to.

PS: Pamatuji si jeden kód, který byl použit pro 5 klientů s různým nastavením. A každá změna (nová funkce) byla nutná při přemýšlení o tom, „jaké součásti se používají“ a „jaké konfigurační klienty mají“, aby nic nebrzdili a nekopírovali kód. Nastavením jejich nastavení do projektu cvs a psaní specifikací se zkrátí tato doba přemýšlení téměř na 0.

2

Neexistuje žádná dokumentace, bude tam jen malá dokumentace, nebo bude zastaralá. Najděte veškerou existující dokumentaci. Pokud je v úložišti týmů, nevytvářejte kopii. Pokud tomu tak není, dejte to tam a požádejte svého vedoucího o povolení k jeho organizaci, možná s jistým dohledem.

Získejte vše do úložiště pro tým a přidejte glosář. Všechny základny mají žargon; dokumentujte to ve slovníku. Vytvářejte sekce pro nástroje, produkty, specifické pro zákazníka atd.

Vytvoření/aktualizace dokumentu pro vytvoření softwarového prostředí. Všechny nástroje, vtípky, možnosti instalace atd. Jdou sem.

Poté nahrajte dokument Začínáme s názvem „ProductName“ nebo podobně. Ať je to jen tok mysli a v průběhu času se organizuje. Poté projděte zastaralé dokumenty a získejte je zpět. Ostatní vývojáři to ocení, budete přispívat jedinečným způsobem při učení kódu. Zejména dokumentujte všechny takové věci, které vás vyhodí nebo jsou označeny špatně nebo jsou kontraintuitivní.

Jakmile se vaše šikmá křivka blíží ke konci, nebojte se aktualizovat dokumentaci. Nech to příští nový člověk. Až dorazí, nasměrujte ho na svou práci. Když vás neustále žádá o odpovědi, neodpovídejte mu. Spíše přidejte otázku do své dokumentace a poté mu předejte adresu URL. Rybářský prut.

Jedním z vedlejších účinků je, že jste vytvořili nástroj, na který můžete sami odkazovat měsíce od nynějška, když zapomenete.

A i když se nejedná o dokumentaci, souvisejícím problémem jsou všechny nepředvídatelné manuálně náročné postupy, které vaši spoluhráči provádějí. Automatizujte je pomocí dávek, skriptů sql a podobně a také je sdílejte. Koneckonců, procedurální znalosti jsou patrně stejně velké jako deklarativní znalosti, pokud jde o produktivitu v novém prostředí. Ať je to cokoli, nedělejte to; spíš skript a spusťte skript. Rybářský prut zasáhne znovu.

1
toddmo

To se stává hodně. Dokud jsem nezačal pracovat na open source platformě, nemyslím si, že jsem někdy začal práci, která nezačala s přiznáním, že kód měl nějaké „vtípky“.

Můžete udělat dlouhou cestu s krokem debugger a hodně houževnatost. Bohužel často to vyžaduje čas a zkušenosti, abych se naučil konkrétní velký bláto a dokonce i po letech může existovat nějaký subsystém, který vynoří, o kterém nikdo nevěděl.

1
Jeremy French

Myslím, že jednou z nejdůležitějších věcí je vzít jednoduchou funkci, vybrat nejjednodušší, na co si vzpomenete, a implementovat ji. Pokud existuje udržovaný seznam přání, použijte jej, nebo si promluvte s někým, kdo je obeznámen s kódovou základnou, a nechte je navrhnout funkci. Obvykle bych očekával, že to bude změna s 5 ~ 20 LOC. Důležitým bodem není, že přidáváte velmi zajímavou funkci, ale že pracujete (nebo spíš zápasíte :)) s kódovou základnou a procházíte celým pracovním postupem. Museli byste

  1. Přečtěte si kód, abyste porozuměli součásti, kterou upravujete
  2. Změňte kód a pochopte, jak to ovlivňuje okolní systém.
  3. Vyzkoušejte změnu a určete tak, jak komponenty vzájemně spolupracují
  4. Napište testovací případ a doufejme, že rozbijete jeden nebo dva testovací případy, abyste je vyřešili a porozuměli invariantům systému.
  5. Postavte věc nebo se přesvědčte, že ji KI staví a poté ji odešlete

Seznam pokračuje, ale jde o to, že malý projekt, jako je tento, vás provede všemi položkami ve vašem kontrolním seznamu, abyste se seznámili se systémem a také povede k produktivní změně.

1
Osada Lakmal

Trochu, co jsem chtěl přidat:

Jedním z nástrojů, které jsem nedávno začal používat pro tento druh problému, který nesmírně pomohl, je mapování mysli. Místo toho, abych se snažil napěchovat všechny podrobnosti o tom, jak je něco implementováno v mé hlavě, postavím si mapu mysli popisující, jak systém, kterým procházím, funguje. Opravdu mi to pomáhá hlouběji pochopit, co se děje a co ještě musím přijít na to. Pomáhá mi také sledovat velmi přesně to, co musím změnit.

Doporučuji použít volné letadlo mezi množstvím možností mapování mysli.

1
c.hughes

Na toto téma jsem napsal poměrně dlouhý příspěvek. Zde je výňatek

O tomto problému jsem chvíli přemýšlel. Jako obecný proces jsem se rozhodl napsat vlastní osobní řešení. Kroky, které jsem zdokumentoval, jsou následující:

  1. Vytvoření listu slovníku
  2. Naučte se aplikaci
  3. Procházejte dostupnou dokumentaci
  4. Vytvořte předpoklady
  5. Vyhledejte knihovny třetích stran
  6. Analyzujte kód

Tento proces je psán v kontextu velké stolní aplikace, ale obecné techniky jsou stále použitelné pro webové aplikace a menší moduly.

převzato z: Proces učení nové kódové základny

1
Lars

Existuje několik malých tipů, které mohu sdílet.

U stávajícího produktu je začnu intenzivně testovat. Pokud vyberu/dostanu úkol, zaměřím se více na konkrétní funkci.

  • Dalším krokem by bylo nalezení kódu, ve kterém se mohu vloupat a začít zkoumat Na cestě najdu závislé moduly, knihovny, rámce atd.

  • Dalším krokem by bylo vytvoření jednoduchého diagramu třídy s jeho zodpovědností (jako karty CRC)

  • Začněte provádět drobné změny nebo odebírejte drobné chyby a opravte je. Můžeme se tedy naučit pracovní tok projektu; nejen kód. Velké produkty budou často mít nějakou účetní knihu kvůli autorizaci a auditům (např. Zdravotnické projekty)

  • Promluvte si s lidmi, kteří na projektu již pracují. Vyjádřete své nápady, myšlenky a na oplátku získejte své zkušenosti a názory na dlouhodobou práci s tímto projektem. To je docela důležité, protože to také pomůže dobře vycházet s týmem.

1
sarat

Chtěl bych vás vyzvat k napsání jednotkových testů, než změníte cokoli v bahně. A pouze změnit dost kódu v té době, aby testy proběhly. Jako refaktoror přidejte do ruky testy jednotek, abyste věděli, že obchodní funkčnost nebyla refaktoringem narušena.

Je párování programovatelné? Mít jinou osobu, aby odrazil nápady, je skvělý nápad, jak se vypořádat s tímto množstvím ošklivých.

1
David Weiser

Zde je postup, který používáme pro odstranění duplikátů.

  • vyberte standardní předponu komentáře pro duplikáty (použijeme [dupe] hned za značku komentáře;
  • napište se svými týmy specifikace týkající se jmen, která se mají použít pro duplikát;
  • první kolo: každý vezme nějaké soubory a přidá [dupe][procedure_arbitrary_name] před duplikovaným postupem;
  • druhé kolo: každý přijme proceduru nebo podmnožinu procedury a přiřadí hodnotu označující pořadí pravděpodobnosti různých implementací stejného účelu (řetězec pak bude: [dupe][procedure_arbitrary_name][n]);
  • třetí kolo: odpovědný za každý postup přepíše do příslušné třídy;
  • čtvrté kolo: grep šťastný!
1
cbrandolino

Už je to dlouho, co jsem se musel ponořit do velké kódové základny. Ale v posledních několika letech jsem se mnohokrát pokusil dostat nové vývojáře do týmů, kde jsme měli existující, spíše velkou, kódovou základnu.

A metoda, kterou jsme úspěšně použili, a já bych řekl, že je nejefektivnějším způsobem bez pochyb IMHO, je párové programování.

Za posledních 12 měsíců jsme měli v týmu 4 nové členy a pokaždé by se nový člen spároval s jiným členem dobře obeznámeným s kódovou základnou. Na začátku by starší člen týmu měl klávesnici. Asi po 30 minutách předáme klávesnici novému členovi, který bude pracovat pod vedením staršího člena týmu.

Tento proces se ukázal jako docela úspěšný.

1
Pete

Můj způsob, jak studovat projekt velkého kódu, je následující:

  1. vytvořte projekt a použijte jej.
  2. použijte IDE k otevření projektu.Například: Eclipse nebo Codelite.Then použijte IDE k indexování veškerého zdrojového kódu projektu).
  3. Použijte IDE) pro vygenerování diagramu třídy, pokud jazyk projektu tuto funkci podporuje.
  4. Najděte hlavní metodu. Hlavní metoda je vstupem do programu. Hlavní metoda je také dobrým vstupem k prozkoumání projektu.
  5. Najděte základní datové struktury a funkce programu. Podívejte se na implementaci.
  6. Upravte nějaký kód projektu. Vytvořte jej a použijte. Sledujte, zda správně funguje! Budete vyzváni úpravou programu.
  7. Poté, co jste pochopili hlavní tok programu a implementaci základního systému, můžete prozkoumat další moduly programu.

    Nyní jste pochopili projekt velkého kódu!

0
Edward Shen