Egy kódoló, aki kódról beszél
Tom itt ír, szenvedélyes fejlesztő minden internetes és natív témában. Sok hold telt el mióta elkezdtem írni néhány sor kódot. Dicsőséges „Hello World” pillanat volt, és azóta sokkal több sort írtam sokkal több kóddal, a valós idejű riasztórendszerektől, az orvosok mindennapi feladataikat támogató orvosi alkalmazásoktól a több platformos találkozókig - & - ütemezés-kezelő szoftver. Megtanultam néhány dolgot is útközben, és ma szeretném megosztani a kódolás egyik aspektusát, amely nem mindig kaphat ekkora hangsúlyt, különösen a projekt közepén nehéz időkben. Beszéljünk egy kódoló felelősségéről, vagy, pontosabban, a kódoló kód örökségéről.
A Javascript piramisai
Az építész feladata nemcsak meghatározni egy új épület alapvető elrendezését, a falak, ablakok és ajtók formáját, vagy a ház déli naparányos beállítását. Mindezek mellett az építész tudja, hogy az épületnek még évekig ki kell állnia, hogy ellenálljon az erős szél, heves esőzések, hűvös tél és forró nyár brutális természetének. Az építész munkájának végső célja annak biztosítása, hogy az épületben élők biztonságos otthonnal rendelkezzenek. Minden a munkája hosszú élettartamáról szól. Minden a hagyatékáról szól.
A szoftverfejlesztésben a dolgok általában nagyon gyors ütemben mozognak, különösen akkor, ha startupoknál dolgoznak. Fontos az új funkciók gyors kiszállítása, a vonzóerő megszerzése a piacon és a felhasználók elkötelezettsége. A fejlesztés során a hangsúly általában a jelenlegi sprintre vagy az egyik kiemelt funkció megvalósítására korlátozódik.
Mégis, amikor kódolok, nem szabad csak a tesztekre korlátozódni, hogy zölden világítsanak, vagy csak az elérendő határidőre. A vadonba kerülve az emberek olyan alkalmazásokat használnak fel, amelyek támaszkodhatnak rájuk a napi munkában. A ma építtetett program az örökség, amelyet holnap elhagyok.
Vegyük példának a webet: az NPM-en keresztül még soha nem volt könnyebb olyan alkatrészeket találni, amelyek biztosítják a most keresett funkciókat. Gyorsan telepítik őket és összekapcsolják a kódbázis többi részével. De amikor az alkalmazásom hosszú élettartamáról van szó, a harmadik féltől származó függőségek leállíthatják az egész frissítési folyamatot, a b / c frissítheti, hogy az egyik függőség leállítja a másik működését. Ez egy kiegyensúlyozó intézkedés, amely eldönti, hogy mit kell megvalósítanom a saját kezemben, elágazok vagy telepítek közvetlenül a csomagkezelőtől.
A harmadik fél szolgáltatóinak kódja azonban rendben lehet. Fontos, hogy a könyvtár vagy a keretrendszer használata előtt ellenőrizni kell néhány tényezőt: mennyire volt jó a karbantartás a múltban, hány aktív hozzájárulás van most, rendelkezésre áll-e egy ütemterv, amely felvázolja a jövőbeni változásokat vagy fejlesztéseket, a csomagot teljesen közösségi kezeli vagy támogatja-e szponzorok segítenek a fejlődésében?
A külső kódtól a saját kódbázisom felé haladva egy dolgot állandóan emlékeztetnem kell magamra, hogy a fejlesztés során ne vágjak sarkot a cél gyorsabb eléréséhez. Bármennyire is csábító rövid távon, a rosszul megtervezett kód bosszút áll és visszaharap. Ha többet gondol a kódra, mint arra, hogy megírja, az segít számos problémát enyhíteni. A biztos tényező kulcsfontosságú tényezője a tapasztalat, mégis a junior fejlesztőknek is meg kell érteniük a karbantartható kód fontosságát a kezdetektől fogva. Ami most hibákat eredményez, a projekt időrendje miatt soha nem javítható, és csak megoldásokkal oldható meg, ami rendetlen kódhoz, rossz felhasználói élményhez vagy mindkettőhöz vezet.
A gépész mentalitása
Az átgondolt kódolás egy másik aspektusa, amelyről írni akarok, egy alkalmazás célközönsége, a felhasználó. Amikor 9-től 5-ig ülök az elektromos csúszkás vonalzók képernyője előtt, szántom a kódsorokat, és a rám rendelt kérdésre összpontosítok, biztosan nehéz szem előtt tartani, hogy minden munkám végül is hogy valaki használja, aki részben vagy egészben használja a napi munka során. És teljesen mindegy, hogy nem technikai emberek számára készítek-e alkalmazást, vagy más fejlesztőknek szánt API-kat - az általam készített dolgoknak ergonómikusnak kell lenniük a használatukban.
Első kézből tudom, hogy a felhasználók furcsa és többnyire megmagyarázhatatlan módon léphetnek kapcsolatba az alkalmazásoddal. Alkotóként hajlamos vagyok elutasítani a szolgálatom „nem szándékos” viselkedését, még inkább, ha már rengeteg időt és energiát fektettem bele. Mégis a nyugodt elme megőrzése a visszajelzések fogadásakor, és ha szükséges, arra kényszerítem magam, hogy meghallgassam őket, kulcsfontosságú szerepet játszik a közönség tényleges, valós használati viselkedésének megértésében.
Fejlesztőként a kódolás rendjének és egységességének világában élünk, ahol egy speciális fizikai és gravitációs fajta érvényes, és ahol ismerjük az összes szabályt. Olyan világ, amely magáévá teszi és teljes mértékben belemerül, hiszen mi vagyunk az alkotói és a lakói. De a visszacsatolással, azaz a világon kívüli kritikával való szembenézés általában a fejlesztők elutasításához vezet. A felhasználói jelentések és opciók kezelését meg kell tanulni és értékelni kell a fejlesztés szempontjából releváns inputként. Ez egy lecke, amelyet megtanultam, és a projekt minden szakaszában nagyban segít abban, hogy nyitott vagyok a változásokra és a visszajelzésekre.
process.exit ();
Összefoglalva, gondoljon nemcsak arra a kódra, amelyet ma ír, hanem arra is, amelyet az emberek a következő években használni fognak. Átgondolt döntéseket hozhat a külső kódcsomagok használatával, valamint a projekt felépítésével és megvalósításával kapcsolatban, hogy a végső terméket ergonómikusan és hatékonyan lehessen használni, tükrözve a célközönség tényleges igényét. A visszajelzések megértése kulcsfontosságú, és nagyban hozzájárul egy olyan minőségi termék eljuttatásához, amelyre büszke lehet.
- Tom
