9 způsobů, jak se naučit hrozné kódu, rychlé

dostali Jste za úkol implementaci nových funkcí na starý codebase, ale kód vypadá hrozně. Jak to můžete pochopit co nejrychleji? Zde je několik zkratek, které vám pomohou naučit se důležité části nového kódu, aniž byste se ztratili v irelevantních detailech.

jako programátoři se často musíme připojit k novým projektům a kvalita kódu může být všude. I s organizovaným týmem je udržování konzistentní kvality kódu v celém středně velkém až velkém projektu výzvou.

to je důvod, proč porozumění špatnému kódu rychle může být cennou dovedností. To vám může pomoci stát se velmi produktivní v krátkém čase a snížit stres, který obvykle přichází s tím, že nový chlap a museli hrát dohnat. Být v rozhovoru se spolupracovníkem a nevědět, o čem tato osoba mluví polovinu času, je hrozný pocit.

Na druhou stranu, je to vynikající příležitost pro ukazuje, váš klient nebo šéf svou cenu, a že se můžete dostat až na rychlost rychle a zapůsobit na ně. Většina vývojářů trvá týdny až měsíce, než se stane opravdu produktivní s kódovou základnou, kterou sami nevytvořili.

zde je návod, jak rychle zvládnout hrozný kód.

požádejte o pomoc. Je to nejúčinnější strategie

ostatní lidé se již naučili, jak kód funguje, tak proč se jich na to nezeptat? Možná si myslíte, že to vypadá jako nováček, ale ukázat zvědavost může mít silný dopad na váš obrázek zaměstnance. Pokud váš šéf očekával, že budete rychle produktivní, aniž byste se ptali, je to z její strany nesprávné posouzení.

každý potřebuje čas, aby se dostal do rychlosti. Ptejte se a zapůsobíte na lidi, kteří mají správný přístup k týmové práci.

v mnoha případech původní vývojáři učinili podivná nebo neočekávaná rozhodnutí, a to je místo, kde mluvit o kódu bude mnohem cennější než jeho čtení. To je ještě více v případě, že dokumentace chybí. Pamatujte, že stávající vývojáři mají cenné znalosti o projektu, které nejsou nikde napsány.

Vytvořte seznam konceptů, které vám nedávají smysl

mohou existovat obchodní koncepty, které jsou pro vás nové nebo příliš složité. Je důležité si o nich ujasnit, než se pokusíte pracovat na kódu, který tyto pojmy zpracovává, aby nedošlo k nedorozuměním, která by mohla chvíli trvat.

může se dokonce stát, že tyto myšlenky jsou nesprávně označeny nebo neočekávaně zastoupeny v databázi. Vyhněte se tedy stresu nad tím, že si kolem toho zabalíte mozek, a prostě jděte ke zdroji a zeptejte se na to svých spolupracovníků.

ve stejném duchu mohou existovat moduly, třídy nebo entity, které nemají odpovídající názvy. Poznamenejte si je. Špatně pojmenované prvky mohou vést k velkému zmatku, takže je zdokumentujte brzy, stejně jako cokoli jiného, co negativně ovlivní vaši schopnost přemýšlet o tom, jak kód funguje.

Aby bylo snadné reprodukovat chyby

přidáním kódu, verzování a virtuální stroj jako je Docker nebo Tulák, bude výrazně snížit čas potřebný k reprodukovat chybu a vyzkoušet své práci na nové funkce.

Jakékoliv nedorozumění o tom, jak kód funguje, by mohl vést vás cestou budování špatnou věc, a to buď, protože to, co jste budova by již být tam a ještě jsi to neviděl, nebo proto, že věci prostě nefungují tak, jak jste si mysleli.

v tomto okamžiku chcete mít ve svém projektu správu verzí Git. Tímto způsobem se budete moci vrátit ke stabilnímu vydání nebo dokonce pracovat na samostatných větvích, které lze v případě potřeby zlikvidovat.

