Tanácsok a régi kód kezelésére

Az Iconic APPLE MACINTOSH 128K

Amikor megjelenik a „örökölt kód” kifejezés, ezt általában megvetett árnyalattal mondják vagy fogadják. A „régi kódmémek” előzetes Google-keresése száz és száz képmakrót hoz fel, amelyekben az emberek kitépik a hajukat, összetörtnek látszanak, vagy nagyon csalódottak.

Amikor 5 hónappal ezelőtt elkezdtem szoftverfejlesztőként dolgozni egy termék alapú vállalatban, fogalmam sem volt, mi a régi kód vagy mit jelent a vele való munka.

A negyedik hónapom során felkértek tőlem, hogy adjunk hozzá egy kapcsolószűrő modult egy alkalmazáshoz, amelyet két vagy három évvel ezelőtt egyik munkatársam épített. Elég könnyűnek tűnt; Az elmúlt három év nagy részét hihetetlenül összetett alkalmazáson dolgoztam, amely magában foglalja a szabványos veremét: TypeScript / React / Angular / Dotnet. Már számos egyedi problémát megoldottam, és eléggé magabiztosnak éreztem magam a kódolási képességeimben ahhoz, hogy egy egyszerű módszert elkészítsem a lekérdezési paraméterek átadására a háttérrendszerhez.

Mint talán már kitalálta, ez nem volt szinte ilyen egyszerű. De miért?

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

A régi kód egy másik fejlesztőtől vagy csapattól örökölt kód, amely olyan régebbi technológiákat használ, amelyeket már nem támogatnak, vagy amelyeket egy újabb verzió vált fel. Sok programozó azt állítja, hogy „a kód örökölt kódmá válik, miután megírták”. A „normál” kód és a régi kód közötti funkcionális különbség egyszerűen az lehet, hogy eltérő konvenciókkal rendelkezik, összehasonlítva azzal, amivel szokott dolgozni.

Az én esetemben az alkalmazás az XAML és T4 szöveges sablonokat használta, nem pedig az alapvető C # kódot, és nem volt olyan erősen gépelve, mint amilyenhez megszoktam. Ez egy kicsit nehezebbé tette az adatok szerkezetének megértését. Egyetlen típus sem jelentette azt, hogy sokkal gyakrabban futottam be a TypeErrors programba a futásidejű számítógépeken, melyeket nehéz lehet hibakeresni, ha egy nagy funkciót ír. Ezen felül az alkalmazás a dotnet sokkal régebbi verzióját használta, amelyet össze kellett hangolni a komponens könyvtár kompatibilis verziójával.

Mielőtt belekapaszkodnék a régimódi szemcsékbe, hogy miként kell kezelni az örökölt kódot az ösztön és a racionalitás érzésével, szeretnék hozzáfűzni egy nyilatkozatot, miszerint a régi kód nem minden rossz, és a régi projekten dolgozni nem kell szörnyűnek lennie. Éppen ellenkezőleg, a régi kód kidolgozása megtanította, hogy rugalmasnak, türelmesnek kell lennem, és mindenekelőtt a tapasztalat lehetőséget adott számomra, hogy új kontextusban új szemszögből megoldhassam a problémákat.

Valójában jobb fejlesztővé tett engem, mint amennyire korábban elkezdtem dolgozni a fentebb említett adatbázisban, és remélhetőleg az örökölt projekt taníthat neked is valamit.

Hogyan kell kezelni a régi kódot műszaki szinten?

Olvassa el a dokumentációt és a kód megjegyzéseit, ha lehetséges

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

Nézze meg a kódbázist mint egészet

Ha elveszett, és nem tudja, hol kezdje, kérdezze meg magadtól a következő kérdéseket:

  • Mi az alkalmazás célja?
  • Hogyan áramlik az adat az alkalmazáson keresztül?
  • Hogyan illeszkedik a szolgáltatás az alkalmazásba?

Ha megismerheti a nagy képet, könnyebb kitalálni, hogyan lehet a legjobban kezelni a problémát. Talán új fájlt kell létrehoznia, és új vezérlőt kell létrehoznia. Talán meg kell írnia egy segédfunkciót és tesztelnie kell azt. Bármi legyen is a helyzet, a probléma szélesebb kontextusának megértése jó első lépés a megoldás megteremtéséhez.

