Odkazy Nikdy Zemřít: Jak Zvládnout Legacy Kódu

Když termín „legacy code“ přijde, to je obvykle řekl, nebo přijaté s nádechem pohrdání. Předběžné vyhledávání Google pro „legacy kód memy“ přináší stovky a stovky obrázků makra lidí, trhat vlasy ven, vypadáš vyčerpaně, nebo obrovsky zklamaný.

Když jsem začal pracovat jako software developer před 6 měsíci, neměl jsem tušení, co legacy kód, nebo to, co práce s ním obnáší.

během mého čtvrtého měsíce jako junior developer, byl jsem požádán, aby přidat vyhledávací filtr modal do aplikace postavené jedním z mých spolupracovníků před dvěma nebo třemi lety. Zdálo se to dost snadné; většinu posledních čtyř měsíců jsem strávil prací na neuvěřitelně složité aplikaci pro jiného klienta zahrnující náš standardní zásobník: TypeScript / React/Redux / Redux-Saga. Měl jsem již vyřešil mnoho jedinečných problémů a cítil důvěru ve své kódovací schopnosti natolik, aby se jednoduché modální předat parametry dotazu na backend.

jak jste možná uhodli, nebylo to tak jednoduché. Ale proč?

Co legacy kód je a proč to může být náročné vypořádat se s

Legacy kód je kód dědí od jiného vývojáře nebo tým, který používá starší technologie, které již nejsou podporovány nebo byla nahrazena novější verzí. Mnoho programátorů říká, že „kód se stává starším kódem, jakmile je napsán“. Funkční rozdíl mezi „běžným“ kódem a starším kódem může být jednoduše v tom, že má různé konvence ve srovnání s tím, s čím jste zvyklí pracovat.

v mém případě byla aplikace přiřazena spíše k využitému toku než k TypeScript a nebyla tak silně napsaná, jak jsem byl zvyklý. Díky tomu bylo pro mě trochu těžší pochopit strukturu dat, která byla načtena z backendu. Žádné typy neznamenaly, že jsem běžel do TypeErrors na runtime mnohem častěji, což může být obtížné ladit, když píšete velkou funkci. Kromě toho aplikace použila mnohem starší verzi Reactu, kterou bylo třeba sladit s kompatibilní verzí knihovny komponent, kterou jsem chtěl použít k sestavení modalu.

než se dostanu do natvrdlý-kostrbatý, jak zacházet starší kód s pocitem poise a racionality, chci přidat disclaimer, že starší kód není všechno špatné a pracuje na starší projekt nemusí být hrozné. Naopak, pracuje na legacy kódu mě naučil být flexibilní, trpělivý, a nade vše, zkušenost umožnila mi šanci vyřešit problémy s novou perspektivu v nových souvislostech.

Ve skutečnosti, to ze mě lepšího vývojáře, než jsem byl předtím, než jsem začal pracovat prostřednictvím výše uvedených codebase, a doufejme, že vaše legacy projektu, může vás něco naučit.

Jak se vypořádat s legacy kód na technické úrovni

Photo by Jeff Sheldon na Unsplash

Přečtěte si dokumentaci a kódu komentáře, když je to možné

V dokonalém světě, každý codebase má robustní README, který obsahuje stručné vysvětlení, jak projekt funguje, kód, komentáře, které vysvětlují, přesná logika původního autora, a celá aplikace dává dokonalý smysl. To je však zřídka případ. Mnoho Readme nechápu aktualizovány projekty rozvíjet, lidé zapomínají psát komentáře, předpokládám, že jejich logika je zřejmé, pro nové vývojáře, nebo se jim prostě nezbývá čas se postarat o ty věci.

podívejte se na kódovou základnu jako celek

Pokud jste ztraceni a nevíte, kde začít, položte si tyto otázky:

• jaký je účel aplikace?
• jak proudí data přes aplikaci?
• jak se vaše funkce vejde do aplikace?

když můžete získat představu o velkém obrazu, je snazší zjistit, jak nejlépe vyřešit problém. Možná budete muset vytvořit nový soubor a vytvořit novou součást. Možná budete muset napsat obslužnou funkci a vyzkoušet ji. Ať už je to jakkoli, pochopení širšího kontextu vašeho problému je dobrým prvním krokem k vytvoření řešení.

