7 pratiche di codifica chiave per sviluppatori agili

Lo sviluppo di software agile non riguarda solo principi e pratiche agili. Per riuscire a rilasciare software che abbia un impatto positivo sugli utenti finali, affronti il ​​debito tecnico e venga distribuito in modo affidabile, il team di sviluppo deve anche considerare le pratiche di codifica e gli standard di architettura che guidano l'agilità.

Una considerazione ancora più importante è in gioco per le organizzazioni tecnologiche. Per quanto sia difficile sviluppare software, è ancora più difficile distribuire miglioramenti e aggiornamenti regolarmente per un periodo prolungato. Le pratiche Devops CI / CD e IAC (infrastruttura come codice) risolvono parzialmente un fattore critico poiché l'automazione consente modi affidabili e ripetibili per distribuire le applicazioni. Aggiungi test continui e i team di sviluppo possono verificare che le modifiche al codice non influiscano sulle funzionalità esistenti.

Tuttavia, con l'invecchiamento delle applicazioni, gli sviluppatori originali passano ad altri progetti e talvolta ad altre società. Quando nuovi sviluppatori si uniscono al team, devono apprendere l'architettura del software e comprendere il codice prima di poterlo modificare in modo affidabile ed efficiente.

Inoltre, gli sviluppatori che creano applicazioni spesso vogliono svilupparne di nuove. Potresti sentirti a tuo agio e sicuro rimanere attaccato alle applicazioni che sviluppi, ma essere legato al tuo codice non è salutare per la tua carriera o per l'organizzazione.

Il modo migliore per passare a nuove ed entusiasmanti iniziative di sviluppo software è rendere la tua architettura, applicazione e codice facilmente supportabili da altri sviluppatori. I team e gli sviluppatori Agile devono stabilire e applicare pratiche di codifica che sostengano lo sviluppo software in corso.

1. Non reinventare la ruota

La prima regola di codifica: non codificare qualcosa che non ha bisogno di essere codificato! Come?

  • Considera l'idea di porre domande sui requisiti. Perché una caratteristica è importante? A chi giova? Più specificamente, esplora le opzioni non di codifica per risolvere il problema. A volte la soluzione migliore non è affatto una soluzione.
  • Qualcuno nella tua organizzazione ha già codificato una soluzione simile? Forse esiste un microservizio che necessita solo di un miglioramento o una libreria software che necessita di un aggiornamento minore? Assicurati di esaminare la base di codice della tua organizzazione prima di scrivere qualcosa di nuovo.
  • Esistono soluzioni di terze parti, inclusi strumenti SaaS convenienti o opzioni open source, che soddisfano i requisiti minimi?
  • Hai esaminato i repository di codifica aperti come GitHub per esempi di codice e snippet che soddisfano i requisiti di conformità della tua organizzazione?

2. Considerare le opzioni di sviluppo a basso codice

Se è necessario codificare una soluzione, forse piattaforme alternative a basso codice possono consentire lo sviluppo delle funzionalità in modo più efficiente rispetto alla codifica in linguaggi di sviluppo come Java, .Net, PHP e JavaScript.

Piattaforme low-code come Caspio, Quick Base, Appian, OutSystems e Vantiq forniscono tutti strumenti per sviluppare applicazioni con poco codice e talvolta anche senza codice. Ogni piattaforma è specializzata in capacità diverse ed è quindi adatta per una specifica classe di applicazioni. Caspio, ad esempio, semplifica l'incorporamento di moduli e flussi di lavoro nei siti Web. Quick Base ha un flusso di lavoro robusto e funzionalità di automazione e l'architettura basata sugli eventi di Vantiq è adatta per IoT e altre applicazioni di dati in tempo reale.

A volte è necessaria la codifica, ma gli sviluppatori dovrebbero anche essere esperti in una o più opzioni di sviluppo a basso codice e considerarle per i casi d'uso appropriati.  

3. Automatizzare i test

Oltre a scrivere codice che soddisfi i requisiti, una delle cose più importanti che gli sviluppatori devono fare è testarlo. Le pratiche di sviluppo basate sui test e gli strumenti di test automatizzati sono maturati ei team di sviluppo dovrebbero includere test di unità, regressione, prestazioni e sicurezza come parte delle loro stime agili.

