Ogni programmatore sa quali sono le proprie abilità in cui è un mago e quelle in cui necessita di qualche ripasso, ma ci sono abilità che contano di più rispetto ad altre.
Abilità che possono fare la differenza nel proprio lavoro, indipendentemente che tu sia dipende o libero professionista.
Tra tutte queste abilità che n’è una che ti garantisce una certa serenità e benefici sul lungo periodo.
Quest’abilità è composta dall’unione della lettera N insieme alla tredicesima lettera dell’alfabeto italiano, la O.
Unirla e pronunciare la parola che compone .. esatto la parola è no!
Aspetta …
L’abilità è saper dire no … NO !!
Tutto chiaro, no?
Un grande – semplice – NO.
Per un programmatore ingegnarsi, per trovare una soluzione e scriverla attraverso un linguaggio di programmazione, è la parte più importante quanto gradevole del lavoro.
Come programmatore, so benissimo, che ogni specifica ti mette davanti a decisione continue. Alcune più difficili di altre.
Niente di sbagliato in questo, anzi, non fai altro che migliorare le tue competenze sulla propria valutazione di rischio e di fattibilità.
Anche perché questo è ciò che tutti si aspettano da te, come programmatore.
Ma ecco che arriviamo alla fatidica domanda: dovresti scrivere tutto il codice che viene richiesto ?
Prima di dare una risposta ..
Ci tengo a ricordarti che programmare è un’arte. Perché si tratta di mettere in comunicazione tanti piccoli elementi nel migliore dei modi possibile, per ottenere un risultato che soddisfi le specifiche volute.
Ma perché è così importante?
Cosa c’entra con il sapere dire di NO?
Saprai benissimo che dato un problema, ci sono virtualmente infinite soluzioni in grado di risolverlo. Questo ci porta a comprendere che prima di scrivere un programma occorre comprenderlo in maniera approfondita e determinare precisamente un algoritmo che possa portare ad una soluzione efficiente.
Dove per efficienza intendiamo un algoritmo che consumi poche risorse e la cui codifica e mantenimento rispettino i buoni principi di programmazione.
Programmare o non programmare questo è il problema
La precisazione fatta, ci porta a parlare di quella che considero l’abilità più importante che un programmatore può imparare.
Sapere riconoscere quando non programmare.
Si hai capito bene, riconoscere quando non programmare è forse l’abilità più importante che un programmatore possa apprendere.
Io la chiamo, l’arte del codice leggibile.
Non trovi quest’affermazione irrazionale?
Lascia che ti spieghi il mio pensiero.
La programmazione è l’arte di risolvere un problema.
Quindi, naturalmente, i programmatori sono risolutori di problemi.
Come tali, quando abbiamo davanti a noi un problema o per qualsiasi altro motivo che richieda scrivere righe di codice, siamo entusiasti.
E va bene perché siamo programmatori.
Adoriamo scrivere codice.
Tuttavia, l’essere troppo entusiasti nel dover scrivere codice può renderci ciechi.
Perché ci porta ad ignorare alcuni fatti importanti che possono causare problemi più grandi. Quei stessi problemi che dovremo poi affrontare in un ipotetico prossimo futuro.
Quindi, quali sono quei fatti importanti che tendiamo a ignorare?
Ogni riga di codice che scrivi è:
- Codice che deve essere letto e compreso da altri programmatori.
- Codice che deve essere testato ed eseguito il debug.
- Codice che aumenterà i difetti del software.
- Codice che probabilmente introdurrà nuovi bug in futuro.
Questo rende il codice il nostro peggior nemico.
Il codice è cattivo. Marcisce. Richiede una manutenzione periodica. Ha dei bug che devono essere trovati. Per ogni funzionalità che viene introdotta, viene richiesto un adattamento del vecchio codice.
Vogliamo parlare poi del processo di refactoring (rifattorizzare) ??
Inoltre, più codice spesso significa meno flessibilità e funzionalità.
I programmatori che ti ispirano per la loro produttività e mentalità di programmazione sono quelli che sanno quando dire di no.
Il loro software, così facile da mantenere che continua ad aiutare i loro utenti, è proprio quello che non contiene righe di codice non necessarie.
Quindi.
Il miglior codice che possiamo produrre è un il codice che non produciamo.
Il programmatore più efficace è colui che sa quando è meglio non scrivere codice.
Come puoi sapere quando non programmare?
È naturale eccitarsi quando si lavora su un progetto e pensare a tutte le fantastiche funzionalità che ti piacerebbe implementare, non è vero?
Ma si tende a sopravvalutare il numero di funzioni realmente necessarie al proprio progetto e molte funzionalità rimangono incompiute o inutilizzate rischiando di rendere l’applicazione troppo complicata per l’utente finale.
Dovresti sapere cosa è essenziale per evitare di commettere questo errore.
Comprendere lo scopo del software è il primo passo per sapere quando non programmare.
Lasciate che vi faccia un esempio ..
Supponiamo che tu debba sviluppare un software che abbia un solo ed unico scopo: gestire le email. A tale scopo, l’invio e la ricezione di e-mail sono due caratteristiche essenziali per il tuo progetto.
Giusto? Non puoi aspettarti che anche quel software gestisca la tua lista degli appuntamenti in agenda, vero?
E’ per questo che dovresti dire NO a tutte le possibili richieste di funzionalità che sono irrilevanti per lo scopo dichiarato.
Questo è il momento in cui puoi essere esattamente sicuro di sapere quando non scrivere il codice.
Non espandere mai lo scopo del software.
Se non c’è un reale motivo/esigenza/domanda per farlo.
Una volta che saprai cosa è essenziale per il tuo progetto sarai anche più consapevole quando dovrai valutare possibili richieste delle varie implementazioni sul tuo software.
Conoscerai esattamente i requisiti necessari per scrivere il codice e saprai riconoscere quale caratteristica debba essere implementata e/o quale codice vale la pena scrivere.
Metterai in discussione tutto, perché saprai esattamente che il codice non necessario può uccidere il tuo progetto.
Sapere quando non programmare mantiene piccola la tua base di codice.
Bastano pochi secondi per compilare ed eseguire il codice.
Sai dove trovare esattamente quello che stai cercando.
Sembra tutto così semplice, non trovi?
Se non sei mai stato all’inferno, continua a leggere …
Ora supponiamo che mano a mano che il progetto cresce, sempre più file riempiono la directory del tuo progetto.
Questo vuol dire che ogni file contiene centinaia di righe di codice e per organizzarli tutti, presto avrai bisogno di più directory.
Questo vuol dire che devi ricordare quali funzioni chiamano altre funzioni e sarà più difficile e tenere traccia dei bug, perché richiederà un po’ più di lavoro.
Ora gestire il tuo progetto diventa difficile e hai bisogno di più programmatori per aiutarti. Le spese generali per la comunicazione aumentano all’aumentare del numero di programmatori.
Il flusso di lavoro diventa sempre più lento.
Alla fine, il progetto diventa enorme.
L’aggiunta di nuove funzionalità è dolorosa.
Apportare piccole modifiche richiede ore.
La correzione dei bug presenti introduce sempre nuovi bug.
Inizi a non rispettare le scadenze.
Ora, sei in lotta con il codice.
Perché?
Perché non sapevi quando non scrivere il codice.
Hai detto SÌ ad ogni possibile richiesta di funzionalità.
Eri cieco.
L’entusiasmo di sviluppare qualcosa di nuovo ti ha fatto ignorare lo scopo principale del tuo software.
Se non è l’inferno questo, cosa lo è?
Questo è ciò che accadrà se continui a dire SÌ a tutto.
Sapere esattamente quando non programmare è una delle abilità più importanti che puoi apprendere.
Elimina ogni codice non necessario dal tuo progetto.
Ciò renderà la tua vita più semplice e prolungherà la durata del tuo software.
Uno dei miei giorni più produttivi è stato gettare via 1000 righe di codice. – Ken Thompson
Posso assicurarti che riconoscere quando non scrivere del codice è stata una sfida anche per me. Come lo è stata anche per programmatori più senior di me e di te.
Ma quello che voglio dire è che ..
Un programmatore non deve perdere mai l’eccitazione e l’entusiasmo di creare qualcosa di nuovo, di scoprire e trovare nuove soluzioni ai problemi.
Si continueranno a compiere errori, questo è certo.
L’importante è imparare dai nostri errori.
Ma ti invito a sapere dire di NO, qualche volta 😉
uoi scrivere del codice
