Quali sono gli ostacoli all'adozione delle migliori pratiche? Come possono essere superati? [chiuso]

Abbiamo visto tutti (e molti di noi hanno scritto) un sacco di codice scritto male. Perché? Cosa ci fa adottare pratiche povere piuttosto che buone?

La risposta più ovvia (per me) è "l'ignoranza", ma sono sicuro che non sia l'unica ragione. Quali altri ci sono? Cosa possiamo fare per superare la tentazione di scrivere un codice errato?

Resistenza al cambiamento.

Questo è il principale fattore dietro l'ignoranza, la cattiva gestione ecc.

Il capitolo 30 di Peopleware 2nd Edition è dedicato a questo argomento. E cita da un libro di un altro consulente abbastanza noto, scritto un po 'prima:

E si dovrebbe considerare che nulla è più difficile da gestire, più incerto del successo, né più pericoloso da gestire, quindi mettersi alla testa dell'introduzione di nuovi ordini. L'introduttore ha tutti coloro che traggono beneficio dai vecchi ordini come nemici e ha difensori tiepidi in tutti coloro che potrebbero trarre beneficio dai nuovi ordini.

Niccolò Machiavelli: Il Principe (1513)

DeMarco e Lister continuano a dichiarare il mantra da tenere a mente prima di chiedere alle persone di cambiare:

La risposta fondamentale al cambiamento non è logica, ma emotiva.

Il processo di cambiamento è raramente una guida semplice e regolare dalle attuali condizioni non ottimali al nuovo mondo 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 desiderare se solo fosse possibile tornare ai buoni vecchi modi di fare le cose. Molto spesso lo fanno, anche con tutti i problemi, perché ritengono che i buoni vecchi problemi noti siano migliori dei nuovi, sconosciuti, frustranti e imbarazzanti. 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, sebbene non si sentano completamente a proprio agio con i nuovi strumenti / processi, iniziano a capire queste cose. Potrebbero esserci esperienze positive "Aha". E gradualmente, il team raggiunge un nuovo status quo.

È davvero importante rendersi conto che il caos è parte integrante e inevitabile del processo di cambiamento . Senza questa conoscenza - e preparazione per questo -, si può andare nel panico dopo aver colpito la fase del Caos, e confonderla con il nuovo status quo. Successivamente il processo di modifica viene abbandonato e il team ritorna al suo stato miserabile precedente, ma con ancora meno speranza di migliorare qualsiasi cosa ...

Per riferimento, le fasi sopra descritte sono state originariamente definite nel Modello di cambiamento di Satir (dal nome di Virginia Satir ).

Péter Török ha ragione, ma tralascia un punto importante e ottimista:

• alla gente potrebbe piacere il cambiamento in cui sono coinvolti, ma non gli piace quasi mai il cambiamento che "accade" a loro

quindi coinvolgeteli, lasciate che contribuiscano con idee, lasciate che vi creino una partecipazione 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 dove lavoro.

ad es. Perché adottare i test unitari quando si deve scrivere più codice e quindi impiegare più tempo per ottenere un prodotto rilasciabile? Il client x lo vuole ora! Codice più veloce!

(Questo ovviamente non finisce bene)

Questo è anche il risultato di una cattiva gestione ed economia, che non carica i clienti abbastanza da permettersi di passare il tempo a farlo bene.

Nonostante le enormi prove contrarie, le persone sono di solito creature molto razionali. La ragione per cui le persone non adottano le migliori pratiche, come TDD per esempio, è che non pensano che ne varrà la pena. O pensano che le pratiche non siano, in effetti, migliori; e che in realtà li costerà più di quanto non li salverà. Oppure pensano che il beneficio sia così marginale che il costo del cambiamento supererà il piccolo beneficio. La linea di fondo è che il problema delle migliori pratiche è un problema di linea di fondo.

Se vuoi essere un agente di cambiamento, il tuo compito è dimostrare che la loro percezione della linea di fondo è difettosa. Devi dimostrare che la migliore pratica è davvero la migliore. Ciò che i benefici sono immediati e significativi . Devi dimostrare che la curva di apprendimento è abbastanza piccola da resistere e che almeno alcuni dei benefici iniziano immediatamente.

Come lo mostri? Adottando te stesso la migliore pratica! Nulla serve a convincere gli altri meglio del tuo comportamento. Se si seguono le migliori pratiche, e sono vocale su di esso, gli altri vedranno che si fatto l'analisi economica e preso la decisione opposta. Ciò li farà riconsiderare la loro decisione. Lo faranno privatamente e non lo ammetteranno mai all'inizio. Ma tutti coloro che ti vedranno usare questa best practice, riesamineranno la loro posizione.

