9 módja a szörnyű kód elsajátításának, gyors

azt a feladatot kapta, hogy új funkciót hajtson végre egy régi kódbázison, de a kód szörnyen néz ki. Hogyan lehet ezt a lehető leggyorsabban megérteni? Íme néhány parancsikon, amelyek segítenek megtanulni az új kód fontos részeit anélkül, hogy eltévednének az irreleváns részletekben.

programozóként gyakran új projektekhez kell csatlakoznunk, és a kód minősége mindenütt megtalálható. Még egy szervezett csapatnál is kihívást jelent a kódminőség konzisztens tartása egy közepes méretű és nagy projekt során.

ezért a gyenge kód gyors megértése értékes készség lehet. Ez segíthet abban, hogy rövid idő alatt nagyon produktívvá váljon, és csökkentse a stresszt, ami általában az új srácnak és a felzárkózásnak köszönhető. Szörnyű érzés, hogy egy munkatárssal beszélgetünk, és nem tudjuk, miről beszél ez a személy.

másrészt ez egy kiváló lehetőség arra, hogy megmutassa ügyfelének vagy főnökének az értékét, és hogy gyorsan felgyorsuljon és lenyűgözze őket. A legtöbb fejlesztőnek hetekig vagy hónapokig tart, hogy valóban produktívvá váljon egy olyan kódbázissal, amelyet nem maguk építettek.

így lehet gyorsan elsajátítani a szörnyű kódot.

kérjen segítséget. Ez a leghatékonyabb stratégia

mások már megtanulták, hogyan működik a kód, miért nem kérdezi meg őket róla? Azt gondolhatja, hogy ettől úgy néz ki, mint az újszülött, de a kíváncsiság megmutatása erősen befolyásolhatja munkavállalói imázsát. Ha a főnöke elvárása az volt, hogy gyorsan produktívvá váljon kérdések feltevése nélkül, ez téves megítélés a részéről.

mindenki időt vesz igénybe, hogy felgyorsuljon. Tegyen fel kérdéseket, és lenyűgözni fogja azokat az embereket, akik megfelelő hozzáállással rendelkeznek a csapatmunkához.

sok esetben az eredeti fejlesztők furcsa vagy váratlan döntéseket hoznak, és ez az, ahol a kódról beszélni sokkal értékesebb lesz, mint olvasni. Még inkább ez a helyzet, ha hiányzik a dokumentáció. Ne feledje,hogy a meglévő Fejlesztők értékes projektismeretekkel rendelkeznek, amelyeket sehol nem írnak.

Készítsen listát azokról a fogalmakról, amelyeknek nincs értelme az Ön számára

lehetnek olyan üzleti koncepciók, amelyek újak vagy túlságosan összetettek. Fontos, hogy tisztázzuk őket, mielőtt megpróbálnánk dolgozni az ezeket a fogalmakat kezelő kódon, hogy elkerüljük a félreértéseket, amelyek kitalálása eltarthat egy ideig.

még az is előfordulhat, hogy ezeket az ötleteket tévesen címkézik vagy váratlan módon ábrázolják egy adatbázisban. Tehát kerülje a stresszt, hogy az agyad köré tekerje, és csak menjen a forráshoz,és kérdezze meg munkatársait.

ugyanebben az értelemben lehetnek olyan modulok, osztályok vagy entitások, amelyeknek nincs megfelelő neve. Jegyezze fel őket. A rosszul megnevezett elemek nagy zavart okozhatnak, ezért korán dokumentálja őket, valamint bármi mást, ami negatívan befolyásolja a kód működésének gondolkodási képességét.

könnyítse meg a hibák reprodukálását

a kódverzió és egy virtuális gép, például a Docker vagy a Vagrant hozzáadásával jelentősen csökkentheti a hiba reprodukálásához és az új funkció teszteléséhez szükséges időt.

a kód működésével kapcsolatos bármilyen félreértés rossz dolog felépítéséhez vezethet, vagy azért, mert amit építesz, lehet, hogy már ott van, és nem láttad, vagy azért, mert a dolgok egyszerűen nem úgy működnek, ahogy gondoltad.

ezen a ponton a GIT verzióvezérlését szeretné a projektben. Így visszatérhet egy stabil kiadáshoz, vagy akár csak külön ágakon is dolgozhat, amelyeket szükség esetén el lehet dobni.

még a GIT segítségével is nagyobb reprodukálhatóságot lehet elérni, mivel a rejtekhely segítségével tesztelési vagy hibakeresési kódot adhat hozzá, miközben egy nehezen nyomon követhető problémába ás.

