E perché la qualità è così importante. E perché non sarai mai abbastanza grato per le cose che esistono di alta qualità. Purtroppo la qualità non è un regalo per nessuno. Richiede impegno e lavoro. Parte 4 del nostro manifesto ingegneristico: apprezza la qualità!
Pianifica il tempo per i test di unità, integrazione e interfaccia utente
Pianifica risorse sufficienti per le CAT
E infine: sii sempre motivato a fornire la migliore qualità possibile
Come puoi vedere, diventerai automaticamente uno sviluppatore di software migliore se rimarrai motivato e metterai sempre l'accento sulla qualità. Ma ora voglio sbarazzarmi di un'altra citazione:
Programma sempre come se il tizio che deve mantenere il codice fosse uno psicopatico violento che sa dove vivi.
Il nostro manifesto
Il nostro manifesto ti convince
Oppure non ti convince, ma vuoi comunque sviluppare con noi? Abbiamo le seguenti offerte di lavoro nel settore dello sviluppo software:
Anche se tutti i post precedenti iniziavano con una citazione o una breve storia, non ho intenzione di continuare così ;) Solo perché qualcosa è sempre stato così, non significa che debba rimanere così. È esattamente la stessa cosa nello sviluppo del software. Ad esempio, un uomo saggio ha capito che avremmo potuto migliorare la comprensibilità e la leggibilità del nostro codice rinominando la funzione "FillAuto" in "BindModel". Il nome originale della funzione non diceva nulla di ciò che accadeva nel codice. Con il tempo tutti lo sapevano, ma i nuovi dipendenti erano regolarmente confusi. L'uomo saggio ha osato mettere in discussione una tradizione del nostro codice e apportare un cambiamento positivo.
Questo è esattamente l'argomento di questo blog post. Scriviamo codice, il codice cambia, la nostra conoscenza cresce. Purtroppo il codice ha una caratteristica negativa: se non lo si affronta in modo consapevole, diventa più complesso a ogni modifica. L'entropia aumenta. A un certo punto, arriva un punto in cui il codice esistente non soddisfa più i requisiti di una nuova storia. Che sia perché il codice originale era stato pensato solo come prototipo, perché le prestazioni non sono più sufficienti o perché nel frattempo sono stati introdotti nuovi modelli: al più tardi a questo punto, dovresti intervenire e chiedere ciò che ti spetta: il tempo di un refactoring. Ma non sono solo i refactoring a contribuire alla qualità. Anche le prove automatizzate, i criteri di accettazione ben definiti, le revisioni del codice condotte in modo corretto e, naturalmente, la mentalità hanno un'influenza importante.
Potrebbe essere necessario un po' di tempo per scrivere le prove, ma in cambio otterrai una sorta di garanzia che il tuo codice funziona come previsto. Le prove aiutano anche gli altri sviluppatori a comprendere il tuo codice e a riconoscere tempestivamente eventuali bug. Inoltre, impari come disaccoppiare le classi e mantenere il codice testabile. Scrivere prove ti rende uno sviluppatore migliore! Se vuoi saperne di più sui test, ti consiglio questo articolo.
CAT = C revisione del codice, A verifica dei criteri di accettazione & T casi di test. Tieni presente che una CAT è più di una semplice revisione del codice. Il codice può essere ben strutturato e comprensibile. Se i criteri di accettazione non sono soddisfatti, la storia non è completa. Non vedere le CAT come una tortura, ma come una sfida. Come revisore, imparerai a conoscere meglio le altre storie e potrai integrare le tue conoscenze. Come destinatario della revisione, verrai a conoscenza di problemi e opportunità di miglioramento che ti renderanno uno sviluppatore migliore!
Raccogli il feedback degli altri sviluppatori nelle prime fasi della storia e documenta la tua realizzazione e le tue scoperte in modo che gli altri possano beneficiare delle tue conoscenze. Questo vi renderà tutti sviluppatori migliori! (e per favore, compilate il vostro codice in locale prima di inviarlo al repository. Questo vi renderà sviluppatori più popolari ;))