Tesztelje az alkalmazást kézzel és egységteszttel, amikor csak lehetséges

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

A legjobb módszer annak elkerülésére, hogy ezek a törések hosszú távú problémává váljanak, az alkalmazás alapos tesztelése mind az egység tesztekkel, mind a kézi tesztekkel. Ha ezek a tesztek helyben vannak, és pontosan tudják, hogy milyen lefedettséggel bocsát ki őket, sok időt takaríthat meg Önnek és a jövőbeli fejlesztőknek. A szigorú tesztek emellett az alkalmazást méretezhetőbbé teszik, és minden alkalommal, amikor a tesztek tisztán futnak, egy kis dopamin-rohanást eredményeznek. Sajnos korlátozott egységteszt esetek vannak a forgatókönyvemen

A kézi tesztekhez ki kell dolgoznia egy tesztmátrixot, és ellenőriznie kell, hogy a dokumentum elérhető-ea jövőbeli fejlesztők számára. A mátrix számára meg kell határoznia a műveletek halmazát, a várható viselkedést, a tényleges viselkedést a teszteléskor és minden egyéb fontos részletet, például:

Kérjen segítséget

Feltételezve, hogy a projektet a munkahelyen jelenlegi vagy volt alkalmazott írta, valószínűleg valaki más tudja, mi folyik az alkalmazásban, vagy legalább annyit tud, hogy kibocsássa. A büszkeség lenyelésének és másoktól való megkérdezésének tanulása mások számára kellemetlen lépés, ám ehhez szükséges egy fejlesztőként való növekedés, és talán munkatársa néhány új trükköt taníthat neked.

