In che modo i programmatori veloci e sporchi sanno di aver capito bene?

Se chiedi ai programmatori perché dovrebbero scrivere un codice pulito, la risposta numero uno che ottieni è la manutenibilità. Mentre è nella mia lista, la mia ragione principale è più immediata e meno altruistica: non posso dire se il mio nuovo codice è corretto se è troppo sporco. Trovo di essermi concentrato così tanto sulle singole funzioni e linee di codice che, quando finisco la mia prima bozza e torno indietro per guardare di nuovo il quadro generale, a volte non si adattano molto bene. Trascorrere un'ora o due nel refactoring per la pulizia spesso rivela errori di copia / incolla o condizioni al contorno che erano molto difficili da rilevare nella bozza approssimativa.

Tuttavia, alcune persone ritengono che occasionalmente sia corretto controllare intenzionalmente codice sporco nell'interesse del software di spedizione, con un piano per "ripulirlo più tardi". C'è qualche tecnica praticabile che dà loro fiducia nella correttezza del loro codice quando la leggibilità è meno che ideale? È un'abilità che vale la pena provare a sviluppare? O la mancanza di fiducia nel codice è qualcosa che alcune persone trovano più facile da accettare?

Il codice probabilmente non è corretto.

Tuttavia, potrebbe non avere importanza.

Veloce e sporco può essere il modo giusto di andare in situazioni in cui:

• Il codice ha una durata breve . Ad esempio, stai trasformando un mucchio di dati in un formato standard con un programma ad hoc.
• L'impatto negativo del fallimento è basso :
  • I dati che stai trasformando non sono critici e gli errori possono essere facilmente corretti
  • L'utente finale è un programmatore simpatico, che ragionerà sui messaggi di errore e aggirerà, diciamo, massaggiando l'input.

A volte non è importante che il codice sia robusto e gestisca ogni input concepibile. A volte deve solo gestire i dati noti che hai a portata di mano.

In quella situazione, se i test unitari ti aiutano a scrivere il codice più velocemente (questo è il caso per me), quindi usali. Altrimenti, codice veloce e sporco, fai il lavoro. I bug che non si innescano non contano. I bug che correggi o aggiri al volo non contano.

Ciò che è assolutamente vitale è che non si dia una diagnosi errata di queste situazioni. Se si digita il codice in modo rapido perché il codice verrà utilizzato solo una volta, allora qualcuno decide di riutilizzare il codice in qualche progetto che merita un codice migliore, quel codice merita più attenzione.

Non lo fanno. Attualmente sto lavorando su una base di codice creata da programmatori "veloci e sporchi" che "ripulirebbero in seguito". Se ne sono andati da tempo, e il codice continua a sopravvivere, scricchiolando verso l'oblio. I programmatori di cowboy , in generale, semplicemente non comprendono tutte le potenziali modalità di errore che il loro software potrebbe avere e non comprendono i rischi a cui stanno esponendo la società (e i clienti).

Va bene, a rischio di essere completamente esca negativa, ho intenzione di "sostenere i diavoli" l'opinione opposta.

Propongo che noi sviluppatori tendiamo a preoccuparci eccessivamente di cose come la pratica corretta e la pulizia del codice. Suggerisco che, sebbene queste cose siano importanti, nessuna di queste importa se non spedisci mai .

Chiunque sia stato in questo settore per un po 'probabilmente sarebbe d'accordo sul fatto che sarebbe possibile giocherellare con un pezzo di software più o meno indefinitamente. Duke Nukem Forever, amici miei. Arriva un momento in cui quella caratteristica piacevole o quella oh così urgente attività di refactoring dovrebbe essere messa da parte e la cosa dovrebbe essere chiamata FATTO.

Ho litigato con i miei colleghi molte volte. C'è SEMPRE un altro tweak, qualcos'altro che "dovrebbe" essere fatto perché sia ​​"giusto". Puoi SEMPRE trovarlo. Ad un certo punto, nel mondo reale, abbastanza buono deve essere abbastanza buono. Nessun software di spedizione reale o reale è perfetto. Nessuna. Nel migliore dei casi, è abbastanza buono.

Questi programmatori non sanno quasi mai di aver fatto bene, ma ci credono . E la differenza potrebbe non essere facile da percepire.

Ricordo come ero solito programmare prima di apprendere i test unitari. E ricordo quella sensazione di fiducia e fiducia a un livello completamente diverso dopo aver eseguito la mia prima discreta suite di test unitari. Non sapevo che un tale livello di fiducia nel mio codice esistesse prima.

