Rady, jak zacházet se starým kódem

Kultovní APPLE MACINTOSH 128K

Když se objeví pojem „dědický kód“, obvykle se říká nebo přijímá s nádechem pohrdání. Předběžné vyhledávání „pamětních kódových pamětí“ na Googlu přináší stovky a stovky obrazových maker lidí, kteří trhají vlasy, vypadají rozcuchaně nebo velmi zklamaní.

Když jsem před 5 měsíci začal pracovat jako softwarový vývojář ve společnosti založené na produktu, neměl jsem tušení, jaký starší kód je nebo co s ním práce znamená.

Během mého čtvrtého měsíce jsem byl požádán o přidání modemu přepínače filtrů do aplikace vytvořené jedním z mých spolupracovníků před dvěma nebo třemi lety. Vypadalo to dost snadno; Většinu posledních tří let jsem strávil prací na neuvěřitelně složité aplikaci zahrnující standardní zásobník: TypeScript / React / Angular / Dotnet. Už jsem vyřešil mnoho jedinečných problémů a cítil jsem se sebejistý v mé kódovací schopnosti natolik, abych vytvořil jednoduchý modal, který předá parametry dotazu backendu.

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

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

Starší kód je kód zděděný od jiného vývojáře nebo týmu, který používá starší technologie, které již nejsou podporovány nebo byly nahrazeny novější verzí. Mnoho programátorů říká, že „kód se stane starým kódem, jakmile bude napsán“. Funkční rozdíl mezi „běžným“ kódem a starým kódem by mohl jednoduše spočívat v tom, že má odlišné konvence ve srovnání s tím, na co jste zvyklí.

V mém případě aplikace využívala spíše textovou šablonu XAML a T4 než základní kód C # a nebyla tak silně zadaná, jako jsem byl zvyklý. To pro mě bylo trochu těžší pochopit strukturu dat. Žádné typy neznamenaly, že jsem běžel do TypeErrors za běhu mnohem častěji, což může být obtížné ladit, když píšete velkou funkci. Kromě toho aplikace používala mnohem starší verzi dotnetu, kterou bylo třeba sladit s kompatibilní verzí knihovny komponent.

Než se dostanu do drzosti o tom, jak zacházet se starým kódem se smyslem pro poezii a racionalitu, chci přidat vyloučení odpovědnosti, že starší kód není tak špatný a práce na starém projektu nemusí být hrozná. Naopak, práce na dědickém kódu mě naučila být pružný, trpělivý a především další, zkušenosti mi umožnily šanci vyřešit problémy s novou perspektivou v novém kontextu.

Ve skutečnosti jsem z toho udělal lepšího vývojáře, než jsem byl předtím, než jsem začal pracovat s výše uvedenou kódovou základnou, a doufejme, že váš starší projekt vás také může naučit.

Jak zacházet se starým kódem na technické úrovni

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

V dokonalém světě má každá kódová základna robustní README, která obsahuje stručná vysvětlení toho, jak projekt funguje, komentáře k kódům, které vysvětlují přesnou logiku původního autora, a celá aplikace dává dokonalý smysl. To je však zřídka případ. Mnoho README se neaktualizuje, jak se projekty vyvíjejí, lidé zapomínají psát komentáře, předpokládají, že jejich logika je zřejmá pro nového vývojáře, nebo jim prostě došel čas postarat se o ty věci.

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

Pokud jste ztraceni a nevíte, kde začít, zeptejte se sami sebe na tyto otázky:

  • Jaký je účel aplikace?
  • Jak proudí data aplikací?
  • Jak se vaše funkce vejde do aplikace?

Když získáte představu o velkém obrazu, je snazší zjistit, jak nejlépe tento problém vyřešit. Možná budete muset vytvořit nový soubor a vytvořit nový řadič. Možná budete muset napsat obslužnou funkci a otestovat ji. Ať už je to jakýkoli případ, porozumění širšímu kontextu vašeho problému je dobrým prvním krokem k vytvoření řešení.

Testujte aplikaci ručně a pomocí testů jednotek, kdykoli je to možné

Dočasné přerušení aplikace při přidávání nové funkce je nevyhnutelné, bez ohledu na to, jakou úroveň vývojáře jste. To je normální a očekávané, zejména pokud jste v práci nováčkem, pracujete ve staré kódové základně s neznámým zásobníkem nebo nějakou kombinací obou.

Nejlepší způsob, jak těmto zlomům zabránit, aby se staly dlouhodobými problémy, je důkladné testování aplikace pomocí testů jednotek i ručních testů. Pokud tyto testy provedete a přesně víte, jaké pokrytí z nich získáte, ušetří vám i budoucím vývojářům spoustu času. Díky přísným testům je aplikace škálovatelnější a také vám dá trochu dopaminového spěchu pokaždé, když jsou vaše testy čisté. V mém scénáři bohužel existují omezené případy testování jednotek

V případě ručních testů budete chtít vyvinout testovací matici a zajistit, aby byl dokument přístupný budoucím vývojářům. Pro matici budete chtít definovat sadu akcí, očekávané chování, skutečné chování při jeho testování a další důležité podrobnosti, jako například:

Požádat o pomoc

Za předpokladu, že váš projekt byl napsán současným nebo bývalým zaměstnancem na vašem pracovišti, někdo pravděpodobně ví, co se v aplikaci děje, nebo alespoň ví dost, aby vás nezastavil. Naučit se spolknout svou pýchu a požádat někoho jiného je pro některé nepříjemný krok, ale nutný pro růst jako vývojář a možná váš spolupracovník vás naučí pár 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 kódovou základnu jako celek a zjistit mezery ve vašem porozumění. Nejenže jim to pomůže získat lepší představu o tom, co je váš problém, ale také ukazuje, že jste se nejprve pokusili vyřešit problém sami.

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