Questo è il meglio che puoi sperare. Se la migliore pratica è una buona pratica, il resto seguirà automaticamente. Oh, non sarà veloce e ci saranno molti ritardi. La transizione sarà lenta e imprevedibile; e sperimenterai molte delusioni. Ma la transizione sarà anche inesorabile e inevitabile. Si potrebbe prendere una generazione, ma la migliore pratica si vincerà.

A riprova di ciò, chiediti quando hai visto qualcuno usare goto per l'ultima volta.

È il risultato di non sapere o pensare di conoscere il metodo ideale. Le persone non scelgono di scrivere codice male; è più un caso di non sapere meglio. " Ingenuità ", in contrapposizione a " ignoranza " sarebbe una parola migliore.

Il modo più semplice per conformarsi alle buone pratiche è riconoscere che esiste (molto probabilmente) un modo migliore per scrivere il codice che hai appena scritto, e quindi aspirare a imparare cos'è quel "modo migliore".

Due cause

• Ignoranza.

• Arroganza.

Come possono essere superati?

• Incentivi.

Fino a quando i gestori (ovvero quelli che acquistano le competenze dello sviluppatore) richiedono le migliori pratiche nell'ambito 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 design non verificabile. O peggio.

Best Practice per me è un software che un team di 8 persone ha scritto. Non avevamo requisiti scritti, revisioni del codice, test unitari, documenti di rilascio del formato. Nessun test per l'utente finale, niente di tutto ciò che tutti i libri dicono che avremmo dovuto fare. Il codice era affrettato, difettoso e impossibile da mantenere. È stato scartato 3 anni dopo il rilascio ed è stato così male. Quindi, ciò che è stato fantastico. Due anni dopo la prima uscita, il proprietario dell'azienda (che aveva finanziato lo sviluppo con un mutuo sulla propria abitazione) 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 l'azienda. Le aziende non esistono per fornirci l'opportunità di sviluppare software utilizzando "Best Practice", esistono per fare soldi.

La maggior parte delle pratiche di "Best practice" non migliora i profitti. Quelli che lo fanno, dovrebbero e sono ampiamente adottati. Ecco perché la "migliore pratica" non è praticata.

Rischio accettabile

Non hai mai rischiato e scommesso su qualcosa? C'è una crisi di tempo, quindi puoi farlo funzionare con l'intenzione di rifattorizzarlo in seguito (invece di rifattorizzarlo prima). Questa è in realtà considerata una buona pratica per alcune persone.

Alla fine, vieni bruciato abbastanza volte e cambi i tuoi modi. Pensa a tutte le "migliori pratiche" disponibili. Riesci a seguirli tutti per tutto il tempo? Si contraddicono a vicenda? Non vuoi perdere tempo a gestire tutti i valori anomali.

Se scrivo codice errato che funziona e nessuno lo guarda mai più, è ancora considerato cattivo? (Per favore, non roviniamo il dibattito filosofico discutendo su cosa sia il "codice cattivo".)

L'IME è una combinazione di ciò che altri hanno detto. Ignoranza ("Ho sempre usato DataSet, perché preoccuparsi di questa roba LINQ?", Mancanza di tempo ("Il Boss vuole che sia fatto il prima possibile, non possiamo passare molto tempo su di esso"), mancanza di comprensione ("Cosa c'è di sbagliato nel scrivere tutto il mio codice nel code-behind?") tutti contribuiscono.

L'ironia che vedo è che una volta che inizi su quella strada, ti infili solo più a fondo. Se tagli gli angoli ora 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 farlo rapidamente, il che significa che devi semplicemente lanciare tutto il codice nel file ASPX (giurando che lo riparerai un giorno), ecc. ecc. non è mai spirale infinita perché non puoi più fermare lo sviluppo e dire che le cose devono prima essere riparate.

Spesso agli sviluppatori non sono state semplicemente mostrate le migliori pratiche o, soprattutto, i vantaggi dell'utilizzo di una migliore pratica (sto iniziando a smettere di usare il termine "Best practice" per vari motivi).

C'è una teoria secondo cui gli sviluppatori sono "volutamente pigri". In altre parole, tenderanno a scegliere il percorso di minor resistenza.

Una volta che mostri loro rapidamente i vantaggi di una pratica migliore (come TDD, o dici, seguendo i principi SOLIDI) e che in realtà consente loro di essere uno sviluppatore migliore (ma ancora "pigro"), allora tendi a scoprire che la resistenza si scioglie lontano.

È una questione di educazione :)

(Mancanza di) conoscenza e abilità + tempo di investire