Per qualcuno a cui manca questa esperienza, è impossibile spiegare la differenza. Quindi possono anche continuare a svilupparsi in modalità codice e pregare per tutta la vita, credendo benevolmente (e ignoratamente) di fare del loro meglio considerando le circostanze.

Detto questo, possono davvero esserci grandi programmatori e casi eccezionali, quando si riesce davvero a tenere l'intero spazio del problema nella propria mente, in uno stato di flusso completo. Ho vissuto momenti rari come questo, quando sapevo perfettamente cosa scrivere, il codice mi è volato via senza sforzo, ho potuto prevedere tutti i casi speciali e le condizioni al contorno e il codice risultante ha funzionato . Non ho dubbi sul fatto che ci siano geni di programmazione là fuori che possono rimanere in tale stato di flusso per periodi prolungati o anche la maggior parte del loro tempo, e ciò che producono è un bellissimo codice, apparentemente senza sforzo. Immagino che queste persone potrebbero non aver bisogno di scrivere test unitari per verificare ciò che già sanno. E se sei davvero un tale genio, potrebbe essere OK (anche se anche allora, non sarai in giro per quel progetto per sempre e dovresti pensare ai tuoi successori ...). Ma se no ...

E ammettiamolo, è probabile che tu non lo sia. Io stesso so di non esserlo. Ho avuto alcuni rari momenti di flusso - e innumerevoli ore di dolore e tristezza, di solito causate dai miei stessi errori. È meglio essere onesti e realistici. In effetti, credo che i più grandi programmatori siano pienamente consapevoli della propria fallibilità e degli errori passati, quindi hanno consapevolmente sviluppato l'abitudine di ricontrollare i loro presupposti e scrivere quei piccoli test unitari, per mantenersi al sicuro. ( "Non sono un grande programmatore - solo un buon programmatore con grandi abitudini." - Kent Beck.)

Test unitari . È l'unico modo per avere fiducia in qualsiasi codice (sporco o no).

In una nota a margine;

le scorciatoie causano lunghi ritardi (Pipino)

È utile imparare ad accettare che nessun sistema software di ragionevole complessità sarà perfetto, indipendentemente da quanti test unitari e modifiche al codice vengono eseguite. Un certo grado di caos e vulnerabilità all'imprevisto si nascondono sempre all'interno del codice. Ciò non significa che non si dovrebbe provare a produrre un buon codice o condurre test unitari. Questi sono, ovviamente, importanti. C'è un equilibrio da cercare e questo varierà da progetto a progetto.

L'abilità da sviluppare è la comprensione di quale livello di "perfezione" deve essere utilizzato per un particolare progetto. Ad esempio, se stai scrivendo un'applicazione di cartelle cliniche elettroniche con una sequenza temporale del progetto di 12 mesi, dovrai dedicare molto più tempo per i test e assicurarti che il tuo codice sia mantenibile rispetto a quanto faresti per un'app Web di registrazione di una conferenza unica che deve essere distribuito entro venerdì. I problemi arrivano quando qualcuno che fa l'app EMR diventa sciatto o l'app di registrazione non viene distribuita in tempo perché il programmatore è troppo impegnato a modificare il codice.

Veloce e sporco va perfettamente bene all'interno di un sottosistema . Se hai un'interfaccia ben definita tra la tua merda e il resto del sistema e una buona serie di test unitari che verificano che il tuo brutto codice veloce e sporco faccia la cosa giusta, potrebbe andare perfettamente.

Ad esempio, forse hai qualche orribile hack di espressioni regolari e offset di byte per analizzare alcuni file provenienti da terze parti. E supponi di avere un test che dice che il risultato che ottieni dall'analisi dei file di esempio è quello che ti aspetti. Potresti ripulirlo in modo da poter ... Non lo so, reagire più rapidamente quando una terza parte cambia un formato di file? Questo non succede abbastanza spesso. Più probabilmente passeranno a un'API completamente nuova e butterai via il vecchio parser e ne collegherai uno nuovo conforme alla stessa API, e voilà, il gioco è fatto.

Dove veloce e sporco diventa un problema è quando la tua architettura è veloce e sporca. Il tuo oggetto di dominio principale deve essere ben congegnato e le tue interfacce, ma i bordi del tuo sistema di solito possono essere disordinati senza mai dover pagare il piper.

Ecco una storia su un programmatore veloce e sporco che conosco.