Oltre ad avere test per convalidare build e release, questi test aiutano anche a rendere il codice più sopportabile. I test sono documentazione e stabiliscono un contratto su come dovrebbe comportarsi il codice. Quando i nuovi sviluppatori si uniscono ai team e implementano inavvertitamente una brutta modifica, il test continuo interrompe la creazione e fornisce un feedback significativo allo sviluppatore al fine di risolvere rapidamente il problema.

4. Esternalizzare tutti i parametri di configurazione

Non ci dovrebbero essere scuse per gli sviluppatori per inserire nel codice impostazioni a livello di sistema, nomi utente e password o altre informazioni di configurazione. Ho visto sviluppatori prendere scorciatoie durante lo sviluppo di prototipi che trovano la loro strada negli ambienti di produzione. Nelle architetture odierne questo non dovrebbe mai essere fatto. L'hard coding non è un debito tecnico ma una pratica di codifica pigra e irresponsabile che può avere conseguenze significative. Se il codice diventa accidentalmente accessibile, crea una vulnerabilità di sicurezza se vengono esposti endpoint o credenziali di accesso.

Fare un ulteriore passo avanti, quando si lavora sul codice legacy, affrontare eventuali configurazioni e parametri hard-coded dovrebbe essere una priorità del debito tecnico non negoziabile.

5. Seguire le convenzioni di denominazione e includere commenti per rendere il codice leggibile

Una volta ho lavorato con uno sviluppatore di incredibile talento che non conosceva bene l'inglese e non era il miglior dattilografo. Avrebbe istanziare oggetti con nomi come un , b, e c e quindi creare le variabili locali di nome zz , aa , xx . Si sarebbe impegnato a ripulirlo prima del rilascio, ma raramente lo ha seguito.

Non dovrebbe essere necessario istituire una programmazione di coppia o mob per riconoscere che questa è una pratica terribile.

I team dovrebbero adottare convenzioni di denominazione come JavaScript Style Guide e Java Style Guide di Google e impegnarsi a commentare il codice almeno a livello modulare e idealmente a livello di classe. Inoltre, le organizzazioni dovrebbero considerare l'utilizzo di strumenti di analisi del codice statico che forniscono feedback agli sviluppatori quando il codice necessita di refactoring per fattori di struttura e leggibilità.

6. Controllare frequentemente il codice nel controllo della versione

Se non controlli il codice nel controllo della versione su base giornaliera o più frequente, può creare conflitti e altri blocchi che influiscono sul team. Un piccolo errore può far sì che i team agili non rispettino gli impegni di sprint o creino lavoro aggiuntivo per risolvere le dipendenze.

I team devono concordare le convenzioni per l'archiviazione del codice non pronto per la produzione. Gli approcci convenzionali includono flag di funzionalità e branching Git.

7. Evita di codificare eroiche e complessità

La maggior parte degli sviluppatori che conosco sono diventati ingegneri software professionisti perché amano risolvere le sfide di codifica. La programmazione è un'arte, una scienza e un mestiere e gli sviluppatori migliori cercano incarichi di programmazione stimolanti e implementazioni eleganti.

Tranne che c'è una linea grigia tra la risoluzione di compiti aziendali e tecnici impegnativi e l'eroicità della programmazione che lascia ai prossimi sviluppatori un codice difficile da capire e complicato da mantenere.

Per quelli di noi che hanno programmato da tempo, ricordiamo la convenienza dei one-liner Perl o l'utilizzo di modelli annidati in C ++. A volte ci sono buone ragioni per usare questi approcci, ma se un nuovo gruppo di sviluppatori non comprende queste tecniche è più difficile cambiare il codice. A volte le pratiche di codifica semplici ma meno eleganti sono migliori.

Promuovere l'agilità nello sviluppo di software agile

I rituali incorporati in Scrum e nello sviluppo agile, inclusi impegni, stand-up, sprint review e retrospettive sono ora pratiche collaudate per consentire la collaborazione del team e guidare un'implementazione di successo. Ma per dimostrare l'agilità a lungo termine, gli sviluppatori devono assumersi responsabilità e pratiche di codifica che consentano il supporto e l'estendibilità a lungo termine del codice che sviluppano.

I team di sviluppo devono avere una visione critica delle loro pratiche di codifica. Non è solo abbastanza buono per demo e rilasciare oggi; è anche fondamentale consentire ad altri di mantenere facilmente l'applicazione e il codice.