Ideje (és ö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 nézve, és derítse ki a megértés hiányosságait. Ez nem csak segít nekik abban, hogy jobban megértsék, mi a problémája, hanem azt is mutatja, hogy Ön a kezdeményezést vállalta, hogy először saját maga próbálja megoldani a problémát.

Tudja meg, mikor csökkenti a veszteségeit

Ha túl sok időt töltsön a lábát az ajtón, és nem tett komoly lépést a szolgáltatás bevezetése felé a fenti lépések kipróbálása után, akkor érdemes lehet újra kódolni a kódot a szolgáltatás körül. Ne feladja túl könnyen, de ne feledje, hogy mik a határidők, és mit vár el tőled a projektmenedzser.

Ennek ellenére vannak hátrányai annak, ha így folytatjuk:

  • A kód újraírásával hibákat lehet bevezetni, bár ezt jó egységteszttel megkerülhetjük.
  • A kód újraírásával eltávolíthatók a rejtett funkciók, bár ezt jó egységteszttel is megkerülhetjük.
  • Ha időigényes, akkor a szolgáltatáson kívüli kódírás a funkción kívül sokkal időigényesebb lehet, mint pusztán az épület.

Mindent összevetve, használja a legjobb megítélését. Előnyeik és hátrányai vannak bármelyik választáshoz, és mindez az Ön körülményeitől és a projekt költségvetésétől függ.

Hogyan lehet kezelni a régi kódot pszichológiai szinten?

Most, hogy már lefedtük a régi kód kezelésének technikai aspektusait, beszéljünk arról, hogyan kell kezelni azt puha képességeink felhasználásával. Végül is a fejlesztők emberek, nem csak a robotok kódolása, és a kreativitást és a szerzők megkötését igénylő projektek kihívásokkal való küzdelme érzelmileg adóztatást okozhat, nemcsak Önnek, hanem munkatársainak is.

Légy alázatos és kedves

Ez olyasmi, amit félénken elismerek, hogy többet kell gyakorolnom. Amikor először kijelölték a szűrő modális projektet, meglehetősen hangosan gondolkodtam arról, hogy Janky és milyen vonzónak kell lennie a kódnak, miközben a kód eredeti szerzője 15 méterre volt tőlem. Megjegyzéseim viccnek szánták, de utólagosan felismerem, hogy arrogáns vagyok és bántó, és empatikusabb kellett volna lennem.

Számos tényező vezethet ahhoz, hogy a régi kód „kikapcsolódjon”, amelyet figyelembe kell venni, mielőtt elkezdené kritizálni a szerzőt, vagy feltételezni a legrosszabbat ezekről (Ez lazán kapcsolódik az alapvető hozzárendelési hibához!).

Lehet, hogy az eredeti szerzőnek oka van arra, hogy a kódot úgy írja, mint ők.

Az időkorlátozások és a technológiai korlátok miatt az emberek írhatnak olyan kódot, amely működik, de nem feltétlenül rendelkezik a legjobb konvencióval. Ha olyan helyzetben képzel el magát, ahol nincs elég idő, elavult eszközök és egy mérföld hosszú teendők listája, akkor valószínűleg nem is írja a legjobb kódot!

Az egyezmények megváltoznak.

Régebbi projektekben a kódmegállapodás egy idézőjelet használ a karakterláncok deklarálására, és két szóköz megegyezett egy fülön. Több kis osztály volt beágyazva egyetlen fájlba. Jelenlegi konvenciónkban dupla idézőjeleket és négy szóközt használunk, és mindegyik osztály, függetlenül attól, hogy kicsi, a saját .cs fájljában él a Models könyvtárban. És néhány év alatt biztos vagyok benne, hogy ez is megváltozik.

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

Ez visszatér az előző ponthoz: a kódja végül örökség lesz. Ahogy feljebb lépsz a szolgálati létrán, új fejlesztőket alkalmaznak, és meg kell tartaniuk a régi kódot. Lehet, hogy tiszta, hibátlan, DRY kódot ír, de ha a konvenciók vagy a trendek megváltoznak, akkor az új fejlesztők ugyanúgy tekinthetik meg a kódot, mint mások örökölt kódját.

Büszke lehet a kis sikerekre

Nem könnyű a szokásos konvencióin kívül dolgozni; ok van a mémek és a viccek óriási vágyára, amelyek a régi kóddal foglalkoznak. Ha valaha is megtanultál valamit egy anyanyelvén kívül, akkor tudod, milyen érzés elfelejteni egy szót vagy kifejezést a második nyelvén, de emlékszel rá anyanyelvén, és nem tudsz fordítani. Ugyanez vonatkozik a modern és a régi hagyományok közötti váltásra. Időnként csak egy percet vesz igénybe, hogy visszanyerje csapágyait.

Annak érdekében, hogy sikeresen navigáljon a régi kódban, megmutatja alkalmazkodóképességét, ami egy fontos készség, amely előnyei lehetnek jelenlegi állása és minden jövőbeli munka során, függetlenül attól, hogy ezek a munkák a technológiai területen vannak-e vagy sem. A Legacy kód a tökéletes játszótér e készség gyakorlására.

Összefoglalva

Ezt az időt használhatja saját kódírásának megerősítésére

Most, hogy már rendelkezik tapasztalatával egy régi kódbázisban való munka során, jobban meg kell értetnie, hogy mi az, ami az eszközök és az egyezmények szempontjából tetszik és mit nem tetszik. Ezek a dolgok, amelyeket folytathat a jövőbeli projektekben, és jobban megkönnyítik mások kódexének áttekintését, konstruktív kritika felkínálását és mentorálást.

Készítsen alkalmazásokat a felhasználó és a jövőbeli fejlesztő számára

Függetlenül attól, hogy nagy tapasztalattal rendelkezik nagyszerű dokumentációval és kódmegjegyzésekkel, vagy nincs dokumentáció vagy kódmegjegyzés, láthatja, hogy mind a dokumentáció, mind a megjegyzések hatékony eszközökkel segítik a jövőbeli fejlesztőket a projektben való navigálásban. Közös célja, hogy sima, funkcionális és SZÁRÍTÓ alkalmazást válasszon; A dokumentáció karbantartása és az informatív kódmegjegyzések elhagyása jó módszer a rés áthidalására.

Ne felejtsd el, hogy a kódod valaha is örökölt lesz

Ezt már néhányszor említettem, de fontos ismételni, hogy a kódod is örökségű lesz, függetlenül attól, hogy SZÁRÍTOTT és tiszta a kód és a logika.

A legfontosabb elvitel az, hogy rugalmas legyen, szerény és hogy mindenképpen új trükköket tanulhasson a régi kódból.