Prendendo spunto da questo interessante articolo volevo condividere commenti ed impressioni riguardo i 10 suggerimenti per il programmatore. Date un occhiata anche ai 17 errori più comuni dei programmatori e l'errore più comune degli sviluppatori Android.01 - Parlare
Proprio come quando si è in cura da uno strizzacervelli è utile parlare con qualcuno dei propri problemi. Vi è mai capitato di parlare con qualcuno di un problema riguardante la stesura di un codice e magicamente trovare la soluzione nel bel mezzo del discorso? Parlare con qualcuno può essere utile a rimettere in ordine i pezzi del puzle in un ordine diverso da come lo siamo abituati a vedere, cambiando la prospettiva di un problema si giunge spesso alla soluzione. Se non hai qualcuno con cui parlare puoi sempre parlare da solo (non davanti ad uno specchio altrimenti rischiate di venire rinchiusi in un manicomio!).
02 - Test Nucleari
La parola può spaventare, ma intendo l'effettuare test di piccole porzioni di codice invece di grandi masse funzionali (nuclei). Effettuare dei test in maniera "nucleare" significa avere la possibilità di testare PRIMA il codice dunque di risolvere per tempo problemi invece di trovarsi immersi fino al collo di errori ed eccezioni non gestite. Un consiglio: durante lo sviluppo in team potrebbe essere interessante far testare una funzione al collega vicino di scrivania, un occhio diverso dal nostro potrebbe incappare in un errore non previsto.
03 - La Punta dell'Iceberg
Su questo punto ho i miei dubbi sinceramente rispetto all'articolo originale da cui ho preso spunto. Tuttavia io la vedo in un altro modo: L'esperienza utente scrive parte del codice. Pensare prima a come visualizzare i dati su una maschera oppure a quali operazioni possono essere effettuate su un sistema sono fattori che aiutano alla stesura di un codice "pronto" ad effettuare il proprio compito. Proprio come abbiamo visto insieme durante la progettazione di SqlDocGen, prima di scrivere il codice sono state definite le interfacce.
04 - Have a break!
Come per il punto 01, anche fare una breve pausa può aiutare a distrarre la mente e a risolvere un problema. Ho avuto colleghi che non facevano la pausa-caffè perchè non avevano sete/fame, tuttavia ho sempre cercato di fargli capire che le pause sono importanti e fondamentali tanto quanto stare a scrivere del codice. Avere una distrazione dal lavoro può essere utile ma non si deve esagerare!
05 - Automazione di Progetto
Automatizzare fasi semplici e ripetitive dello sviluppo di un progetto permette di ridurre tempi ed errori aumentato il tempo per dedicarsi allo sviluppo vero e proprio. Quando ho iniziato il progetto SqlDocGen avevo proprio questo in mente, dato che la stesura della documentazione di specifica di un database è una cosa che porta via molto tempo mi poteva essere utile avere un software che fa il lavoro al posto mio. Questo è applicabile anche al riutilizzo di funzioni già scritte utili ad altri scopi, ma attenzione a non lasciare del "codice morto" che può causare problemi prestazionali.
06 - Prima la Sostanza, poi la Forma
Prima di dedicarsi alla creazione di funzioni ricorsive modulari a parametri variabili, è sufficiente scrivere una funzione semplice che risponde alle nostre esigenze di progetto. Anche se male indentato, mal commentato e non performante è necessario prima di tutto scrivere del codice funzionante per dedicarsi successivamente al perfezionamento e ai commenti. Un consiglio: non posticipare troppo a lungo il perfezionamento o i commenti di un codice può produrre applicazioni di bassa qualità ed efficienza (ci vuole un po' di buon senso).
07 - Mantenersi in moto
Proprio come il punto 04, è utile fare pause e distrarsi dal lavoro; ancora meglio se si utilizza il tempo libero per fare del movimento (vi ricordo che la gara di resistenza seduti su una scrivania a programmare non sarà mai uno sport olimpico). Mi ricordo ancora l'articolo di Greg Baugues riguardo l'accostamento del lavoro di uno chef (sempre in piedi con strumenti a portata di mano) con quello del programmatore.
08 - "Stay Hungry"
Avevamo affrontato questo discorso già nell'articolo i 17 errori dei programmatori. Leggere riviste/blog di programmazione e di tecnologia aiuta ad essere preparati ed informati nel vasto mondo dell'informatica. Anche solo leggere Programmazione Applicata è un buon punto di partenza ma, se ci fate caso, cerco sempre di porre l'attenzione dei miei lettori su siti che ritengo affidabili facendo post dedicati (come il caso del sito Brent Ozar di cui avevo parlato in questo articolo) o come minimo inserendo in fondo all'articolo le fonti. Non si deve mai supporre di sapere tutto ed essere esperti, specialmente nell'informatica, non si finisce mai di imparare.
09 - Documenta e Commenta
Si lo so, nel punto 06 ho detto che è meglio dedicarsi prima alla sostanza che alla forma, è vero, ma la scrittura di un buon commento (e naturalmente di un buon codice) aiuta non tanto a risolvere un problema ma, in un giorno seguente, ad apportare modifiche o effettuare manutenzione. Se non volete fare un tema all'interno del codice sorgente può essere utile prendere degli appunti ed archiviarli (in formato elettronico, salviamo le foreste!). Ancora meglio sarebbe scrivere della documentazione di specifica del software che viene realizzato, ma a parte il mio lavoro non ho trovato molti settori in cui l'ufficio qualità del cliente ha una fobica attenzione alla documentazione rilasciata.
10 - Il Piano di Guerra
Durante la mia permanenza in Danimarca ho avuto la possibilità di vedere gli usi e i costumi della prima azienda di ingegneria di processo chimico-farmaceutico presente nel paese (è veramente l'azienda più importante Danese). Questi tizi (di tutti i settori, non solo software) entravano alle 06:00 del mattino e facevano 7 ore di lavoro filate fino alle 13:00, facevano un'oretta di pausa pranzo e dalle 14:00 alle 15:00 avevano un meeting per pianificare il lavoro del giorno seguente. Da quel momento ho sempre trovato utilissimo, se non fondamentale, pianificare il giorno prima le attività del giorno seguente (io personalmente lo faccio durante il tragitto di ritorno da lavoro a casa). Porsi degli obiettivi a breve termine aiuta a mantenere un ritmo serrato di lavoro senza perdere mai per un momento le scadenze e lo stato di avanzamento dei lavori.
Conclusione
Vorrei aggiungere il punto 11: Condividi. L'obiettivo di Programmazione Applicata non è solo quello di dare risorse utili ai programmatori ma anche quello di condividere esperienze per una crescita collettiva e collaborativa. I miei articoli non sono le tavole di Mose scolpite nella pietra, sono frutto delle mie personali esperienze e quindi vi chiedo di condividere con me le vostre impressioni ed opinioni (anche contrarie), grazie alle quali possiamo accrescere insieme le competenze professionali.
Avete qualche altro punto da suggerire? scrivete un commento a questo articolo oppure nel post dedicato della pagina ufficiale Facebook.
fonti
Nessun commento:
Posta un commento