'N Kodeerder wat oor kode praat
Tom skryf hier, passievol ontwikkelaar vir alle web en inheems. Baie mane het verbygegaan sedert ek die eerste keer 'n paar reëls kode begin skryf het. 'N Glorieryke' Hello World'-oomblik is, en sedertdien het ek nog baie meer reëls geskryf met veel meer kode, wat strek van intydse alarmstelsels, mediese toepassings wat dokters ondersteun in hul alledaagse take tot multi-platform vergadering - & - sagteware vir skeduleringsbestuur. Ek het ook 'n paar dinge langs die pad geleer en vandag wil ek een aspek van kodering deel wat nie altyd soveel fokus kan kry nie, veral nie tydens swaar tye in die middel van die projek nie. Kom ons praat oor die verantwoordelikheid van 'n kodeerder, of, om presies te wees, die nalatenskap van 'n kodeerder.
Die piramides van Javascript
Die taak van 'n argitek is nie net om die fundamentele uitleg van 'n nuwe gebou, die vorms van mure, vensters en deure of die huis se belyning eweredig aan die son, te definieer nie. Onder al hierdie dinge weet die argitek dat die gebou nog jare moet verduur, dat dit 'n wrede aard van sterk wind, swaar reën, koue winters en warm somers moet weerstaan. Die uiteindelike doel van die argitek se werk is om seker te maak dat die mense wat in die gebou woon 'n veilige huis het. Dit gaan alles oor die lang lewe van sy of haar werk. Dit gaan alles oor die nalatenskap daarvan.
In sagteware-ontwikkeling beweeg dinge baie vinnig, veral as u by opstart werk. Dit is belangrik om vinnig nuwe funksies uit te stuur, in die mark vas te trek en die gebruikers besig te hou. Die fokus tydens ontwikkeling is meestal beperk tot die huidige sprint of die implementering van een funksie met 'n hoë prioriteit.
Maar as ek kodeer, moet dit nie net tot die toetse beperk word om alle groen of net die sperdatum te bereik nie. Sodra u in die natuur is, word toepassings gebruik deur mense wat hul daaglikse werksroetine daarop kan vertrou. Die program wat ek vandag bou, is die nalatenskap wat ek more agterlaat.
Kom ons neem die web as voorbeeld: dit was nog nooit so maklik om deur NPM komponente te vind wat die funksies bied wat ek tans soek nie. Hulle word vinnig geïnstalleer en aan die res van die kodebasis gekoppel. Maar as dit gaan oor die langdurige gebruik van my aansoek, kan afhanklikhede van derdepartye die hele opdateringsproses staak, b / c bywerk dat een afhanklikheid keer dat 'n ander werk. Dit is 'n balans daad wat besluit tussen my eie, vurk of direk vanaf 'n pakketbestuurder installeer.
Die kode van verskaffers van derdepartye kan egter net goed wees. Dit is belangrik om na enkele faktore te kyk voordat u die biblioteek of raamwerk gebruik: hoe goed onderhoud in die verlede was, hoeveel aktiewe bydraes daar nou is, is 'n padkaart beskikbaar wat toekomstige veranderings of verbeterings uiteensit, is die pakket volledig gemeenskapsbestuur of gerugsteun deur borge om te help met die ontwikkeling daarvan?
Om van eksterne kode na my eie kodebasis te beweeg, is een ding wat ek myself voortdurend moet herinner, is om nie tydens ontwikkeling 'n hoek te sny om vinniger 'n doel te bereik nie. So aanloklik soos dit op kort termyn kan wees, sal sleg beplande kode wraak neem en terugbyt. As u meer oor kode dink as om dit te skryf, kan dit baie probleme verlig. 'N Belangrike faktor hier is beslis ervaring, maar tog moet junior ontwikkelaars van meet af aan die belangrikheid van instandhoudende kode verstaan. Wat nou tot foute lei, kan moontlik weens die tydlyne van die projek nooit reggestel word nie en slegs deur middel van oplossings opgelos word, wat lei tot slordige kode, slegte gebruikerservaring of albei.
Geestelikheid van die masjinis
Een ander aspek van deurdagte kodering waaroor ek wil skryf, is die teikengehoor van 'n toepassing, die gebruiker. Terwyl ek 9 tot 5 voor my elektriese skuifliniaal se skerm sit en deur die kode ry en fokus op die probleem waaraan ek toegewys is, is dit moeilik om in gedagte te hou dat al my werk uiteindelik om gebruik te word deur iemand wat dit gedeeltelik of volledig tydens die daaglikse werk gebruik. En dit maak nie regtig saak of ek 'n app vir nie-tegniese mense of API's vir ander ontwikkelaars bou nie - die goed wat ek bou, moet ergonomies wees in die gebruik daarvan.
Ek weet uit die eerste hand dat gebruikers op vreemde en meestal onverklaarbare maniere met u app kan kommunikeer. Ek as skepper is geneig om 'onbedoelde' gedrag van my diens te verwerp, nog meer as ek al baie tyd en energie daarin belê het. Maar om 'n kalm gemoed te hou wanneer ek terugvoering ontvang en, indien nodig, myself dwing om daarna te luister, speel 'n sleutelrol in die begrip van die werklike, werklike gebruiksgedrag van die gehoor.
Ons as ontwikkelaars leef in 'n wêreld van orde en eenvormigheid tydens kodering, waar 'n spesiale soort fisika en gravitasie geld en waar ons al die reëls ken. Dit is 'n wêreld om ons daarin te omhels en ten volle te verdiep, aangesien ons die skeppers en inwoners daarvan is. Maar om terugvoer te kry, dws kritiek van buite hierdie wêreld, lei gewoonlik tot die verwerping daarvan deur ontwikkelaars. Die hantering van gebruikersverslae en -opsies moet geleer en waardeer word as relevante insette vir die ontwikkeling. Dit is 'n les wat ek geleer het, en dit help baie in elke stadium van die projek om oop te wees vir veranderinge en terugvoer.
proses.exit ();
Om saam te vat, dink nie net aan die kode wat u vandag skryf nie, maar ook aan die kode wat mense in die komende jare sal gebruik. Neem deurdagte besluite rakende die gebruik van eksterne kodepakkette sowel as die projek se struktuur en implementerings, sodat die finale produk ergonomies en doeltreffend gebruik kan word, wat die werklike vraag van die teikengehoor weerspieël. Dit is belangrik om terugvoer te verstaan en dit help baie om 'n kwaliteit produk te lewer waarop jy trots kan wees.
- Tom
