Capitolo 9 — Pacchetti, dipendenze, terze parti

Questo è il capitolo 9 sull'Arte della Codificazione, formattato vagamente come nell'antico libro Art of War e parte di una serie di articoli che catturano buone intenzioni e opinioni su come scrivere codice software.

Nello sviluppo di software ci sono alcune aree da evitare o da cui prestare attenzione, tuttavia, poiché ciò che offrono sono elementi necessari con cui occuparsi, soprattutto se si considerano gli ambienti e il terreno.

Presta attenzione a quali librerie esterne utilizzi.

• Controllare e rivedere eventuali licenze
• Assicurati che siano relativamente stabili e che il loro tasso di cambiamento non sia troppo alto
• Verificare che siano aggiornati e ancora utilizzati e mantenuti attivamente
• Controlla come e quando vengono aggiornati
• Gestisci le versioni utilizzate nelle tue build
• Controlla frequentemente se la libreria che usi è aggiornata
• Preparati a impegnarti per tenerti aggiornato
• Non sottovalutare l'impatto di un rapido aggiornamento della libreria

• Prevedi che il servizio sia temporaneamente inattivo o non disponibile e gestiscilo con garbo.
• Consenti il ​​rilevamento automatico e regolare dell'indisponibilità del servizio anche se non viene utilizzato in quel momento.
• Determina come i dati possono essere separati e archiviati per vari usi di tali servizi come ambienti e dati di sviluppo, test e produzione.
• Impedire l'accesso ai servizi utilizzati dai sistemi di produzione tramite l'utilizzo di credenziali memorizzate separatamente dal codice e conosciute solo dalle persone rilevanti (cioè se non hai la password per vivere i servizi non puoi danneggiarla quindi sei al sicuro).
• Stabilire come monitorare l'utilizzo di quel servizio.
• Pianifica la registrazione e la traccia da un sistema all'altro con un modo per correlare tra loro (a parte i timestamp).
• Assicurati che tutti i sistemi si riferiscano all'unico imperatore del tempo che sarà chiamato UTC
• Proteggiti ricevendo un avviso se l'utilizzo e quindi la spesa dovessero diventare balistici a causa di un banale errore di codifica nel tuo codice.
• Nascondi tutti i fornitori tramite una facciata per quel servizio per semplificare il cambio fornitore.

• Sii meticoloso nel registrare dettagli, ipotesi e ipotesi nel ticket di emissione.
• Non saltare a conclusioni infondate.
• Replica accuratamente gli ambienti e i dati in cui si è verificato il problema.
• Sii aperto a un problema veritiero segnalato con fatti mancanti.
• Consentire la possibilità di un vero problema segnalato da una vista contestuale alternativa con una prospettiva diversa. "La bellezza è negli occhi di chi guarda".
• Accetta che il cliente potrebbe non avere il tempo o la capacità di ripetere o approfondire per te.
• Un saggio sviluppatore cervelli prende d'assalto tutte le possibilità quando nessuna è disponibile.
• L'assenza di vedere un problema non significa che non ci sia alcun problema.
• Uno sviluppatore intelligente cerca l'illuminazione sotto forma di una causa principale e non si limita a mascherare i sintomi.
• Un problema molto raro ma problematico dovrebbe essere visto come una sfida, non come un fastidio.
• Se puoi esagerare le condizioni per rendere il problema frequente e ripetibile, allora capisci veramente l'origine del problema.

• Il debug è la rimozione di bug indesiderati (non sono un bug ricercato)
• Un bug è un errore di codifica nell'implementazione di una funzione
• Un difetto è un errore o un'omissione con un requisito per una caratteristica.
• Esegui il debug del tuo codice per assicurarti che venga eseguito correttamente.
• Eseguire il debug del codice in condizioni difficili ed estreme (più dell'ambiente di produzione).
• Conserva e gestisci tutti i vettori di test al sicuro in modo che possano essere riutilizzati.
• Trasmetti qualsiasi vettore di test ai tester (come gesto amichevole).
• Assicurare ai tester di aver testato il codice prima che venga passato a loro per prove e test formali e rigorosi. Fallo in un modo che spieghi l'ampiezza e la profondità del tuo lavoro, nel codice, nei commenti o in un ticket come preferisci.
• Il test unitario è una vera virtù e il marchio di un buon sviluppatore.

Applica questi e altri standard come una squadra che ritieni adatta. Tutti scrivono ed eseguono il debug del codice secondo loro e dichiarano se qualcuno non soddisfa il marchio, non per sminuirlo ma tutelare la santità del software. Quindi soddisferà la legge morale del software funzionante.

Ulteriori letture

Maggiori informazioni sull'autore

Greg è un professionista del software esperto e CTO di outsource.dev , dopo aver lavorato in diverse aziende, ora è appassionato di aiutare gli altri ad avere successo nello sviluppo, nella gestione e nell'outsourcing del software.

Se questo articolo ti è piaciuto, batti le mani e seguimi .