Ho conosciuto una persona che considera i test unitari una perdita di tempo. Dopo molte discussioni, alla fine ne scrisse uno. Consisteva in un lungo metodo cosparso di && e || e ha restituito un valore booleano per assert True. La dichiarazione si estende su 20 righe. Poi di nuovo, ha scritto una classe in cui ogni metodo aveva una riga e una principale aveva oltre 1000 righe senza spazi bianchi. Era un muro di testo. Quando ho rivisto il suo codice e inserito alcune nuove righe, ha chiesto "perché". Ho detto "A causa della leggibilità". Sospirò e li cancellò. Ha messo un commento in alto "Non toccarlo, funziona!"

L'ultima volta che ho parlato con lui, ha codificato un sito Web per un'azienda. Stava cercando di trovare un bug. Aveva trascorso gli ultimi 3 giorni a farlo per 8 ore al giorno. Poco dopo gli ho parlato di nuovo, e si è scoperto che il suo compagno di squadra ha cambiato il valore di un letterale e non lo ha aggiornato altrove. Non è stata una costante. Quindi ha cambiato anche gli altri letterali in modo che il suo bug fosse corretto. Si è lamentato del codice spaghetti del suo compagno di squadra. Mi ha detto 'Haha, non sappiamo tutti cosa significhi stare svegli tutta la notte con il debugger, senza dormire per un brutto bug "Pensa che sia qualcosa di veramente buono che fanno i programmatori e si sente davvero bene.

Inoltre, ritiene inutile leggere libri e blog di programmazione. Dice "inizia a programmare". Lo ha fatto per 12 anni e pensa di essere un programmatore eccellente. / facepalm

Eccone un po 'di più.

Un'altra volta stavamo scrivendo una classe DatabaseManager per la nostra app web. Ha inserito tutte le chiamate al database. Era una classe di Dio con oltre 50 metodi per ogni cosa immaginabile. Ho suggerito di suddividerlo in sottoclassi perché non tutti i controller devono conoscere ogni metodo di database. Non era d'accordo, perché era "facile" avere solo una classe per l'intero database ed era "veloce" aggiungere un nuovo metodo ogni volta che ne avevamo bisogno. Alla fine, DatabaseManager disponeva di oltre 100 metodi pubblici dall'autenticazione dell'utente allo smistamento delle posizioni dei siti archeologici.

La mia lezione nell'evitare la sporcizia e la rapidità fu quando avevo sei mesi per consegnare quello che era stimato (sottovalutato) per un anno di lavoro. Ho deciso di ricercare metodologie prima di iniziare il lavoro. Alla fine ho investito tre mesi di ricerca e sono stato in grado di consegnare nei restanti tre mesi.

Abbiamo ottenuto grandi vantaggi identificando le funzionalità comuni e creando le librerie necessarie per gestire tali requisiti. Vedo ancora programmatori che scrivono il proprio codice quando ci sono routine di libreria disponibili. Questi programmatori spesso riscrivono, o nella migliore delle ipotesi, lo stesso codice quando devono risolvere lo stesso problema in un secondo momento. Le correzioni di bug invariabilmente catturano solo alcune delle copie del codice.

Uno sviluppatore ha risposto in modo esplicito quando gli ho chiesto di usare il codice della biblioteca: "Non è un imbroglio? Ho dovuto scrivere tutto il mio codice a scuola".

In alcuni casi suppongo che potrebbe esserci una vasta gamma di test di regressione che troveranno "tutti" i bug e verificheranno il comportamento, consentendo in tal modo una tecnica di codifica rapida e sporca. Ma soprattutto è solo una questione di cattiva pianificazione del progetto e un manager che pensa che sia più importante farlo, piuttosto che farlo nel modo giusto.

E dimentica di "ripulirlo più tardi", che non succede mai. In rari casi, il programmatore avrà dimenticato la maggior parte del codice, rendendo il lavoro molto più costoso rispetto a se lo avesse fatto bene la prima volta.

Il prodotto viene spedito.

Il codice non esiste nel vuoto. Ho sofferto di indicibile dolore antincendio le conseguenze di una codifica rapida e sporca e da cowboy. Ma a volte finire il prodotto è la priorità, non capire come scrivere il codice migliore. In definitiva, se il prodotto viene spedito e funziona abbastanza bene, gli utenti e i clienti non sapranno o si preoccuperanno di quanto sia "cattivo" il codice all'interno, e ammetterò che ci sono stati momenti in cui non mi importava affatto di "ottenerlo giusto "fintanto che l'ho tirato fuori dalla porta.

Sì, questo in un problema organizzativo e "non dovrebbe mai accadere". Ma se ti capita di scrivere codice in un'organizzazione scarsamente gestita e fortemente orientata alle scadenze, a livello di singolo programmatore le opzioni sono limitate.

