Abbiamo visto tutti (e molti di noi hanno scritto) un sacco di codice scritto male. Perché? Cosa ci fa adottare pratiche inadeguate piuttosto che buone?
La risposta più ovvia (per me) è "ignoranza", ma sono sicuro che non è l'unica ragione. Quali altri ci sono? Cosa possiamo fare per superare la tentazione di scrivere codice errato?
Questo è il principale fattore dietro l'ignoranza, la cattiva gestione ecc.
Il capitolo 30 di Peopleware 2nd Edition è dedicato a questo argomento. E cita un libro di un altro consulente piuttosto noto, scritto un po 'prima però:
And it should be considered that nothing is more difficult to handle, more doubtful of success, nor more dangerous to manage, then to put oneself at the head of introducing new orders. For the introducer has all those who benefit from the old orders as enemies, and he has lukewarm defenders in all those who might benefit from the new orders.
Niccolo Machiavelli: The Prince (1513)
DeMarco e Lister continuano affermando il mantra da tenere a mente prima di chiedere alle persone di cambiare:
The fundamental response to change is not logical, but emotional.
Il processo di cambiamento è raramente una guida dritta e fluida dalle attuali condizioni sub-ottimali al mondo nuovo e migliorato. Per qualsiasi cambiamento non banale, c'è sempre un periodo di confusione e caos prima di arrivare al nuovo status quo . Imparare nuovi strumenti, processi e modi di pensare è difficile e richiede tempo. Durante questo periodo di transizione la produttività diminuisce, il morale soffre, le persone possono lamentarsi e desiderano se solo fosse possibile tornare ai buoni vecchi modi di fare le cose. Molto spesso lo fanno, anche con tutti i problemi, perché sentono che i migliori problemi noti sono migliori dei nuovi, sconosciuti, frustranti e imbarazzanti problemi. Questa è la resistenza che deve essere delicatamente e delicatamente, ma decisamente superata per avere successo.
Con pazienza e perseveranza, alla fine la squadra arriva dal caos alla fase successiva, pratica e integrazione. Le persone, anche se non completamente a proprio agio con i nuovi strumenti / processi, iniziano a prendere il controllo di queste cose. Potrebbero esserci esperienze positive di "Aha". E gradualmente, il team raggiunge un nuovo status quo.
È davvero importante rendersi conto che il caos è una parte integrante, inevitabile del processo di cambiamento . Senza questa conoscenza - e la preparazione per esso -, si può prendere il panico sul colpire la fase del caos, e scambiarlo con il nuovo status quo. Successivamente il processo di cambiamento viene abbandonato e il team ritorna al suo precedente stato miserabile, ma con ancora meno speranza di migliorare qualsiasi cosa ...
Per riferimento, le fasi sopra descritte sono state originariamente definite nel Satir Change Model (dal nome Virginia Satir ).
Péter Török ha ragione, ma ha lasciato fuori un punto importante e ottimistico:
quindi coinvolgeteli, lasciate che contribuiscano con le loro idee, lasciateli coinvolgere e non sarà così doloroso
Nota: questo è rilevante per la programmazione in quanto molti progetti software tecnicamente riusciti falliscono perché gli utenti li rifiutano .
Il tempo sembra essere grande quando lavoro.
es. Perché adottare un test unitario quando devi scrivere più codice e quindi impiegare più tempo per ottenere un prodotto rilasciabile? Il cliente x lo vuole ora! Codice più veloce!
(Ovviamente non finisce bene)
Questo è anche il risultato di una cattiva gestione ed economia, non di far pagare abbastanza ai clienti da permettersi di spendere il tempo per farlo nel modo giusto.
Nonostante le enormi prove del contrario, le persone sono di solito creature molto razionali. La ragione per cui le persone non adottano le migliori pratiche, come ad esempio TDD, è che non pensano che ne varrà la pena. O pensano che le pratiche non siano, in effetti, le migliori; e che in realtà li costerebbe più di quanto non li salverà. Oppure pensano che il vantaggio sia così marginale che il costo di change supererà il piccolo vantaggio. La linea di fondo è che il problema delle migliori pratiche è un problema della linea di fondo.
Se vuoi essere un agente di cambiamento, il tuo compito è dimostrare che la loro percezione della linea di fondo è imperfetta. Devi dimostrare che la migliore pratica è veramente la migliore. Che i benefici siano immediati e significativi . Devi dimostrare che la curva di apprendimento è abbastanza piccola da sopportare e che almeno alcuni dei benefici iniziano immediatamente.
Come lo mostri? Adottando la miglior pratica da soli! Niente serve a convincere gli altri meglio del tuo comportamento. Se tu segui le migliori pratiche e ne parli a voce, gli altri vedranno che tu hanno fatto l'analisi economica e hanno preso la decisione opposta. Ciò li farà riconsiderare la loro decisione. Lo faranno privatamente, e non lo ammetteranno mai all'inizio. Ma tutti quelli che ti vedono usando quella best practice, riesamineranno la loro posizione.
Questo è il meglio che puoi sperare. Se la migliore pratica è una best practice, il resto seguirà automaticamente. Oh, non sarà veloce, e ci saranno molti ritardi. La transizione sarà lenta e macchiata; e sperimenterai molte delusioni. Ma la transizione sarà anche inesorabile e inevitabile. Potrebbe richiedere una generazione, ma la migliore pratica vincerà .
Come prova di ciò, chiediti quando hai visto l'ultima volta che qualcuno usa goto.
È il risultato del non sapere, o pensare che si conosce il metodo ideale. Le persone non scelgono di scrivere male il codice; è più un caso di non sapere meglio. " Naivety ", al contrario di " ignoranza " sarebbe una parola migliore.
Il modo più semplice per conformarsi alle buone pratiche è riconoscere che c'è (molto probabilmente) un modo migliore per scrivere il codice che hai appena scritto, e quindi aspirare ad imparare che cosa sia "modo migliore".
Due cause
L'ignoranza.
L'arroganza.
Come possono essere superati?
Fino a quando i manager (cioè, le persone che acquistano le capacità dello sviluppatore) richiedono le migliori pratiche come parte della consegna del software, nulla può cambiare. Molte organizzazioni sono chiaramente schizofreniche: educano gli sviluppatori in varie tecnologie e quindi richiedono software non testato o un progetto non verificabile. O peggio.
Best Practice for me è un software che una squadra di 8 persone ha scritto. Non avevamo requisiti scritti, recensioni di codici, test unitari, documenti di rilascio del formato. Nessun test per l'utente finale, nessuno di ciò che tutti i libri dicono che avremmo dovuto fare. Il codice era frettoloso, buggy e chiaramente impossibile da mantenere. È stato scartato 3 anni dopo il rilascio è stato così male. Quindi, cosa c'è di così eccezionale. Due anni dopo il primo rilascio, il proprietario della società (che aveva finanziato lo sviluppo con un mutuo in casa sua) se ne andò con $ 30- $ 40 milioni nella tasca posteriore.
Spesso perdiamo di vista il fatto che siamo (il più delle volte) qui per creare software che faccia soldi per il business. Le aziende non esistono per darci l'opportunità di sviluppare software usando "Best Practice", esistono per fare soldi.
La maggior parte delle pratiche di "best practice" non migliorano i profitti. Quelli che fanno, dovrebbero e sono, ampiamente adottati. Ecco perché la "migliore pratica" non è praticata.
Rischio accettabile
Non hai mai preso un rischio e hai scommesso su qualcosa? C'è una crisi di tempo, quindi puoi farlo funzionare con l'intenzione di rifattenerlo in seguito (al contrario di rifattorizzarlo prima). In realtà è considerato una buona pratica per alcune persone.
Alla fine, vieni bruciato abbastanza volte e cambi i tuoi modi. Pensa a tutte le "migliori pratiche" che sono là fuori. Puoi seguirli tutti per tutto il tempo? Qualunque contraddizione l'un l'altro? Non vuoi perdere tempo a gestire ogni outlier.
Se scrivo codice errato che funziona e nessuno lo guarda mai più, è ancora considerato negativo? (Per favore, non roviniamo il dibattito filosofico discutendo su cosa sia "codice cattivo".
IME è una combinazione di ciò che hanno detto gli altri. Ignoranza ("Ho sempre usato solo DataSet, perché preoccuparmi di questo materiale LINQ?", Mancanza di tempo ("Il Capo vuole farlo il prima possibile, non possiamo passare molto tempo su di esso"), mancanza di comprensione ("Cosa c'è di sbagliato con la scrittura di tutto il mio codice nel code-behind?") tutti contribuiscono.
L'ironia che vedo è che una volta che inizi quella via, ti imponi di andare più a fondo. Se tagli ora gli angoli e lanci tutto il codice per un'app nei file ASPX, non sarai mai in grado di risolverlo in seguito; nuove cose continueranno a essere lanciate contro di te, il che significa che devi farle rapidamente, il che significa che devi solo lanciare tutto il codice nel file ASPX (giurando che lo aggiusti un giorno), ecc. ecc. - spirale a spirale perché non è più possibile interrompere lo sviluppo e dire che è necessario correggere prima le cose.
Spesso gli sviluppatori non hanno semplicemente mostrato la pratica migliore o, ancora più importante, i vantaggi dell'uso di una pratica migliore (sto iniziando a smettere di usare il termine "Best practice" per vari motivi).
C'è una teoria secondo cui gli sviluppatori sono "deliberatamente pigri". In altre parole, tenderanno a scegliere il percorso di minor resistenza.
Una volta mostrati rapidamente i vantaggi di una pratica migliore (come TDD, o dire, seguendo i principi SOLID) e che in realtà permette loro di essere uno sviluppatore migliore (ma ancora 'pigro'), allora si tende a trovare quella resistenza si scioglie.
È una questione di educazione:)
(Mancanza di) Conoscenze e abilità + Tempo per investire
Sono sorpreso che nessun altro abbia messo questo fuori, ma forse è ovvio per me, perché gran parte del mio lavoro è stato un programmatore singleton, con nessuno (diverso dallo stack) a cui andare quando faccio fatica qualcosa. Conosco 'di' tecniche migliori - come TDD - ma spesso non le capisco abbastanza bene da usarle e faccio fatica a trovare buone informazioni per aiutarmi a iniziare a usarle. Ancora, usando TDD come esempio, ne capisco il significato di base: costruisci test che affermano che il tuo codice genera un risultato specifico, ma in realtà lo sta implementando?
A parte il fatto che XCode ha in questi giorni test di unità integrati, non ho idea di dove cominciare. Devo affermare che la vista ha dei pulsanti X su di essa dopo aver eseguito una routine per crearli? Che ne dici di affermare che i miei UIViews sono stati riorganizzati in modo appropriato dopo aver chiamato il tag di rotazione?
Diamine, come faccio a scrivere un test unitario in XCode? È un'altra cosa di cui ho bisogno per imparare il tempo.
@Zues e @Joshua Smith
Sì, sono d'accordo a volte il tempo e il budget sono alcuni vincoli che non ti permettono di mettere in ogni programma un "programma di programmazione migliore".
Sai che l'attività corrente può essere svolta in modo molto più efficace se solo tu avessi avuto più tempo. Ma pochissimi clienti (specialmente se stanno facendo la loro prima App per iPhone o il loro primo software di business intelligence personalizzato) capiscono quando dici di re-implementare qualcosa già fatto perché hai trovato un modo migliore di farlo.
Lo stesso per Test unitari. Sfortunatamente devo ancora incontrare un cliente che è pronto a stanziare budget per quelli. Risposta tipica è come "Test di regressione automatizzati OK, ho capito ma test unitari? Non abbiamo tempo per quello! Dobbiamo arrivare velocemente al mercato! "
Due parti nella maggior parte della mia esperienza:
Le "migliori pratiche" sono MOLTO soggettive in molte situazioni del mondo reale. Se una metà della squadra sta provando a fare un sacco di SOLID e amp; TDD mentre l'altra metà lavora per 60 ore alla settimana per radere secondi di durata della corsa qua e là con ogni mezzo necessario perché hai superato il punto in cui è troppo tardi per ridisegnare qualcosa che non sta funzionando in tempo per la tua prossima uscita, tu non arriveranno molto lontano.
Anche se non si verificano troppi disaccordi in tutto il team, è molto difficile ottenere un accordo formale, documentazione e formazione su qualunque politica tu decida di seguire. Questo è un grande blocco di tempo non produttivo dal punto di vista del business che dovrai giustificare attentamente.
A volte, scoprirai che abitudine è anche un importante contributo alla scrittura di codice terribile.
Potresti essere un programmatore molto esperto e potresti sapere tutto sulle migliori pratiche del settore. Diavolo, potresti anche essere l'esperto su queste cose. L'esperienza mi dice che queste persone spesso non scrivono codice terribile, eppure può essere facile ricorrere alle vecchie abitudini e fare qualcosa che sai infrangerà le regole, semplicemente perché sembra sicuro e conveniente. In tali casi, l'ignoranza e l'arroganza e tutti gli altri aggettivi puntati su di un dito che potresti pensare non hanno molta importanza. Non è necessariamente che tali programmatori sono particolarmente cattivi in quello che fanno (anche se questo è più spesso il caso), o anche che vogliono creare un pasticcio terribile.
È sfortunato che abbia assistito personalmente a questo evento più volte di quanto vorrei contare, dove alcune persone di talento hanno sfornato pura spazzatura perché le loro dita e il loro cervello stavano operando in auto per un paio di mesi. Molto spesso questo è il punto in cui si vedono tracce di esaurimento, dolore e stress accumulati. A volte è solo un'abitudine cieca che li trasporta attraverso le mosse quotidiane. È qualcosa su cui ho imparato a prestare attenzione per evitare il rischio di etichettare inutilmente persone vulnerabili.
Solo un po 'di spunti di riflessione per quelli di noi che trovano più facile semplicemente saltare alla conclusione negativa ... anche se purtroppo avrai ragione il più delle volte.
Nessuno mostra interesse a pagare per un progetto intitolato qualcosa lungo il refactoring. Deve avere alcune parole che fanno appello agli interessi "commerciali". Parole come rinnovamento, rinvigorimento, rifacimento totale, aggiornamento del ciclo di vita, ecc. Funzionano nel mio posto di lavoro. Quasi tutti hanno il refactoring come parte principale del progetto.
Purtroppo, grazie al sicario economico, il lavoro avviene solo quando c'è una paga. Anche se il lavoro è solo per salvare le fortune aziendali a lungo termine.
Leggi altre domande sui tag learning