Test aplikaci ručně a s unit testy, kdykoli je to možné

Lámání aplikace dočasně, zatímco přidávání nových funkcí je nevyhnutelné, bez ohledu na to, jakou úroveň vývojka jste. Toto je normální a očekávané, a to zejména pokud jste nové zaměstnání, práce v legacy codebase s neznámým zásobníku, nebo nějaká kombinace obou.

nejlepší způsob, jak zabránit tyto chyby z stává dlouhodobé problémy, je otestujte si své aplikaci důkladně s oběma unit testy a ruční testy. Mít tyto testy na místě a přesně vědět, jaký druh pokrytí se z nich dostanete, vám a budoucím vývojářům ušetří spoustu času. Kromě toho, přísné testy, aby aplikace více škálovatelné a také vám trochu dopaminu spěch pokaždé, když vaše testy spustit čistý.

pro testování jednotek můžete použít testovací rámce jako Jest nebo Jasmine.

pro ruční testy budete chtít vytvořit testovací matici a ujistit se, že dokument je přístupný budoucím vývojářům. Pro matrix, budete chtít stanovit soubor opatření, očekávané chování, skutečné chování, když si to vyzkoušet, a další podrobnosti, které jsou důležité, tak jako:

budu pokrývající jak realizovat oba typy testování efektivně do svého workflow v budoucím blogu.

Požádat o pomoc

za Předpokladu, že váš projekt byl napsán současných nebo bývalých zaměstnanců na vašem pracovišti, někdo jiný asi ví, co se děje v aplikaci, nebo alespoň ví dost, aby vás odlepit. Naučit se spolknout svou hrdost a zeptat se někoho jiného je pro některé nepříjemný krok, ale nezbytný pro růst jako vývojář, a možná vás váš spolupracovník naučí několik nových triků.

dobrým způsobem, jak efektivně využít svůj čas (a jejich), je formulovat informované otázky. Zkuste se vrátit k pohledu na codebase jako celek a zjistit mezery ve vašem porozumění. Nejen, že jim pomůže získat lepší představu o tom, jaký je váš problém, ale ukazuje, že jste se ujali iniciativy a pokusili se problém vyřešit sami.

Vědět, kdy snížit své ztráty

Pokud budete trávit příliš mnoho času se snaží dostat nohu do dveří a neprovedli žádné vážné kroky směrem k plnění funkce poté, co se snaží výše uvedené kroky, by to mohlo být za refactoring kódu kolem své funkce. Nevzdávejte se příliš snadno, ale také mějte na paměti, jaké jsou vaše termíny a co od vás očekává váš projektový manažer.

to znamená, Že tam jsou nevýhody, jde o to, že způsob, jak:

• Přepisování kódu lze zavést chyby, i když to může být poněkud obejít s dobrou unit testování.
• přepisování kódu může odstranit skryté funkce, i když to lze také obejít pomocí dobrých testů jednotek.
• Pokud jste v časové tísni, psaní kódu mimo své funkce kromě své funkce může být ve skutečnosti časově náročnější, než jen budování kolem ní.

celkově vzato, Použijte svůj nejlepší úsudek. Existují výhody a nevýhody pro obě volby, a to vše závisí na vašich individuálních okolnostech a rozpočtu projektu.

Jak se vypořádat s legacy kód na psychologické úrovni

Foto Simon Migaj na Unsplash

Nyní, když jsme probrali technické aspekty nakládání s legacy kódu, pojďme mluvit o tom, jak se s tím vypořádat pomocí našich soft skills. Po všem, vývojáři jsou lidé, nejen kódování robotů, a řešení náročných problémů na projektech, které vyžadují kreativitu a autorství, může být emocionálně zdanitelné, nejen pro vás,ale i pro vaše spolupracovníky.

buďte pokorní a laskaví