je dokonce možné získat větší reprodukovatelnosti s Git, protože můžete použít skrýš přidat testování nebo ladění kódu, zatímco vy kopat do tvrdé-to-track problém.

Chcete-li se dozvědět o architektuře vašeho projektu, přijměte úkoly konfigurace a dokumentace brzy.

totéž lze říci o VMs a reprodukovatelnosti. Staly se všudypřítomnými pro každý moderní vývojový tým, ale určitě narazíte na projekty, které je nepoužívají, nebo dokonce připravené běžet uvnitř jednoho. Někdy váš první krok jako nový člen týmu je dokument kroků jste si vzal, aby si pracovní prostředí, a nakonec zase ty kroky do VM instalační skript.

Vytvořit diagram komponent

myšlenkové mapy pro obchodní koncepty, entita-relační diagram (ERD) z tabulky databáze, a jednoduchý diagram kód komponenty může výrazně pomoci snížit bolest z pochopení nového kódu. Nepamatujete si, jak něco funguje? Nech ten ERD otevřený.

ve skutečnosti bude cenný jakýkoli grafický nástroj, který vám pomůže rychle strávit informace a mít desetitisícový pohled na projekt. Dalšími příklady nástrojů, které by vám mohly pomoci, jsou grafy závislostí, protokoly a mapa technologického zásobníku projektu.

jedním z největších spotřebitelů času ve vývoji je integrační bod mezi systémy. Globální pohled na krajinu projektu vám pomůže určit, které integrační body je zajímavé prozkoumat. To jsou místa, která mají nejvíce práce dát do nich, a nejvíce chyb.

na druhé straně se technologie pohybuje rychle a mohly by existovat příležitosti nahradit velké části kódové základny modernějšími a správně integrovanými řešeními. Starý rámec mohl vyvinout nový a oficiální způsob řešení problému, nebo mohla být vyvinuta zcela nová knihovna s ohledem na lepší kompatibilitu.

použijte vizualizační a modelovací nástroje pro zobrazení velkého obrazu.

připravte se na automatizované testování

než začnete rozbíjet věci, je vždy rozumné přidat příslušné testy jednotek. Problém s testováním a chudé kódu je, že chudí kód je obvykle pevně spojen a těžké (ne-li nemožné) k testování. Nemůžete izolovat komponenty, které jsou propletené a nedělitelné.

v těchto případech udělejte krok zpět a vyzkoušejte z větší vzdálenosti. Obvykle to znamená dělat integrační testování, pro které je k dispozici mnoho nástrojů. Webové aplikace lze testovat proti požadavkům HTTP, takže je možné alespoň ověřit, že systém bude reagovat stejným způsobem na stejné vstupy.

integrační testování má však mnohem horší výkon než unit testy. Kdykoli je to možné, implementujte testy jednotek, abyste mohli mít rychlejší zpětnou vazbu o změnách kódu. Pokud to není možné, pak se rozhodněte pro funkční nebo dokonce integrační testování.

tento krok by měl osvětlit části kódu, které potřebují práci. Pokud existuje velké množství pevně Spojeného kódu, je to dobrý cíl pro refaktoring po provedení integračních testů a později pro testování jednotek.

Identifikujte neobvyklé nebo nedostatečné strategie kódování

je čas začít dělat nějaké refaktorování,ale kde začít?

obvykle je nejlepším místem, kde věci vypadají divně, nebo kde nebyly dodržovány osvědčené postupy vývoje. Pro vývoj webových aplikací by to mohlo znamenat řadiče fat s pevně spojeným kódem modelu.

mějte na paměti, že stejné strategie mohou být použity i jinde. Pokud například zjistíte, že jsou přítomny řadiče fat, je pravděpodobné, že předchozí vývojáři se nepokusili mít tenké řadiče. Můžete očekávat, že stejný problém uvidíte i v jiných řadičích, protože to odráželo styl nebo nedostatky vývojového procesu dříve.

zpočátku bude práce na malém úkolu

