Arriva una richiesta, un nuovo lavoro da affrontare, spesso c’è un prodotto di partenza da modificare, a volte il prodotto è vecchio, a volte inizi qualcosa di nuovo ed hai tutto il massimo delle libertà.
Per chi sono questi consigli
Ti trovi spesso nella situazione di dover mettere mano su codice altrui, o stai iniziando un nuovo progetto con le idee un po’ sparpagliate diciamo, cioè senza un piano esattamente coeso ed ordinato. Capita sicuramente di non avere le idee chiare se si va a modificare un codice altrui, spesso si deve agire senza aver colto a pieno la filosofia che sta dietro il codice che si va a modificare, il codice è figlio del tempo e delle mode che sono in voga in quel periodo quindi alcuni costrutti sembrano bizzarri perché, ad esempio, si ha il vizio di usare template definiti tramite variabili quando è di moda farlo, alla stessa maniera di come in cucina si tende mettere lo zenzero dappertutto quando lo zenzero è di moda, oppure il peperoncino nel gelato. Se scrivi (e leggi) codice da un po’ di tempo riuscirai sicuramente a riconoscere la moda e capire più o meno quando è stato scritto il codice, e finirai col pensare a quanto eri stupido a forzare così le scelte, lo siamo tutti, non importa.
Ecco, sicuramente non posso rendere il mondo del software scritto in passato migliore, neanche ordinare le idee confuse che sicuramente avrai all’inizio. Piuttosto traggo ispirazione dal Gioco MU di Douglas Hofstadter, per provare ad uscire dal sistema e guardare me stesso nel fare i soliti errori che fanno perdere tempo.
Ho ottenuto questi 10 consigli utili per un programmatore php/mysql, ma nella modalità e nello spirito probabilmente si applicano anche ad altri framework/toolchain.
1. Fai (e rifai) la lista della spesa
La chiamo così questa pratica che ultimamente mi salva da alcuni imprevisti. Devi determinare gli strumenti di cui hai bisogno e le azioni, il codice, i task che dovrai portare a termine. Fa la lista di questo, e aggiornala man mano che se ne presenta la necessità. Ogni volta che fai un ragionamento scrivilo. Non si ragiona con la testa tra le nuvole, si ragiona con le dita sulla tastiera (o se vuoi, con la penna sul foglio, o il pennarello sulla lavagna). Va divisa per passi sequenziali, come nella programmazione imperativa, poi sull’ordine si può soprassedere, senza stare a formalizzare ogni volta, bisogna essere snelli, basta un appunto veloce. Se ci sono cicli la cosa potrebbe essere preoccupante, a differenza della programmazione imperativa qui si sta facendo una lista di passi, girare attorno non è un buon segno, ma potrebbe essere sensato a volte. Fare comunque attenzione ai cicli.
Forse riconosci kanban (http://kanbanblog.com/explained/), infondo è quello, diciamo che io mi trovo meglio con un file di testo e appiccicare per l’ufficio tutti quei post-it mi rende la vita incasinata, poi magari porto avanti diversi progetti, bisognerebbe fare una stanza per ogni progetto da riempire con i relativi post-it. A volte mi capita di usare una lavagna per disegnare ad esempio. Siccome ho bisogno di disegnare altro faccio una foto alla lavagna, applico un filtro edge e uso l’immagine come parte del blueprint del progetto. Questo mi permette di:
- avere un ufficio ordinato
- i progetti catalogati in cartelle
- seguire più progetti
- lavorare a distanza condividendo blueprint e schizzi
L’eventuale svantaggio è il non avere tutto davanti agli occhi. Riguardo a questo per ora uso 2 monitor ed è abbastanza per sviluppare software, eventualmente ne andrebbe aggiunto un terzo per avere la lista sotto gli occhi. Con i tool giusti si riesce ad ottenere lo stesso risultato dello spostamento dei post-it, ma credo sia più importante seguire la metodologia riguardo a PENDING-DOING-DONE, piuttosto che la sua forma implementata in post-it.
2. Hai bisogno di Git
Ok, forse preferisci, mercurial? bitkeeper? bazaar? subversion? ci siamo capiti un Source Control Version, non importa se pensi che la cosa duri poco, è un piccolo task, e quindi non farai errori … ma dai.
Seriamente usa git anche se devi scrivere dei documenti, usa git anche per la lista della spesa, usa git per qualsiasi cosa, fai commit ad ogni modifica funzionante, o anche più, anche per file di testo e commenti come la lista della spesa.
3. Affronta le paure non aggirarle
Di cosa parlo? Paure durante la programmazione? Diciamo di tutti quei lavori che stufano e che pesano e si rimandano e non si vogliono fare. La paura è quella di superare il limite, per me è quello dell’avere a che fare con la definizione di un db e un dbms, anzi più dbms da tenere allineati tra la macchina di test e la macchina produttiva. Fa la lista della spesa, i passi da compiere e falli, senza paura.
Altre paure sono ad esempio quella di toccare il codice, magari del codice altrui che sai che funziona. http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx qui se ne parla e si parla anche della paura di perdere il lavoro, per questa bisogna chiarire i problemi ed affrontarli sempre apertamente col commitente o capo che sia, non importa perdere un lavoro che sottintende uno stress continuo per qualcosa di non chiarito, durante il lavoro si avrà la pressione continua che abbasserà la produttività e finisce che quel lavoro costerà a te più di qualsiasi valutazione pessimistica tu abbia fatto. Il lavoro deve essere guidato dalla passione, non dalla paura: cambia committente.
4. Concediti l’ignoranza. Ragiona temporalmente
Stai facendo la lista della spesa, hai considerato che dovrai affrontare alcune cose odiose, ma ancora non sai tutto. Non puoi saperlo in anticipo, lascia un’area di ignoranza, riconoscila e non cercare di avere una definizione definitiva dall’inizio.
L’esempio tipico è quello della definizione della struttura della base di dati, a meno che non utilizzi mongodb (e potrebbe anche essere un path per lo sviluppo per poi passare ad un relazionale …). La struttura dei dati di solito non è determinata dall’inizio, perché si comincia col definire una serie di test da soddisfare, le classi e così via. Io di solito parto da problemi concettuali cardinali attorno ai quali ho concepito la soluzione, ma dei quali non sono certo riguardo la facilità di implementazione, scrivo appunto la classe, il test relativo e risolvo man mano i problemi funzionali, quindi non la definizione della struttura dei dati. Per me il db schema cambia, allora scelgo strumenti che rendono il cambiamento semplice e veloce. Considero mysql:
- mysql-workbench: permette di creare tabelle ed estrarre la definizione in modo semplice, molto meglio di phpmyadmin perché usabile via tastiera, il cambiamento di una struttura può essere eseguito o simulato cioè generando solo l’alter da una versione alla successiva (Database -> Compare Schemas…). Basta salvare l’sql degli alter e può essere usato per avanzare la versione dello schema in un sito di test o anche in produzione ogni volta che si effettua il deploy
- http://www.adminer.org/ sembra avere abbastanza feature, non so andrebbe provato
- https://github.com/victorstanciu/dbv non è esattamente qualcosa di leggero, usarlo potrebbe voler dire rivedere tutta l’organizzazione del codice e c’è poco di programmabile, sembra
- https://github.com/doctrine/dbal Doctrine Abstraction Layer, perché doctrine2 lo utilizza per gestire i db e fa già qualcosa di molto simile a mysql-workbench riguardo a compare schema, ma c’è bisogno di un minimo di lavoro iniziale, diciamo cominciando con la documentazione, http://doctrine-dbal.readthedocs.org/en/latest/reference/schema-representation.html, ma una volta fatto questo lavoro si può avere in mano uno strumento piuttosto versatile nel ciclo: devel, test, deploy QA, test, deploy Production, quando ci si inseriscono upgrade del db poterle automatizzare e gestire semplicemente da file .yml è un vantaggio temporale spesso importante.
- Take it easy: mysqldump. Sicuramente un tool da linea di comando è quello che un programmatore preferisce, lo puoi mettere dappertutto, anche nello script di deploy, esempio:
mysqldump -udbuser -pdbpass -d test `cat data/tablelist.txt` > data/dbdef.sql
esporta la struttura delle tabelle elencate in data/tablelist.txt (una per riga) contenute nel database `test` accedendovi tramite utente ‘dbuser’ identificato con ‘dbpass’, la definizione (-d vuol dire solo struttura) viene messa in dbdef.sql. Questo è qualcosa di versatile da poter mettere all’interno di uno script da eseguirsi al momento del commit, o prima, comunque meno macchinoso di dover eseguire l’operazione tramite workbench, o peggio phpmyadmin, e comunque versatile abbastanza da poter scegliere le sole tabelle interessate.
Tutte queste considerazioni sugli strumenti vanno anche in un’altra dimensione, cioè come si può andare verso la complessità e completezza di un tool, o verso la semplicità e versatilità, di quanto questo possa significare più tempo iniziale di setup e meno durante l’utilizzo. Sostanzialmente va valutato cosa è più soggetto al cambiamento, e per questo può essere speso più tempo per l’ottimizzazione: definire la struttura del db è un ciclo, non lo metterei neanche nella lista della spesa.
5. Give it 5 minutes
(Jason Fried’s post) Capire le soluzioni degli altri, cercare di carpirne le motivazioni che hanno portato a quelle soluzioni. Spesso gli strumenti disponibili abbracciano e risolvono tutta la problematica affrontandola da un punto di vista più inclusivo. Mentre l’esigenza specifica che si ha non ha bisogno di tenere conto di tutti gli aspetti della problematica, è naturale che ci si scocci a dover leggere tutta la documentazione per qualcosa di cui non si ha bisogno. Durante lo sviluppo del progetto se ne avrà bisogno. Dagli quei 5 minuti, dagli ragione a chi ha ideato lo strumento e capisci la problematica in toto. A tutto c’è un limite, ovviamente, ma avere una visione ampia dei vari aspetti del deploy & delivering tornerà utile se si hanno altre esigenze nel progetto che si sta affrontando, ed anche nei progetti futuri.
6. Le costanti non hanno senso
Hai presente quella pratica di definire delle costanti all’inizio del codice. È un idiozia.
Non puoi mischiare codice e costanti quando le costanti dipendono dalla configurazione, e la configurazione dipende dalla macchina, ed esiste anche il concetto di deploy, cioè ci sono 2 macchine differenti. Se le costanti sono mescolate al codice dovrai complicare il deploy facendo script da eseguirsi sulla macchina target per modificare quelle costanti.
D’altra parte potresti usare un file separato, ma sempre nel linguaggio utilizzato, cioè usare le define.
Vediamo come organizzaresti il codice (caso php):
- configurazione db (file .ini)
- file .php con define’s
- file .php con codice
E così il deploy:
- impacchetta il codice .php, ma escludendo i .php contenenti define’s
- impacchetta i .php dei define’s e i file .ini
- così hai 2 file da deployare e spacchettare a piacimento (supponendo la stessa base dir, hai lo stesso target di directories).
Pro e contro dei file con define:
- devi usare require, require causa un fatal error ed è visibile se l’output a video è attivato nella macchina target (non lo è se la macchina è in produzione)
- è .php, puoi avere la voglia di ficcarci dentro del codice, puoi farlo, questa è una boiata se ci pensi (ci pensi?)
- è .php quindi è caricato dall’interprete php scritto in C, al posto della funzione parse_ini, che certamente è scritta anch’essa in C, però nella tua testa esplicita i concetti di caricamento e parsing. (Ehi! sono le stesse operazioni!)
Di queste quali sono i pro??
No amico, le costanti non hanno senso. Usa file di configurazione, che siano ini, yaml, json, etc. basta che non ti venga voglia di mischiarci codice.
7. Usa l’ultima tecnologia
Se sulla macchina target c’è PHP 5.3, allora puoi usare il namespace, se c’è il 5.4 allora puoi usare this nelle closure, e via dicendo. Non c’è motivo di privarsi di funzionalità pensando ad un backport, non succede che si torni indietro, casomai si va avanti. Stai aggiornato sempre all’ultima tecnologia utilizzabile, all’ultima best practice, all’ultima metodologia. Non importa, puoi sempre usare roba vecchia perché non la dimenticherai così facilmente.
Usa PHPUnit per i test e composer per prendere pezzi già pronti, per questi tool infondo non importa che non siano nel server, e non c’è motivo di rinunciarci.
8. Test, test, test
Lo traduco: provare, provare, provare, e poi provare, provare, provare … Ricordi sicuramente Amanda Sandrelli in Non ci resta che piangere, quello è il TDD anticipiato nel 1984 da Troisi e Benigni, ma sono stati compresi solo molto più tardi. Test vuol dire scrivere, scrivere codice, scrivere casi studio. Testing vuol dire creare uno script di prova per verificare che l’allocazione di una sprintf sia corretta, anche per controllare il dubbio più banale è meglio scrivere codice e vedere se funziona come ci si aspetta, piuttosto che leggersi documentazione sparpagliata tra sito istituzionale, commenti e blogosphere. Test vuol dire reingegnerizzare, rivedere l’organizzazione del codice, rivedere il progetto, rivedere lo schema del db. Tutta la discussione del dotarsi di strumenti adatti al cambiamento è nell’ottica del poter provare, provare, provare. E poi provare, provare, provare, provare, provare.. e poi ci si riesce bene anche 2, 3 volte, tanto per concludere la citazione.
9. Esci dal sistema, e osservati
Guarda quello che stai facendo, dove stai perdendo tempo. Non dare per scontato che ci voglia necessariamente tutto quel tempo, prova a pensare alla strada più breve. Ho letto pochi giorni fa un articolo interessantissimo, https://medium.com/@lauraklein/your-job-is-not-to-write-code-d002609b117a, your job is not writing code, il tuo lavoro non è scrivere codice, ma soddisfare i bisogni dell’utente, anche se in pratica per farlo devi scrivere codice, ma quello non è il tuo lavoro, è il modo col quale raggiungi lo scopo. Quindi scrivi meno codice e soddisfa meglio gli utilizzatori. Non inseguire sofismi, ortodossie architetturali, o anche metodologiche, non essere così pedante riguardo al TDD, BDD e via dicendo. In generale se qualcosa ti fa perdere molto tempo forse lo stai facendo nel modo sbagliato. Esci dal sistema, guardati individua le regole che stai seguendo e se ti fanno perdere tempo, se necessario cambiale.
(immagine proveniente da http://www.zz7.it/esperienze-extracorporee-la-donna-che-usci-dal-suo-corpo-7336/ )
10. Non aspettarti che tutto fili come dovrebbe
Ad esempio io non ho un decimo consiglio da mettere, però ho letto che fare liste è qualcosa che fa salire nei risultati delle ricerche, e ho letto inoltre che 10 è il numero magico che ha migliori performance. Quindi se non trovi questo consiglio utile è normale. Non tutti i consigli sono utili nella tua situazione, e non lo sono certamente per tutte le situazioni, io ho cercato di raccogliere quelli che a grandi linee sono considerazioni che valgono per me.
E comunque sia qualcosa andrà male, o meglio andrà come non ti aspetti. Non puoi evitare di aspettarti qualcosa, né pretendere che le cose vadano secondo le previsioni. È un po’ più complesso del gioco MU.
Conclusioni
Programmare è un gioco bellissimo quando hai 13 anni. Quello che ti affascina è far funzionare delle cose, automatizzarle, in breve fare la magia. La magia, come quella del pacman che risponde ai comandi del joystick, ma ha una logica, anche il fantasmini che si muovono cercando di mangiarti, hanno una logica. È affascinante come la logica può mangiare un pupazzetto. La logica prestabilita può portare a risultati inattesi, persino inattesi dallo stesso programmatore. Avere in mano uno strumento così potente è fantastico. A volte le cose non vanno bene, o non sono andate bene, e potresti pensare che tutto è noioso e inaccettabile. Non perdere l’entusiasmo. Trova il modo di tornare ad avere quel potere, non accettare compiti ripetitivi, non l’hai mai cercato e ora non l’accettare. E crea la magia per gli utenti, e ricorda, nella magia vera il trucco non si vede!
Ho il sospetto che l’entuasiasmo si perda dietro al voler dimostrare di essere bravi, che purtroppo si scontra col programmare proprio perché è un’attività che ti mette continuamente di fronte alle tue mancanze, ai tuoi difetti, permettendoti di migliorare. L’elemento sempre presente durante la programmazione è la propria ignoranza e incapacità, ma questo non lo puoi certo scrivere nel curriculum, bisogna dividere i 2 aspetti: l’attività quotidiana e l’autopromozione. È accettabile essere crittico riguardo la propria attività se sei un programmatore. Devi farti pagare. Parla piuttosto dei risultati prodotti, non di metodologie. Le metodologie sono l’ultima cosa di cui parlare per l’autopromozione. Ma sono piuttosto importanti se vuoi arrivare ad un prodotto, ad un risultato.
E tu …
Se vuoi puoi condividere questo articolo. Forse troverai questi consigli banali, superficiali e poco formalizzati, forse ce ne sono altri da aggiungere. Non so