to je něco, co rozpačitě přiznám, že potřebuji více cvičit. Když mi byl poprvé přidělen projekt filter modal, byl jsem docela hlasitý o tom, jak se janky a neatraktivní kód měl vypořádat, zatímco původní autor kódu seděl 15 nohy ode mě. Zamýšlel jsem své komentáře jako vtip, ale při zpětném pohledu uznávám, že jsem byl arogantní a zraňující, a že jsem měl být empatičtější.

Existuje mnoho faktorů, které mohou vést k legacy kód, dívat se „z“, které byste měli vzít v úvahu předtím, než začnete kritizovat autora nebo předpokládat to nejhorší o nich (To je volně vázána na základní atribuční chyba!).

původní autor mohl mít své důvody pro psaní kódu tak, jak to udělali.

časová omezení a technologická omezení mohou způsobit, že osoba napíše kód, který funguje, ale nemusí mít nutně nejlepší konvenci. Pokud si představujete sami sebe v situaci, kdy není dostatek času, zastaralé nástroje, a seznam úkolů míle dlouhý, pravděpodobně byste také nenapsali nejlepší kód!

konvence se mění.

ve starších projektech aplikací Olio používá konvence pro kód jednotlivé uvozovky k deklarování řetězců a dvě mezery se rovnaly jedné kartě. Měli jsme několik malých komponent React vnořených uvnitř jednoho souboru. V naší současné úmluvy, používáme uvozovky a čtyři mezery, a každé React komponenty, bez ohledu na to, jak malé, žije ve své vlastní .tsx soubor v component adresář. A za několik let se to určitě také změní.

celý kód se nakonec stane legacy

to naváže zpět na předchozí bod: váš kód bude nakonec legacy. Jak se budete pohybovat po žebříčku seniority, budou najati noví vývojáři a budou muset udržovat váš starý kód. Můžete napsat čistý, bezchybný, suchý kód, ale jakmile se změní konvence nebo se změní trendy, tito noví vývojáři mohou zobrazit váš kód stejným způsobem jako starší kód ostatních.

buďte hrdí na malé úspěchy

není snadné pracovat mimo vaše obvyklé konvence; existuje důvod pro obrovskou hromadu memů a vtipů o řešení staršího kódu. Pokud jste se kdy naučil jazyk mimo svůj rodný jazyk, víte, jaké to je zapomenout na slovo nebo výraz v druhém jazyce, ale pamatujte, že ve vašem rodném jazyce, a ne být schopen přeložit přes mezeru. Totéž platí pro změnu mezi moderními a staršími konvencemi. Někdy to trvá jen minutu, než se znovu zorientujete.

být schopen, aby se úspěšně navigovat legacy kód, ukazujete, že vaše schopnost být adaptabilní, což je důležitá dovednost, že výhody, které vám na vaší současné práci a všechny vaše budoucí zaměstnání, zda tyto úlohy jsou v technologické oblasti, nebo ne. Legacy code je ideálním hřištěm pro procvičování této dovednosti.

závěr:

využijte tento čas k posílení své vlastní psaní kódu

Nyní, že jste měl zkušenosti z práce v legacy codebase, měl bys jít pryč od toho s lepší smysl pro to, co se vám líbí a nelíbí v oblasti nástrojů a úmluv. To jsou věci, s nimiž můžete pokračovat v budoucích projektech, a zlepší vás v revizi kodexu ostatních, nabízí konstruktivní kritiku, a dávat mentorství.

Vyvíjet aplikace pro uživatele a budoucí vývojáře

Ať už jste měli zkušenosti z velké dokumentaci a kódu komentáře nebo žádná dokumentace nebo kódu komentáře, můžete vidět, jak oba dokumentace a komentáře jsou mocné nástroje, které pomohou budoucí vývojáři navigaci v projektu. Sdílíte společný cíl chtít hladký, funkční, a suchá aplikace; udržování dokumentace a zanechání informativních komentářů k kódu je dobrý způsob, jak tuto mezeru překlenout.

Pamatujte, že váš kód bude starší taky jednou

zmínil jsem to už několikrát, ale je důležité zdůraznit, že váš kód bude legacy taky, bez ohledu na to, jak SUCHÉ a nedotčené váš kód a logiku.

nejdůležitější je být flexibilní, pokorný a určitě se můžete naučit nové triky ze starého kódu.