Kodilo parolanta pri kodo
Tom ĉi tie verkas, pasia programisto pri ĉiuj aferoj retejaj kaj denaskaj. Multaj lunoj pasis de kiam mi unue skribis kelkajn liniojn de kodo. Glora momento de "Saluton Mondo" estis, kaj de tiam mi skribis multajn pli da linioj de multe pli da kodo, de realtempaj alarmaj sistemoj, medicinaj aplikoj subtenantaj kuracistojn en iliaj ĉiutagaj taskoj ĝis plurplatforma kunveno - & - programado-mastrumado de programoj. Ankaŭ mi lernis iujn aferojn laŭ la vojo, kaj hodiaŭ mi volas dividi unu aspekton de kodado, kiu eble ne ĉiam gajnas tiom multe da fokuso, precipe dum mez-projektaj pezaj tempoj. Ni parolu pri respondeco de kodilo, aŭ, pli precize, koda heredaĵo de kodilo.
La Piramidoj de Ĝavaskripto
La tasko de arkitekto estas ne nur difini la fundamentan aranĝon de nova konstruaĵo, la formojn de muroj, fenestroj kaj pordoj aŭ la vicigo de la domo proporcia al la suno tagmeze. Inter ĉiuj tiuj aferoj, la arkitekto scias, ke la konstruaĵo devas elteni dum la venontaj jaroj, ke ĝi devas elteni brutalan naturon de fortaj ventoj, pluvegoj, malvarmaj vintroj kaj varmaj someroj. La fina celo de la laboro de la arkitekto estas certigi, ke la homoj loĝantaj en la konstruaĵo havu sekuran hejmon. Ĉio temas pri la longviveco de lia aŭ ŝia laboro. Ĉio temas pri ĝia heredaĵo.
En programevoluo, aferoj emas tre rapide, precipe kiam oni laboras ĉe noventreprenoj. Gravas rapide sendi novajn funkciojn, akiri tiradon en la merkato kaj teni la uzantojn allogaj. La fokuso dum disvolviĝo tendencas esti limigita al la nuna spurto aŭ efektivigado de tiu unu-prioritata trajto kiel eble plej baldaŭ.
Tamen kiam mi kodas, ĝi ne devas esti limigita al la testoj por lumigi tute verdan aŭ nur la limtempon atingotan. Post kiam ili sovaĝe aperas, homoj uzas homojn, kiuj eble dependas de ili por sia ĉiutaga labora rutino. La programo, kiun mi konstruas hodiaŭ, estas la heredaĵo, kiun mi postlasos morgaŭ.
Ni prenu la retejon kiel ekzemplon: neniam estis pli facile trovi erojn, kiuj provizas la funkciojn, kiujn mi serĉas nun per NPM. Ili estas rapide instalitaj kaj konektitaj al la resto de la kodbazo. Sed se temas pri la longdaŭro de mia aplikaĵo, triaj dependecoj eble haltigos la tutan ĝisdatigan procezon, b / c ĝisdatigante, ke unu dependeco haltigas alian funkcii. Ĝi estas ekvilibra ago decidi inter kion efektivigi per mia propra, forko aŭ instalo rekte de paka administrilo.
Tamen kodo de triaj provizantoj simple povas esti bona. Gravas kontroli iujn faktorojn antaŭ uzi la bibliotekon aŭ kadron: kiel bona estis prizorgado en la pasinteco, kiom da aktivaj kontribuoj estas nun, ĉu disponeblas vojmapo, kiu priskribas estontajn ŝanĝojn aŭ plibonigojn, ĉu la pako estas tute administrata de la komunumo aŭ subtenata de sponsoroj por helpi kun ĝia disvolviĝo?
Antaŭenirante de ekstera kodo al mia propra kodbazo, unu aferon, kiun mi konstante devas memori al mi, estas ne tranĉi angulojn dum disvolviĝo por atingi celon pli rapide. Kiel ajn tenta ĝi estas baldaŭ, malbone planita kodo venĝos kaj mordos reen. Pensi pri kodo pli ol skribi helpas mildigi multajn problemojn. Kerna faktoro certe ĉi tie estas sperto, tamen ankaŭ junaj programistoj devas kompreni la gravecon de konservebla kodo dekomence. Kio kondukas al cimoj nun eble neniam estos riparita pro projektaj templinioj kaj nur solviĝos per solvoj, kondukante aŭ al fuŝa kodo, malbona uzanto-sperto aŭ ambaŭ.
Mentaleco de la maŝinisto
Unu alia aspekto de pripensema kodado pri kiu mi volas verki estas la celgrupo de aplikaĵo, la uzanto. Ĉar mi sidas 9 ĝis 5 antaŭ la ekrano de miaj elektraj glitaj regiloj, esplorante liniojn de kodo kaj fokusante la aferon, al kiu mi estas asignita, certe estas malfacile memori, ke mia tuta laboro eventuale havas uzenda de iu, kiu uzas ĝin parte aŭ tute dum la ĉiutaga laboro. Kaj ne gravas, ĉu mi konstruas programon por ne-teknikaj homoj aŭ API por aliaj programistoj - la aferoj, kiujn mi konstruas, devas esti ergonomiaj laŭ ĝia uzado.
Mi scias per propra sperto, ke uzantoj povus interagi kun via programo per strangaj kaj plejparte neklarigeblaj manieroj. Mi kiel kreinto emas malakcepti "neintencitan" konduton de mia servo, des pli se mi jam investis multan tempon kaj energion en ĝi. Tamen konservi trankvilan menson ricevante reagojn kaj, se necese, devigi min aŭskulti ĝin, ludas ŝlosilan rolon por kompreni la realan, realan uzokutimon de la spektantaro.
Ni kiel programistoj vivas en mondo de ordo kaj unuformeco dum kodado, kie speciala fiziko kaj gravito validas kaj kie ni konas ĉiujn regulojn. Ĝi estas mondo por ampleksi kaj plene mergi nin en ĝin, ĉar ni estas ĝiaj kreintoj kaj loĝantoj. Sed alfronti reagojn t.e. kritikoj de ekster ĉi tiu mondo kutime kaŭzas ĝian malakcepton de programistoj. Traktado de uzaj raportoj kaj ebloj devas esti lernita kaj taksata kiel grava enigo por la disvolviĝo. Ĝi estas leciono, kiun mi lernis, kaj ĝi ege helpas en ĉiu stadio de la projekto esti malfermita por ŝanĝoj kaj reagoj.
process.exit ();
Resume, pensu ne nur pri la kodo, kiun vi skribas hodiaŭ, sed tiu, kiun homoj uzos en la venontaj jaroj. Faru pripensajn decidojn pri la uzado de eksteraj kodaj pakaĵoj same kiel la strukturo kaj efektivigoj de la projekto, tiel ke la fina produkto povas esti uzata ergonomie kaj efike, reflektante la efektivan postulon de la celgrupo. Kompreni reagojn estas ŝlosilo kaj multe helpas liveri kvalitan produkton, pri kiu oni povas fieri.
- Tom