Non penso che possano onestamente dire di aver capito bene se non è facilmente gestibile. Se ammettono che devono "ripulirlo più tardi", allora c'è probabilmente qualcosa a cui non hanno pensato abbastanza. Testarlo a fondo scoprirà davvero qualsiasi problema con il codice sporco.

Personalmente non mirerei a sviluppare l'abilità di "scrivere codice sporco" ed essere fiducioso sulla sua correttezza. Preferirei scrivere il codice corretto la prima volta.

Come fanno a sapere di aver capito bene? Il test è la risposta semplice.

Se il loro codice è stato testato a fondo da un buon team di controllo qualità e passa, allora direi che hanno capito bene.

La scrittura di codice rapido e sporco non è qualcosa che dovrebbe essere fatto come un'abitudine, ma allo stesso tempo ci sono occasioni in cui puoi trascorrere 20 minuti a scrivere codice che può essere classificato come sporco o 4 ore di refactoring di un sacco di codice per farlo bene. Nel mondo degli affari a volte 20 minuti è tutto ciò che è disponibile per fare il lavoro e quando si affrontano scadenze veloci e sporche può essere l'unica opzione.

Sono stato su entrambi i fronti, ho dovuto correggere il codice sporco e ho dovuto scrivere il mio per aggirare i limiti di un sistema in cui stavo sviluppando. Direi che avevo fiducia nel codice ha scritto perché sebbene fosse sporco e un po 'un hack a volte mi sono assicurato che fosse accuratamente testato e aveva un sacco di gestione degli errori incorporata, quindi se qualcosa fosse andato storto non avrebbe distrutto il resto del sistema.

Quando guardiamo in basso a questi programmatori veloci e sporchi, dobbiamo ricordare una cosa, un cliente generalmente non paga fino a quando non ha il prodotto, se viene spedito e va in test UAT e trova i bug dal codice rapido e sporco è un molto meno probabilmente si tireranno fuori quando hanno un prodotto quasi funzionante davanti a loro, ma se non hanno nulla e stai dicendo loro "lo avremo presto stiamo solo aggiustando x" o "è stato ritardato perché dovevamo ottenere y funzionano perfettamente "hanno maggiori probabilità di arrendersi e andare con un concorrente.

Naturalmente, come dimostra questa immagine, nessuno dovrebbe sottovalutare il pericolo di codice rapido e sporco!

Non penso che dovresti nemmeno iniziare a percorrere quella strada. Veloce e sporco potrebbe darti il ​​vantaggio temporale di finire più velocemente, ma alla fine paghi sempre dieci volte per farlo.

A mio avviso, imparare a giudicare il codice di domande e risposte per correttezza non è un'abilità che vale la pena sviluppare perché è solo una cattiva pratica. Ecco perché:

Non credo che "veloce e sporco" e "best practice" vadano insieme. Molti programmatori (me compreso) hanno tirato fuori il codice rapido e sporco a causa di un disallineamento nei vincoli tripli . Quando dovevo farlo, di solito era il risultato di un creep di portata combinato con una scadenza che si avvicinava sempre di più. Conoscevo il codice che stavo controllando risucchiato, ma sputava uscite appropriate dato un set di input. Molto importante per i nostri stakeholder, abbiamo spedito in tempo.

