Un programmatore che parla di codice
Tom qui iscritto, sviluppatore appassionato per tutto ciò che riguarda il web e il nativo. Molte lune sono passate da quando ho iniziato a scrivere alcune righe di codice. Un glorioso momento di "Hello World" è stato, e da allora ho scritto molte più righe di molto più codice, che vanno da sistemi di allarme in tempo reale, applicazioni mediche che supportano i medici nelle loro attività quotidiane fino a riunioni multi-piattaforma. software di pianificazione-gestione. Ho anche imparato alcune cose lungo la strada e oggi voglio condividere un aspetto della codifica che potrebbe non sempre ottenere così tanta attenzione, specialmente durante i periodi pesanti di metà progetto. Parliamo della responsabilità di un programmatore, o, per essere precisi, dell'eredità del codice di un programmatore.
Le piramidi di Javascript
Il compito di un architetto non è solo definire la disposizione fondamentale di un nuovo edificio, le forme di muri, finestre e porte o l'allineamento della casa proporzionale al sole di mezzogiorno. Tra tutte queste cose, l'architetto sa che l'edificio deve resistere negli anni a venire, che deve resistere a una natura brutale di forti venti, forti piogge, inverni gelidi ed estati calde. L'obiettivo finale del lavoro dell'architetto è assicurarsi che le persone che vivono nell'edificio abbiano una casa sicura. Riguarda la longevità del suo lavoro. Riguarda la sua eredità.
Nello sviluppo del software, le cose tendono a muoversi a un ritmo molto veloce, soprattutto quando si lavora alle startup. È importante fornire rapidamente nuove funzionalità, ottenere trazione sul mercato e mantenere gli utenti coinvolti. L'attenzione durante lo sviluppo tende ad essere limitata allo sprint corrente o all'implementazione di quella caratteristica ad alta priorità il prima possibile.
Tuttavia, quando sto programmando, non dovrebbe essere limitato ai test per illuminare tutto in verde o solo alla scadenza da raggiungere. Una volta in libertà, le applicazioni vengono utilizzate dagli esseri umani che possono fare affidamento su di esse per la loro routine lavorativa quotidiana. Il programma che sto costruendo oggi è l'eredità che lascerò domani.
Prendiamo il web come esempio: non è mai stato così facile trovare componenti che forniscono la funzionalità che sto cercando in questo momento tramite NPM. Vengono rapidamente installati e collegati al resto del codebase. Ma quando si tratta della longevità della mia applicazione, le dipendenze di terze parti possono interrompere l'intero processo di aggiornamento, b/c l'aggiornamento di una dipendenza impedisce a un'altra di funzionare. È un atto di bilanciamento decidere tra cosa implementare da solo, fork o installare direttamente da un gestore di pacchetti.
Tuttavia, il codice di fornitori di terze parti può andare bene. È importante verificare alcuni fattori prima di utilizzare la libreria o il framework: quanto era buona la manutenzione in passato, quanti contributi attivi ci sono ora, è disponibile una tabella di marcia che delinea cambiamenti o miglioramenti futuri, il pacchetto è completamente gestito dalla comunità o supportato da sponsor per aiutarlo nel suo sviluppo?
Passando dal codice esterno alla mia base di codice, una cosa che devo costantemente ricordare a me stesso è di non tagliare scorciatoie durante lo sviluppo per raggiungere un obiettivo più velocemente. Per quanto allettante possa essere a breve termine, il codice mal pianificato si vendicherà e morderà. Pensare al codice più che scriverlo aiuta a mitigare molti problemi. Un fattore chiave sicuramente qui è l'esperienza, ma anche gli sviluppatori junior dovrebbero comprendere l'importanza del codice manutenibile fin dall'inizio. Ciò che ora porta ai bug potrebbe non essere mai risolto a causa delle tempistiche del progetto e potrebbe essere risolto solo attraverso soluzioni alternative, portando a codice disordinato, cattiva esperienza utente o entrambi.
Mentalità del macchinista
Un altro aspetto della codifica ponderata di cui voglio scrivere è il pubblico di destinazione di un'applicazione, l'utente. Dato che sono seduto dalle 9 alle 17 davanti allo schermo del mio righello calcolatore elettrico, solcando righe di codice e concentrandomi sul problema a cui sono assegnato, è sicuramente difficile tenere a mente che tutto il mio lavoro, alla fine, ha per essere utilizzato da chi lo utilizza parzialmente o completamente durante il lavoro quotidiano. E non importa se sto creando un'app per persone non tecniche o API per altri sviluppatori: le cose che creo devono essere ergonomiche nel loro utilizzo.
So per esperienza diretta che gli utenti potrebbero interagire con la tua app in modi strani e per lo più inspiegabili. Io come creatore tendo a rifiutare il comportamento "non intenzionale" del mio servizio, ancora di più se ho già investito molto tempo ed energie in esso. Tuttavia, mantenere una mente calma quando si riceve un feedback e, se necessario, costringermi ad ascoltarlo, svolge un ruolo chiave nella comprensione del comportamento di utilizzo effettivo e reale del pubblico.
Noi sviluppatori viviamo in un mondo di ordine e uniformità durante la programmazione, in cui si applicano un tipo speciale di fisica e gravitazione e dove conosciamo tutte le regole. È un mondo da abbracciare e immergersi completamente in esso, poiché siamo i suoi creatori e abitanti. Ma affrontare il feedback, ad esempio le critiche da fuori questo mondo, di solito porta al suo rifiuto da parte degli sviluppatori. La gestione dei report e delle opzioni degli utenti deve essere appresa e valutata come input rilevante per lo sviluppo. È una lezione che ho imparato e aiuta enormemente in ogni fase del progetto essere aperti a cambiamenti e feedback.
process.exit();
Per riassumere, pensa non solo al codice che stai scrivendo oggi, ma a quello che le persone useranno negli anni a venire. Prendi decisioni ponderate in merito all'utilizzo di pacchetti di codici esterni, nonché alla struttura e alle implementazioni del progetto, in modo tale che il prodotto finale possa essere utilizzato in modo ergonomico ed efficiente, riflettendo l'effettiva domanda del pubblico di destinazione. Comprendere il feedback è fondamentale e aiuta notevolmente a fornire un prodotto di qualità di cui essere orgogliosi.
- Tom