ha többet szeretne megtudni a projekt architektúrájáról, Korán kezdje el a konfigurációs és dokumentációs feladatokat.

ugyanez mondható el a virtuális gépekről és a reprodukálhatóságról. Minden modern fejlesztőcsapat számára mindenütt jelen vannak, de minden bizonnyal olyan projektekbe fog belefutni, amelyek nem használják őket, vagy akár készen állnak az egyikben való futtatásra. Néha az első lépés új csapattagként az, hogy dokumentálja a környezet működéséhez szükséges lépéseket, és végül ezeket a lépéseket virtuális gép telepítő szkriptjévé alakítja.

összetevők diagramjának elkészítése

az üzleti koncepciók elme térképe, az adatbázis-táblák entitás-relációs diagramja (ERD) és a kódösszetevők egyszerű diagramja nagyban segíthet csökkenteni az új kód megértésének fájdalmát. Nem emlékszel, hogyan működik valami? Tartsd nyitva az ERD-t.

valójában minden olyan grafikus eszköz, amely segít gyorsan megemészteni az információkat, és tízezer lábnyi képet nyújt a projektről, értékes lesz. További példák az eszközök, amelyek segítségével vannak függőségi grafikonok, naplók, és egy térképet a projekt technológiai verem.

a fejlesztés egyik legnagyobb időfogyasztója a rendszerek közötti integrációs pont. A projekt tájképének globális áttekintése segít azonosítani, hogy mely integrációs pontokat érdemes megvizsgálni. Ezek azok a helyek, ahol a legtöbb munka van, és a legtöbb hiba.

másrészt a technológia gyorsan fejlődik, és lehetőség nyílik arra, hogy a kódbázis nagy részét modernebb és megfelelően integrált megoldásokkal helyettesítsék. Egy régi keretrendszer kifejleszthetett volna egy új és hivatalos módszert a probléma megoldására, vagy egy teljesen új könyvtárat is kidolgozhattak volna a jobb kompatibilitást szem előtt tartva.

használja a vizualizációs és modellezési eszközöket a nagy kép megtekintéséhez.

felkészülés az automatikus tesztelésre

Mielőtt elkezdené a dolgok feltörését, mindig körültekintő a releváns egységtesztek hozzáadása. A tesztelés és a rossz kód problémája az, hogy a rossz kód általában szorosan kapcsolódik és nehéz (ha nem lehetetlen) tesztelni. Nem lehet elkülöníteni azokat az összetevőket, amelyek összefonódnak és oszthatatlanok.

ezekben az esetekben tegyen egy lépést hátra, és teszteljen messzebb. Ez általában integrációs tesztelést jelent, amelyhez sok eszköz áll rendelkezésre. A webalkalmazások tesztelhetők a HTTP kérésekkel szemben, így legalább ellenőrizhető, hogy a rendszer ugyanúgy reagál-e ugyanazokra a bemenetekre.

az integrációs tesztelés sokkal rosszabb teljesítményt nyújt, mint az egységtesztek. Amikor csak lehet, hajtson végre egységteszteket, így gyorsabb visszajelzést kaphat a kódváltozásokról. Ha ez nem lehetséges, akkor válassza a funkcionális vagy akár integrációs tesztelést.

ez a lépés rávilágít a kód azon részeire, amelyek munkát igényelnek. Ha nagy mennyiségű szorosan összekapcsolt kód van, ez jó célpont a refaktoráláshoz az integrációs tesztek elvégzése után, majd később az egység teszteléséhez.

azonosítsa a szokatlan vagy nem megfelelő kódolási stratégiákat

itt az ideje elkezdeni a refaktorálást,de hol kezded?

általában a legjobb hely, ahol a dolgok furcsának tűnnek, vagy ahol a fejlesztési legjobb gyakorlatokat nem követték. A webfejlesztéshez ez azt jelentheti, hogy a fat vezérlők szorosan összekapcsolt modellkóddal rendelkeznek.

ne feledje, hogy ugyanazokat a stratégiákat máshol is lehet használni. Tehát, ha például megállapítja, hogy fat vezérlők vannak jelen, akkor valószínű, hogy a korábbi fejlesztők nem próbálták meg vékony vezérlőket használni. Ugyanez a probléma várható más vezérlőkben is, mivel ez tükrözte a fejlesztési folyamat korábbi stílusát vagy hiányosságait.

először egy kis feladaton dolgozni

