Le 10 cose che più infastidiscono gli sviluppatori?
Se siete sviluppatori le sapete già, ma vale la pena scriverle per “avvisare” gli altri della categoria che certe cose infastidiscono anche gli altri!!!
Comunque l’ordine potrebbe essere percepito diversamente da sviluppatore a sviluppatore.
10. Commenti che dicono “cosa”, ma non “perchè”
I corsi di programmazione di livello introduttivo insegnano agli studenti di commentare subito e spesso. Questa è una pratica utile per un giovanissimo programmatore, ma… come commentano?
r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while (abs( r - (n/r) ) > t) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
Il problema è che il codice descrivo cosa fa, ma non perchè lo sta facendo!
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
Purtroppo, è molto difficile raggiungere il “passo” (noto anche come “being in the zone”), quando il filo logico è costantemente interrotto da clienti e colleghi.
Wikipedia definisce scope creep “variazioni non controllate in ambito di un progetto”.
Scope creep può trasformare una richiesta relativamente semplice in un compito terribilmente complesso e che richiede molto tempo. Tutto ciò che serve è un paio di battute apparentemente innocue per distruggere linea temporale di un progetto:
Versione 1: Visualizza una mappa del luogo
Versione 2: Visualizza una mappa 3D della posizione
Versione 3: Mostra una mappa 3D della posizione su cui l’utente può volare attraverso
6. Documentare le nostre applicazioni
Se si lavora con un’applicazione che normali persone comuni stanno usando, è necessario scrivere una documentazione che “chiunque” possa capire (ad esempio come funziona l’applicazione, guide di risoluzione dei problemi, ecc.)
Questa è una cosa che fa paura ai programmatori. Date un rapido sguardo a tutti i progetti open-source là fuori. Qual è l’unica cosa per cui tutti chiedono costantemente aiuto? La doocumentazione.
Non ho mai detto che non siamo ipocriti. I programmatori sono costantemente invitati a integrare le biblioteche 3rd party e le applicazioni. Per fare questo, abbiamo bisogno di documentazione. Purtroppo, come indicato al punto 6, i programmatori odiano scrivere documentazione. No, l’ironia non si perde su di noi.
Non c’è niente di più frustrante che cercare di utilizzare una libreria di terze parti pur non avendo assolutamente idea di cosa facciano metà delle funzioni delle API presenti. Qual è la differenza tra poorlyNamedFunctionA() e poorlyButSimilarlyNamedFunctionB()? Ho bisogno di effettuare un controllo null prima di accedere PropertyX? Credo che dovrò solo per scoprire attraverso tentativi ed errori! Ugh.
Ogni programmatore che sia mai stato chiamato a eseguire il debug di uno strano incidente su un server o perché le unità RAID non funzionano correttamente sa che i problemi hardware sono un dolore. Sembra che ci sia un malinteso comune: da programmatori lavorano con i computer, quindi necessariamente devono sapere come risolverli. Certo, questo può essere vero per alcuni programmatori, ma mi sa che la stragrande maggioranza non sanno veramente quello che succede dopo che il codice viene tradotto dalla macchina!
“Il sito web è rotto”. “La caratteristica X non funziona correttamente”. Richieste vaghe sono un dolore da affrontare.
E’ sempre sorprendente come i non programmatori tendono a reagire quando gli viene chiesto di riprodurre un problema per mostrarlo al programmatore. Non sembrano capire che “è rotto, risolvete il problema!” non è un’informazione sufficiente per lavorarci su.
Software è (per la maggior parte) deterministica. Ci piace così. Fa ridere che anzichè farci capire quale fase del processo è rotta, venga chiesto semplicemente “aggiustarlo”.
I programmatori non sempre vanno d’accordo con altri programmatori. Scioccante, ma vero. Di seguito alcuni punti, elencati a caso, ma che possono variare da programmatore a programmatore…
Essere scontroso al punto di essere ostile.
Non riuscire a capire che c’è un tempo per discutere l’architettura di sistema e un tempo per fare le cose.
Incapacità di comunicare in modo efficace e confusione terminologica.
Essere apatici verso il codice ed il progetto
Avete mai guardato il tuo codice di mesi prima e fatto una smorfia di dolore? “Che stupido sei stato! Come hai potuto! Hai scritto così???? Fuck!”
Bene, una buona notizia. Non siete i soli.