Uno sguardo al Rapporto CHAOS originale chiarisce che Q&D non è una buona idea e ucciderà il budget in seguito (o in manutenzione o durante l'espansione). Imparare a giudicare se il codice di domande e risposte è corretto è una perdita di tempo. Come disse Peter Drucker, "Non c'è nulla di così inutile come fare in modo efficiente ciò che non dovrebbe essere fatto affatto".

Non so dire se il mio nuovo codice è corretto se è troppo sporco.

"Sporco" significa cose diverse per persone diverse. Per me, per lo più significa fare affidamento su cose che sai che probabilmente non dovresti fare affidamento, ma che sai anche che puoi aspettarti di lavorare a breve termine. Esempi: supponendo che un pulsante sia alto 20 pixel invece di calcolare l'altezza; hard coding di un indirizzo IP invece di risolvere un nome; contando su un array da ordinare perché sai che lo è, anche se il metodo che fornisce l'array non lo garantisce.

Il codice sporco è fragile - puoi provarlo e sapere che funziona ora , ma è una buona scommessa che si romperà ad un certo punto in futuro (oppure costringere tutti a camminare sui gusci d'uovo per paura di romperlo).

A rischio di sembrare un po 'controverso, direi che nessuno sa davvero che il loro codice è corretto al 100% e senza errori al 100%. Anche quando hai una copertura dei test davvero buona e stai applicando rigorosamente buone pratiche BDD / TDD, puoi comunque sviluppare codice che contiene errori e sì che può anche contenere effetti collaterali!

Scrivere semplicemente codice e supporre che funzioni implica un'eccessiva fiducia da parte dello sviluppatore delle proprie capacità dello sviluppatore e che quando sorgeranno problemi (che inevitabilmente faranno) lo sforzo di eseguire il debug e mantenere il codice sarà costoso, specialmente se è necessario un altro sviluppatore per mantenere il codice in seguito. La vera differenza è fatta applicando buone pratiche di ingegneria del software, che assicurano che tu possa avere la vera fiducia che il tuo codice probabilmente funzionerà per la maggior parte del tempo e che se riscontri un errore, è più probabile che sia più facile eseguire il debug e molto meno costoso da modificare e mantenere indipendentemente dalla persona che lavora su quel codice in seguito.

Il punto saliente è che un codice ben ponderato e ben testato consentirà ad ALTRI di avere fiducia nel tuo codice, che nella maggior parte dei casi è più importante della tua stessa fiducia.

Se il codice sporco è ben testato, ci si può fidare. Il problema è che l'unità che verifica il codice sporco è di solito molto difficile e ingombrante. Questo è il motivo per cui TDD è così buono; rivela e rimuove sporco e odori. Inoltre, i test unitari sono spesso la prima cosa a soffrire di tempo. Quindi, se il ragazzo più pulito avesse mai creato il codice più pulito che avesse mai fatto, non mi sarei mai fidato un po ', se avesse omesso i test unitari per motivi di tempo.

I bravi programmatori (Quick & Dirty e non) non hanno l'arroganza di presumere che abbiano capito bene. Partono dal presupposto che tutti i sistemi di grandi dimensioni presentano bug e difetti, ma che a un certo punto potrebbero essere sufficientemente testati e rivisti per avere un rischio sufficientemente basso o un costo di fallimento sufficientemente basso che il codice può essere spedito.

Allora perché esistono questi, cosiddetti programmatori Quick & Dirty? La mia ipotesi è la selezione darwiniana. I programmatori che spediscono velocemente il codice praticabile, occasionalmente spediscono prima che la concorrenza venga spedita, o il budget si esaurisca, o la società fallisca. Pertanto le loro società sono ancora in attività con nuovi programmatori per lamentarsi del disordine che deve essere ripulito. Anche le cosiddette navi a codice pulito, ma non sufficientemente differenziate per far estinguere i programmatori Quick & Dirty.

Si potrebbe probabilmente pensare che una parte non ottimale di un codice non possa fare alcuna differenza, a causa della breve durata, del piccolo impatto sul business o del poco tempo per farlo. La risposta corretta è che non lo sai davvero. Ogni volta che ascolto qualcuno che dice che "questa è una piccola funzionalità" o "rendiamolo il più veloce e semplice possibile" e dedichiamo un tempo insufficiente a pensare al design giusto, le uniche due cose che in realtà si verificano siamo:

1-) Il progetto diventa più grande e la motivazione della squadra diminuisce, lavorando su un codice pieno di "punti". In tal caso, il progetto sarà probabilmente su una corsia veloce verso il caos.

2-) Il progetto diventa noto per essere una soluzione non ottimale e il suo utilizzo inizia a essere scoraggiato, a favore di una nuova soluzione o di un refactoring che è costoso come una nuova soluzione.

Prova sempre a fare il miglior codice possibile. Se non hai abbastanza tempo, spiega perché hai bisogno di più. Non metterti a rischio con un lavoro mal fatto. Sii sempre un professionista migliore. Nessuno può punirti per questo se sei ragionevole. Se lo fanno, non è dove dovresti preoccuparti di lavorare.

Discutere con il senior e valutare l'eventuale impatto dei guasti. Ad esempio, una situazione in cui è possibile correggere lo sporco richiede 1 giorno e un codice robusto richiede modifiche alla progettazione e all'architettura che potrebbero richiedere 4-6 mesi + tempo di convalida aggiuntivo per convalidare completamente tutti i flussi di lavoro che sono stati interessati dalla modifica della progettazione.

Dobbiamo prendere una decisione basata anche su Tempo + Capacità + Priorità nell'elenco. Una buona discussione in squadra con gli anziani o le persone con esperienza più elevata può aiutare a prendere una decisione che si adatta meglio alla squadra e ai suoi risultati.

Il codice pulito è il primo e principale approccio in cui il codice sporco consente di salvare le escalation, le decisioni go / no go dei clienti, mostrare i tappi, la reputazione dell'organizzazione in gioco e molti altri in cui il codice sporco si trasforma in codice pulito.