A hagyatékok soha nem halnak meg: hogyan kell kezelni a örökölt kódot

amikor a “örökölt kód” kifejezés felmerül, általában megvetéssel mondják vagy fogadják. A “legacy code mémek” előzetes Google-keresése több száz képmakrót hoz fel azokról az emberekről, akik kitépik a hajukat, szétzúzottnak vagy rendkívül csalódottnak tűnnek.

amikor elkezdtem dolgozni, mint egy szoftverfejlesztő 6 hónappal ezelőtt, fogalmam sem volt, mi örökölt kód volt, vagy mi dolgozik vele járó.

junior fejlesztőként töltött negyedik hónapom során felkértek, hogy adjak hozzá egy keresési szűrő modált egy alkalmazáshoz, amelyet az egyik munkatársam épített két vagy három évvel ezelőtt. Elég könnyűnek tűnt; az elmúlt négy hónap nagy részét egy hihetetlenül összetett alkalmazáson dolgoztam egy másik ügyfél számára, amely magában foglalja a szokásos veremünket: TypeScript/React/Redux/Redux-Saga. Már sok egyedi problémát megoldottam, és elég magabiztosnak éreztem magam a kódolási képességemben ahhoz, hogy egy egyszerű modálist adjak át a lekérdezési paramétereknek a háttérbe.

mint talán kitaláltad, ez közel sem volt ilyen egyszerű. De miért?

mi a régi kód, és miért lehet nehéz kezelni

a régi kód egy másik fejlesztőtől vagy csapattól örökölt kód, amely régebbi technológiákat használ, amelyeket már nem támogat, vagy amelyeket egy újabb verzió felülírott. Sok programozó azt mondja, hogy”a kód örökölt kódgá válik, amint meg van írva”. A funkcionális különbség a “normál” kód és a régi kód között egyszerűen az lehet, hogy eltérő konvenciókkal rendelkezik ahhoz képest, amellyel megszokta a munkát.

Az én esetemben az alkalmazás, amelyhez hozzárendeltem, a TypeScript helyett a Flow-t használta, és nem volt olyan erősen gépelve, mint megszoktam. Ez egy kicsit nehezebbé tette számomra, hogy megértsem a háttérből letöltött adatok szerkezetét. Egyetlen típus sem jelentette azt, hogy sokkal gyakrabban futottam be a TypeErrors-ba a futási időben, ami nehéz lehet hibakeresés, ha nagy funkciót ír. Ezen felül, az alkalmazás a React sokkal régebbi verzióját használta, amelyet össze kellett egyeztetni a komponens könyvtár kompatibilis verziójával, amelyet a modál felépítéséhez akartam használni.

mielőtt belemennék a legacy code kezelésének apróságába a nyugalom és a racionalitás érzésével, szeretnék hozzáadni egy nyilatkozatot arról, hogy a legacy code nem minden rossz, és a legacy projekten való munkának nem kell szörnyűnek lennie. Éppen ellenkezőleg, a régi kóddal való munka megtanított arra, hogy rugalmas, türelmes legyek, és mindenekelőtt a tapasztalat lehetővé tette számomra, hogy új perspektívával oldjam meg a problémákat egy új kontextusban.

valójában jobb fejlesztővé tett, mint azelőtt, hogy elkezdtem dolgozni a fent említett kódbázison, és remélhetőleg a régi projekted is taníthat valamit.

hogyan kell kezelni a régi kódot technikai szinten

fotó: Jeff Sheldon on Unsplash

olvassa el a dokumentációt és a kód megjegyzéseket, amikor lehetséges

egy tökéletes világban minden kódbázisnak van egy robusztus README-je, amely tömör magyarázatokat tartalmaz a projekt működéséről, kódmegjegyzéseket, amelyek megmagyarázzák az eredeti szerző pontos logikáját, és az egész alkalmazásnak tökéletes értelme van. Ez azonban ritkán fordul elő. Sok READMEs nem frissül a projektek fejlődésével, az emberek elfelejtenek megjegyzéseket írni, feltételezik, hogy logikájuk nyilvánvaló egy új fejlesztő számára, vagy egyszerűen elfogy az idő, hogy vigyázzon ezekre a dolgokra.

nézze meg a kódbázis egészét

ha elveszett, és nem tudja, hol kezdje, tegye fel magának ezeket a kérdéseket:

• mi az alkalmazás célja?
• hogyan folyik az adat az alkalmazáson keresztül?
• hogyan illeszkedik a funkció az alkalmazásba?