Sono sorpreso che nessun altro l'abbia messo fuori, ma forse è ovvio per me perché gran parte del mio lavoro è stato come programmatore singleton, senza nessuno (a parte lo stack) a cui andare quando faccio fatica su qualcosa. Conosco "di" tecniche migliori - come il TDD - ma spesso non le capisco abbastanza bene per usarle e faccio fatica a trovare buone informazioni per aiutarmi a iniziare a usarle. Ancora una volta, usando TDD come esempio, capisco il significato di base di esso - costruire test che affermano che il tuo codice produce un risultato specifico - ma lo stai effettivamente implementando?

A parte il fatto che XCode ha integrato i test unitari in questi giorni, non ho idea di dove iniziare. Devo affermare che la vista ha dei pulsanti X su di essa dopo aver eseguito una routine per farli? Che ne dici di affermare che le mie UIVview sono state riorganizzate in modo appropriato dopo che ho chiamato il tag di rotazione?

Cavolo, come faccio a scrivere un unit test in XCode? È qualcos'altro che devo dedicare del tempo all'apprendimento.

@Zues e @Joshua Smith

Sì, concordo che a volte il tempo e il budget sono alcuni vincoli che non consentono di inserire in un programma ogni principio di "migliore programmazione".

Sai che il compito attuale può essere svolto in modo molto più solido se solo avessi un po 'più di tempo. Ma pochissimi clienti (specialmente se stanno realizzando la loro prima app per iPhone o il loro primo software di business intelligence personalizzato) capiscono quando dici che stai implementando qualcosa di già fatto perché hai trovato un modo migliore per farlo.

Lo stesso vale per i test unitari. Purtroppo devo ancora incontrare un cliente che è pronto ad allocare il budget per quelli. La risposta tipica è come "Test di regressione automatizzata OK Capisco ma test unitari? Non abbiamo tempo per quello! Dobbiamo arrivare velocemente sul mercato! ”

Due parti nella maggior parte della mia esperienza:

• tempo
• ottenere abbastanza persone per concordare quali pratiche siano le migliori per la situazione attuale

Le "migliori pratiche" sono MOLTO soggettive in molte situazioni del mondo reale. Se metà del team sta provando a fare un sacco di SOLID e TDD mentre l'altra metà lavora 60 ore a settimana per radunare i secondi fuori dalle durate di corsa qua e là attraverso tutti i mezzi necessari perché hai superato il punto in cui è troppo tardi per riprogettare qualcosa che non si esibirà in tempo per la prossima versione, non andrai molto lontano.

Anche se non stai riscontrando troppi disaccordi all'interno del 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 aziendale che dovrete giustificare attentamente.

A volte, scoprirai che l' abitudine è anche un grande contributo alla scrittura di codice terribile.

Potresti essere un programmatore di grande esperienza e potresti conoscere tutto sulle attuali migliori pratiche del settore. Cavolo, potresti persino essere un esperto di queste cose. L'esperienza mi dice che spesso queste persone non scrivono codice terribile, eppure può essere facile ricorrere a vecchie abitudini e fare qualcosa che sai infrangere le regole, semplicemente perché sembra sicuro e conveniente. In questi casi, l'ignoranza e l'arroganza e tutti gli altri aggettivi che potresti pensare non contano davvero. Non è necessariamente che tali programmatori siano particolarmente cattivi in ​​quello che fanno (anche se questo è più spesso il caso), o anche che vogliono creare un disastro terribile.

È un peccato che io abbia assistito personalmente a questo fatto accadendo più volte di quanto mi piacerebbe contare, dove alcune persone veramente talentuose hanno sfornato immondizia perché le loro dita e il loro cervello hanno funzionato in auto per un paio di mesi. Molto spesso è qui che si vedono prove di esaurimento, dolore e stress che si accumulano. A volte è davvero solo un'abitudine cieca che li porta attraverso i movimenti quotidiani. È qualcosa che ho imparato a tenere d'occhio per evitare il rischio di etichettare le persone vulnerabili inutilmente.

Solo qualche spunto di riflessione per quelli di noi che trovano più facile saltare semplicemente alla conclusione negativa ... anche se purtroppo avrai ragione più spesso che no.

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 rinnovo, rinvigorimento, rifacimento totale, aggiornamento del ciclo di vita, ecc. Funzionano sul mio posto di lavoro. Quasi tutti hanno il refactoring come parte principale del progetto.

Purtroppo, grazie al sicario dell'economia, il lavoro si svolge solo quando c'è la paga. Anche se il lavoro è solo quello di salvare le fortune aziendali a lungo termine.