Oprava malé chyby na koncepčně jednoduché funkci velmi poučná a pomůže vám cítit se produktivní od začátku.

je to podobná myšlenka, jakou Andy Hunt a Dave Thomas nazývají” tracer bullets ” v pragmatickém programátorovi. Základní logika je stejná: Pracovat na něčem end-to-end, aby sis dokázal, že je to možné, a pak postupně zvýšit na původní práce.

přístup “tracer bullet”. Kredit: pragmatický programátor

dobrým příkladem jednoduchého vylepšení, které můžete udělat, je podniknout malé refaktorovací kroky s jednoduchým kódem. Identifikujte běžnou programovací praxi, která se nedodržuje, a aplikujte ji.

jeden z mých oblíbených pro toto je un-hnízdění podmíněné bloky. Takže místo toho, s několika, pokud-pokud-je-li bloky, jeden uvnitř druhého, negovat první a vrátit se a udělat to samé pro všechny ověření-typ kontroly, které můžete najít. To může být stejně jednoduché jako převrácení kontroly ” if ” a přesunutí nějakého kódu, takže riziko téměř neexistuje a plochý kód bude snáze čitelný.

nezapomeňte nejprve pracovat na refaktorovacích funkcích, které lze snadno otestovat, protože i když jsou změny nízkorizikové, je vždy dobré ověřit kód před odesláním do výroby.

před řešením kritického kódu

se vždy nejprve dozvíte, jak je projekt nastaven, a teprve poté se ponořte do architektonické stránky. Nejkritičtější části obchodního a integračního kódu jsou nejtěžší pochopit a upravit. Vyhněte se dostat do problémů brzy.

obecně se vyhněte obchodním problémům, které by vyžadovaly, abyste věděli více, než v současné době o projektu nebo o obchodní stránce. To obvykle znamená držet se dál od transakčního, platebního nebo matematického kódu, dokud se nezačne seznamovat.

jakmile jste produktivní, jste spokojeni se stylem kódování projektu a nemáte potíže s opravou jednoduchých problémů, je čas pracovat na tvrdších věcech—ale ne dříve.

I když je to naléhavé pro stanovení platebních problémů, například, že druh úkolu může být neuvěřitelně riskantní. Chyba by mohla projekt stát draho, a to bude také na vás. Absolutně odmítněte pracovat na vysoce rizikových úkolech brzy, pokud je to vůbec možné.

Jak se vypořádat s neznámým tech stack

Pro poslední bod, společný problém jsem běžet do je, že každý nový projekt obvykle zahrnuje některé technologie, která mi není znám.

když se to stane, mám několik strategií, které mi pomáhají rychle se dostat do rychlosti. Zřejmou cestou pro učení je čtení dokumentace a seznámení se s novou technologií. Ale i když se dozvíte hodně o struktuře, tato cesta vám nepomůže naučit se rohové případy, které obvykle přicházejí se zkušenostmi. (“Corner case” je technický termín, který odkazuje na situaci, která se vyskytuje mimo normální provozní parametry.)

Jeden způsob, jak urychlit tento proces získávání zkušeností je, aby se otázka-na základě zdrojů, jako je Přetečení Zásobníku a Quora a jen číst v nich jako v knize. Najděte nejoblíbenější otázky týkající se knihovny, kterou se učíte, a podívejte se, na jaké problémy se ostatní lidé obvykle setkávají. Nebudete na ně nutně narazit sami, ale jen vědět, co je možné, je jako svítit jasné světlo na vaši myšlenkovou mapu těchto nových nápadů.

využijte otázky přetečení zásobníku, abyste získali zkušenosti rychle. Kredit: přetečení zásobníku

pro cílenější přístup najděte informace o funkcích knihovny, které se konkrétně používají ve vašem novém projektu. Podívejte se na ty, které jsou pro vás nové, a naučte se je předem, než se budete muset tohoto kódu vůbec dotknout.

Podělte se o své nápady