amikor megértheti a nagy képet, könnyebb kitalálni, hogyan lehet a legjobban kezelni a problémát. Lehet, hogy létre kell hoznia egy új fájlt, és létre kell hoznia egy új összetevőt. Talán meg kell írni egy segédprogram funkciót, és tesztelni. Bármi legyen is az eset, a probléma tágabb kontextusának megértése jó első lépés a megoldás létrehozásához.

tesztelje az alkalmazást manuálisan és egységtesztekkel, amikor csak lehetséges

Az alkalmazás ideiglenes megszakítása új funkció hozzáadása közben elkerülhetetlen, függetlenül attól, hogy milyen szintű fejlesztő vagy. Ez normális és várható, különösen akkor, ha új vagy a munkában, egy régi kódbázisban dolgozik egy ismeretlen veremmel, vagy a kettő valamilyen kombinációjával.

a legjobb módja annak, hogy megakadályozzák, hogy ezek a törések hosszú távú problémákká váljanak, az alkalmazás alapos tesztelése mind az egységtesztekkel, mind a kézi tesztekkel. Ha ezeket a teszteket a helyén tartja, és pontosan tudja, hogy milyen lefedettséget kap tőlük, sok időt takarít meg Önnek és a jövőbeli fejlesztőknek. Ezen túlmenően, a szigorú vizsgálatok, hogy az alkalmazás több skálázható, valamint kapsz egy litte dopamin rohanás minden alkalommal, amikor a vizsgálatok futnak tiszta.

az egység teszteléséhez használhat olyan tesztkereteket, mint a Jest vagy a Jasmine.

a kézi tesztekhez egy tesztmátrixot kell kifejleszteni, és biztosítani kell, hogy a dokumentum hozzáférhető legyen a jövőbeli fejlesztők számára. A mátrix esetében meg kell határoznia egy sor műveletet, a várható viselkedést, a tényleges viselkedést, amikor teszteli, és minden más fontos részletet, mint például:

egy jövőbeli blogbejegyzésben ismertetem, hogyan lehet mindkét típusú tesztelést hatékonyan végrehajtani a munkafolyamatban.

kérjen segítséget

feltételezve, hogy a projektet egy jelenlegi vagy korábbi alkalmazott írta a munkahelyén, valaki más valószínűleg tudja, mi folyik az alkalmazásban, vagy legalábbis eleget tud ahhoz, hogy megszabadítson. A büszkeség lenyelése és valaki más megkérdezése kényelmetlen lépés egyesek számára, de szükséges ahhoz, hogy fejlesztőként növekedjen, és talán munkatársa megtaníthat néhány új trükköt.

az idő (és az övék) hatékony felhasználásának jó módja a tájékozott kérdések megfogalmazása. Próbáljon visszatérni a kódbázis egészére, és találja ki a megértés hiányosságait. Nem csak segít nekik abban, hogy jobban megértsék, mi a problémád, hanem azt is mutatja, hogy kezdeményezte, hogy először egyedül próbálja megoldani a problémát.

Tudja meg, mikor kell csökkenteni a veszteségeit

Ha túl sok időt tölt azzal, hogy megpróbálja betenni a lábát az ajtóba, és a fenti lépések kipróbálása után nem tett komoly lépéseket a funkció megvalósítása felé, érdemes lehet A kód újratervezése a funkció körül. Ne add fel túl könnyen, de tartsd szem előtt, hogy milyen határidők vannak, és mit vár el tőled a projektmenedzser.

ennek ellenére vannak hátrányai is:

• a kód átírása hibákat okozhat, bár ezt jó egységteszteléssel kissé meg lehet kerülni.
• a kód átírása eltávolíthatja a rejtett funkciókat, bár ez jó egységtesztekkel is megkerülhető.
• ha időigényes, akkor a funkción kívüli kód írása a funkción kívül valójában időigényesebb lehet, mint csak körülötte építeni.

mindent összevetve, használja a legjobb megítélését. Vannak előnyök és hátrányok bármelyik választáshoz, és mindez az egyéni körülményektől és a projekt költségvetésétől függ.

hogyan kell kezelni a legacy kódot pszichológiai szinten

fotó: Simon Migaj on Unsplash

most, hogy lefedtük a legacy kód kezelésének technikai szempontjait, beszéljünk arról, hogyan kell kezelni a puha készségeinkkel. Végül is a fejlesztők emberek, nem csak robotok kódolása, és a kreativitást és szerzőséget igénylő projektek kihívást jelentő problémáinak kezelése érzelmileg megterhelő lehet, nem csak neked, hanem munkatársainak is.

Légy alázatos és kedves