Pokud trávíte příliš mnoho času pokusem dostat nohu do dveří a neučinili jste žádný vážný krok k implementaci funkce po vyzkoušení výše uvedených kroků, může být užitečné refactoring kód kolem funkce. Nevzdávejte se příliš snadno, ale také mějte na paměti, jaké jsou vaše termíny a co váš projektový manažer od vás očekává.

To znamená, že existují určité nevýhody, pokud jde o to takto:

  • Přepisovací kód může představovat chyby, i když to může být obcházeno při dobrém testování jednotek.
  • Přepisovací kód může odstranit skrytou funkčnost, i když to lze obejít i dobrými testy jednotek.
  • Pokud stisknete nějaký čas, psaní kódu mimo vaši funkci může být kromě vaší funkce časově náročnější, než když se kolem ní budete stavět.

Celkově vzato používejte svůj nejlepší úsudek. Existují výhody a nevýhody obou možností a vše závisí na vašich okolnostech a rozpočtu projektu.

Jak se vypořádat s dědickým kódem na psychologické úrovni

Nyní, když jsme se zabývali technickými aspekty zacházení se starým kódem, pojďme mluvit o tom, jak se s ním vypořádat pomocí našich měkkých dovedností. Konec konců vývojáři jsou lidé, nejen kódování robotů, a řešení náročných problémů u projektů, které vyžadují kreativitu a autorství, může být emocionálně zdanitelné nejen pro vás, ale také pro vaše spolupracovníky.

Buďte skromní a laskaví

To je něco, co si nesmyslně přiznávám, že potřebuji více trénovat. Když mi byl poprvé přidělen projekt modálního filtru, byl jsem docela vokální o tom, jak by se měl žánr a neochotný kód vypořádat, zatímco původní autor kódu seděl 15 metrů od mě. Měl jsem v úmyslu své připomínky považovat za vtip, ale vzadu jsem si uvědomil, že jsem byl arogantní a zraněný a že jsem měl být více empatický.

Existuje mnoho faktorů, které mohou vést k tomu, že starší kód vypadá „mimo“, který byste měli vzít v úvahu dříve, než začnete kritizovat autora nebo předpokládat nejhorší z nich (to je volně spojeno se základní chybou přiřazení!).

Původní autor mohl mít 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í nutně mít nejlepší konvenci. Pokud si představujete sami sebe v situaci, kdy nemáte dostatek času, zastaralé nástroje a seznam úkolů dlouhý kilometr, pravděpodobně byste ani nenapsali ten nejlepší kód!

Konvence se mění.

Ve starších projektech používá konvence pro kód k deklarování řetězců jednoduché uvozovky a dva mezery se rovnají jedné kartě. Uvnitř jednoho souboru jsme vnořili několik malých tříd. V naší současné konvenci používáme dvojité uvozovky a čtyři mezery a každá třída, bez ohledu na to, jak malá, žije ve svém vlastním .csfile v adresáři Modely. A za několik let jsem si jistý, že se to také změní.

Celý kód se nakonec stane odkazem

To navazuje na předchozí bod: váš kód bude nakonec odkazem. Jak postupujete po žebříčku seniority, budou najati noví vývojáři a bude si muset zachovat váš starý kód. Můžete napsat čistý, bezchybný DRY ​​kód, ale jakmile se změní konvence nebo se změní trendy, mohou tito noví vývojáři zobrazit váš kód stejným způsobem, jakým si prohlížíte starší kód ostatních.

Pýchou na malé úspěchy

Není snadné pracovat mimo vaše obvyklé konvence; existuje důvod pro obrovskou zápletku memů a vtipů o zacházení se starým kódem. Pokud jste se někdy naučili jazyk mimo svůj rodný jazyk, víte, jaké to je zapomenout na slovo nebo termín ve vašem druhém jazyce, ale pamatujte si ho ve svém rodném jazyce a nemůžete 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 vaše ložiska znovu objeví.

Abyste mohli úspěšně procházet starým kódem, prokazujete svou schopnost být adaptabilní, což je důležitá dovednost, která těží z vaší současné práce a ze všech vašich budoucích pracovních pozic, ať už jsou tyto pozice v technologické oblasti nebo ne. Starší kód je ideální hřiště pro procvičení této dovednosti.

Na závěr

Použijte tento čas k posílení psaní vlastního kódu

Nyní, když jste měli zkušenost s prací ve staré kódové základně, měli byste se od ní vzdát s lepším smyslem pro to, co se vám líbí a nelíbí, pokud jde o nástroje a konvence. To jsou věci, s nimiž můžete pokračovat v budoucích projektech, a vylepšit tak revizi kódu ostatních, konstruktivní kritiku a vedení mentorství.

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

Ať už jste měli zkušenost s velkou dokumentací a komentáři k kódům nebo bez dokumentace nebo s komentáři k kódům, můžete vidět, jak jsou dokumentace i komentáře účinnými nástroji, které pomáhají budoucím vývojářům při navigaci v projektu. Sdílíte společný cíl, kterým je hladká, funkční a SUCHÁ aplikace; udržování dokumentace a zanechání komentářů s informativními kódy je dobrý způsob, jak tuto mezeru překlenout.

Nezapomeňte, že váš kód bude někdy také starý

Už jsem o tom několikrát zmínil, ale je důležité znovu zopakovat, že váš kód bude také starý, bez ohledu na to, jak suchý a nedotčený je váš kód a logika.

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