egy kis hiba kijavítása egy fogalmilag egyszerű funkcióra nagyon tanulságos lesz, és segít a kezdetektől fogva produktívnak érezni magát.

ez egy hasonló ötlet, amit Andy Hunt és Dave Thomas “tracer bullets” a pragmatikus programozó. A mögöttes logika ugyanaz: dolgozzon valami végponttól végpontig, hogy bebizonyítsa magának, hogy lehetséges, majd fokozatosan javítsa ezt a kezdeti munkát.

a “tracer bullet” megközelítés. Hitel: a pragmatikus programozó

jó példa arra, hogy milyen egyszerű fejlesztéseket végezhet, ha egyszerű kóddal kis refaktorálási lépéseket tesz. Határozza meg a nem követett közös programozási gyakorlatot, és alkalmazza azt.

az egyik kedvencem ehhez az un-fészkelő feltételes blokkok. Tehát ahelyett, hogy több if-if blokk lenne, az egyik a másikban, tagadja meg az elsőt, és térjen vissza, és tegye ugyanezt az összes érvényesítési típusú ellenőrzésnél. Ez olyan egyszerű lehet, mint egy “ha” ellenőrzés megfordítása és néhány kód mozgatása, így a kockázat szinte nem létezik, és a lapos kód könnyebben olvasható lesz.

győződjön meg róla, hogy először a könnyen tesztelhető refaktorálási funkciókon dolgozik, mert annak ellenére, hogy a változások alacsony kockázatúak, mindig jó ötlet, hogy ellenőrizze a kódot, mielőtt elküldené a gyártásba.

ismerkedjen meg a kritikus kóddal

először mindig ismerje meg a projekt felállítását, és csak ezután merüljön el az építészeti oldalon. Az üzleti és integrációs kód legkritikusabb részeit a legnehezebb megérteni és módosítani. Kerülje el, hogy korán bajba kerüljön.

általános szabályként kerülje az olyan üzleti problémákat, amelyek megkövetelnék, hogy többet tudjon meg a projektről vagy az üzleti oldalról, mint jelenleg. Ez általában azt jelenti, hogy távol kell maradni a tranzakciós, fizetési vagy matematikai nehéz kódtól, amíg meg nem kezd ismerőssé válni.

ha már produktív vagy, jól érzed magad a projekt kódolási stílusával, és nem okoz gondot az egyszerű problémák megoldása, ideje dolgozni a nehezebb dolgokon—de nem korábban.

még akkor is, ha sürgős a fizetési problémák megoldása, például, ez a fajta feladat hihetetlenül kockázatos lehet. Egy hiba nagyon sokba kerülhet a projektnek, és ez a te hibád is lesz. Teljesen megtagadja a magas kockázatú feladatok elvégzését korán, ha egyáltalán lehetséges.

hogyan kell kezelni egy ismeretlen tech stack

az utolsó pont, egy gyakori probléma, amit befut az, hogy minden új projekt általában tartalmaz néhány technológia, hogy nem vagyok tisztában.

amikor ez megtörténik, van néhány stratégiám, amelyek segítenek gyorsan felgyorsulni. A tanulás nyilvánvaló útja a dokumentáció olvasása és az új technológia megismerése. De bár sokat fog tanulni a struktúráról, ez az út nem segít megtanulni a sarok eseteket, amelyek általában tapasztalattal járnak. (A “sarok eset” egy mérnöki kifejezés, amely olyan helyzetre utal, amely a normál működési paramétereken kívül fordul elő.)

a tapasztalatszerzés folyamatának felgyorsításának egyik módja az, hogy kérdésalapú erőforrásokat, például a Stack Overflow-t és a Quorát olvassuk át, mint egy könyvet. Keresse meg a legnépszerűbb kérdéseket a tanult könyvtárral kapcsolatban, és nézze meg, hogy mások milyen problémákkal szembesülnek. Nem fogsz feltétlenül összefutni velük magad, de csak tudni, hogy mi lehetséges, olyan, mintha ragyogó fényt ragyogna az új ötletek elmetérképére.

tőkeáttétel Stack túlcsordulás kérdések tapasztalatszerzés gyors. Hitel: Stack Overflow

a célzottabb megközelítéshez keressen információkat az új projektben használt könyvtárfunkciókról. Nézzetek azokra, akik újak számotokra, és tanuljátok meg őket idő előtt, mielőtt egyáltalán hozzá kellene nyúlnotok ehhez a kódhoz.

ossza meg ötleteit