Ez olyasmi, amit szégyenlősen elismerem, hogy többet kell gyakorolnom. Amikor először kaptam a filter modal projektet, meglehetősen hangos voltam arról, hogy janky és nem vonzó a kód kezelése, miközben a kód eredeti szerzője ült 15 méterre tőlem. Viccnek szántam a hozzászólásaimat, de utólag felismertem, hogy arrogáns és bántó voltam, és hogy empatikusabbnak kellett volna lennem.

sok tényező vezethet ahhoz, hogy a régi kód “kikapcsolt” legyen, amelyet figyelembe kell vennie, mielőtt kritizálni kezdené a szerzőt, vagy a legrosszabbat feltételezné róluk (ez lazán kapcsolódik az alapvető hozzárendelési hibához!).

lehet, hogy az eredeti szerzőnek oka volt arra, hogy a kódot úgy írja, ahogy tette.

az időkorlátok és a technológiai korlátok miatt az ember olyan kódot írhat, amely működik, de nem feltétlenül a legjobb konvencióval rendelkezik. Ha olyan helyzetben képzeled el magad, ahol nincs elég idő, elavult eszközök és egy mérföld hosszú todo lista, akkor valószínűleg nem írnád meg a legjobb kódot sem!

A konvenciók megváltoznak.

régebbi Olio Apps projektekben a kód konvenciója egyetlen idézőjelet használ a karakterláncok deklarálásához, és két szóköz egyenlő egy lappal. Több kis React komponens volt beágyazva egyetlen fájlba. A jelenlegi konvenciónkban dupla idézőjeleket és négy szóközt használunk, és minden React komponens, bármilyen kicsi is, a saját .tsx fájljában él a component könyvtárban. Néhány év múlva biztos vagyok benne, hogy ez is változni fog.

minden kód végül örökséggé válik

Ez visszatér az előző ponthoz: a kód végül örökölt lesz. Ahogy feljebb lépsz a ranglétrán, új fejlesztőket vesznek fel, akiknek meg kell őrizniük a régi kódot. Lehet, hogy tiszta, hibátlan, száraz kódot ír, de ha a konvenciók vagy a trendek megváltoznak, az új fejlesztők ugyanúgy tekinthetik meg a kódot, mint mások régi kódját.

Légy büszke a kis sikerekre

nem könnyű a szokásos konvenciókon kívül dolgozni; oka van a mémek és viccek hatalmas tárházának a régi kód kezelésével kapcsolatban. Ha valaha is megtanultál egy nyelvet az anyanyelveden kívül, tudod, milyen érzés elfelejteni egy szót vagy kifejezést a második nyelveden, de emlékezz rá az anyanyelveden, és nem tudsz lefordítani a szakadékon. Ugyanez vonatkozik a modern és a régi konvenciók közötti váltásra is. Néha csak egy percet vesz igénybe, hogy visszanyerje a csapágyakat.

azzal, hogy sikeresen navigálhat a régi kódban, megmutatja, hogy képes-e alkalmazkodni, ami fontos készség, amely előnyös a jelenlegi és az összes jövőbeli munkahelyén, függetlenül attól, hogy ezek a munkahelyek a technológia területén vannak-e vagy sem. A Legacy code a tökéletes játszótér ennek a képességnek a gyakorlásához.

összefoglalva:

használd ezt az időt arra, hogy megerősítsd a saját kódírásodat

most, hogy már van tapasztalatod egy régi kódbázisban dolgozni, jobban meg kell értened, hogy mit szeretsz és mit nem szeretsz az eszközök és a konvenciók szempontjából. Ezek azok a dolgok, amelyeket folytathat a jövőbeli projektekben, és jobban áttekintheti mások kódját, építő kritikát kínál, és mentorál.

alkalmazások fejlesztése a felhasználó és a jövőbeli fejlesztő számára

függetlenül attól, hogy tapasztalt-e nagyszerű dokumentációs és kódmegjegyzéseket, vagy nincs-e dokumentációs vagy kódmegjegyzés, láthatja, hogy mind a dokumentáció, mind a Megjegyzések hatékony eszközök a jövőbeli fejlesztők számára a projektben való navigáláshoz. Közös célja, hogy sima, funkcionális és száraz alkalmazást szeretne; a dokumentáció fenntartása és az informatív kódmegjegyzések hátrahagyása jó módja annak, hogy áthidalja ezt a szakadékot.

ne feledje, hogy a kódod egy nap örökölni fog

ezt már néhányszor említettem, de fontos megismételni, hogy a kódod is örökölt lesz, függetlenül attól, hogy a kódod és a logikád mennyire száraz és tiszta.

a legfontosabb elvihetőség az, hogy rugalmas, alázatos, és hogy határozottan megtanulhat új trükköket a régi kódból.