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

Probabilmente il codice non è corretto.

Tuttavia, potrebbe non essere importante.

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

• Il codice ha una vita breve . Ad esempio, stai trasformando un gruppo 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 in esso contenuti possono essere facilmente corretti
  • L'utente finale è un programmatore comprensivo, che ragionerà sui messaggi di errore e lavorerà intorno a loro, ad esempio, massaggiando l'input.

A volte non è importante che il codice sia robusto e gestisca ogni input immaginabile. A volte basta gestire i dati noti che hai a disposizione.

In questa situazione, se i test unitari ti aiutano a far scrivere il codice più velocemente (questo è il mio caso), allora usali. Altrimenti, codice veloce e sporco, portare a termine il lavoro. I bug che non si attivano non contano. I bug che risolvi o ti aggirano al volo non contano.

Ciò che è assolutamente vitale è che non si diagnostichino erroneamente queste situazioni. Se si codifica il quick-and-dirty perché il codice verrà utilizzato una sola volta, quindi qualcuno decide di riutilizzare il codice in un progetto che merita un codice migliore, quel codice meritava più attenzione.

Non lo fanno. Attualmente sto lavorando su una base di codice creata da programmatori "veloci e sporchi" che "ripulirebbero più tardi". Sono finiti da tempo e il codice continua a vivere, cigolando verso l'oblio. I codificatori dei cowboy , in generale, semplicemente non comprendono tutte le possibili modalità di errore che il loro software potrebbe avere e don ' t comprendere i rischi a cui espongono la società (e i clienti).

Okay, correndo il rischio di essere completamente prosciugato, vado a "difendere i diavoli" la visione opposta.

Propongo che noi sviluppatori abbiamo la tendenza ad essere eccessivamente preoccupati per cose come la pratica corretta e la pulizia del codice. Suggerisco che, mentre quelle cose sono importanti, non importa se non spedite mai .

Chiunque sia stato in questo business un po 'probabilmente sarebbe d'accordo sul fatto che sarebbe possibile giocare con un software più o meno indefinitamente. Duke Nukem Forever, amici miei. Arriva un momento in cui quella caratteristica piacevole o quel lavoro di refactoring così urgente dovrebbero essere messi da parte e la cosa dovrebbe essere chiamata FATTO.

Ho combattuto i miei colleghi su questo 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, il bello deve essere abbastanza buono. Nessun software di spedizione reale, reale, è perfetto. Nessuna. Al massimo, è abbastanza buono.

Questi programmatori quasi mai conoscono hanno capito bene, solo credono così. E la differenza potrebbe non essere facile da percepire.

Ricordo come ho programmato prima di apprendere i test unitari. E ricordo quella sensazione di fiducia e fiducia su un livello completamente diverso dopo che ho eseguito la mia prima suite di test unitari decenti. Non avevo mai conosciuto un tale livello di sicurezza nel mio codice prima d'ora.

Per qualcuno a cui manca questa esperienza, è impossibile spiegare la differenza. Quindi possono anche continuare a svilupparsi in modalità code-and-pray per tutta la loro vita, benevolmente (e ignoranti) credendo che stiano facendo del loro meglio considerando le circostanze.

Detto questo, ci possono essere dei grandi programmatori e casi eccezionali, quando uno riesce davvero a tenere tutto lo spazio problematico nella sua mente, in uno stato di flusso completo. Ho vissuto momenti rari come questo, quando sapevo perfettamente cosa scrivere, il codice mi è appena sfuggito senza sforzo, potevo prevedere tutti i casi speciali e le condizioni al contorno, e il codice risultante ha appena funzionato . Non ho dubbi che ci siano dei geni di programmazione là fuori che possono rimanere in tale stato di flusso per lunghi periodi o anche la maggior parte del loro tempo, e ciò che producono è un codice bellissimo, apparentemente senza sforzo. Immagino che tali persone non sentano il bisogno di scrivere dei test unitari per verificare cosa già conoscono . E se sei davvero un genio, potrebbe essere OK (anche se anche così, non sarai per sempre intorno a quel progetto, e dovresti pensare ai tuoi successori ...). Ma se non ...

E diciamocelo, è probabile che tu non lo sia. Io, per me stesso, so che non lo sono. Ho avuto alcuni rari momenti di flusso - e innumerevoli ore di dolore e dolore, di solito causati 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 del passato, quindi hanno consapevolmente sviluppato l'abitudine di ricontrollare le proprie assunzioni e scrivere quei piccoli test unitari, per tenersi 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).

Nota a margine;

short cuts make for long delays (Pippin)

È bello imparare ad accettare che nessun sistema software di una ragionevole complessità sarà perfetto, indipendentemente da quanto siano stati testati e testati il codice dell'unità. Un certo grado di caos e vulnerabilità agli imprevisti sarà sempre in agguato all'interno del codice. Ciò non significa che non si debba cercare di produrre codice valido o condurre test unitari. Questi sono, ovviamente, importanti. C'è un equilibrio che deve essere cercato e questo varierà da progetto a progetto.

L'abilità da sviluppare è la comprensione di quale livello di "perfezione" deve essere usato per un particolare progetto. Ad esempio, se stai scrivendo un'applicazione di cartelle cliniche elettroniche con una cronologia di progetto di 12 mesi, ti consigliamo di dedicare molto più tempo per i test e assicurarti che il tuo codice sia gestibile rispetto a quello che avresti per una singola app web di registrazione della conferenza che deve essere distribuito entro venerdì. I problemi arrivano quando qualcuno che esegue l'app EMR diventa sciatto o l'app di registrazione non viene distribuita in tempo perché il programmatore è troppo impegnato nel tweaking del codice.

Veloce e sporco è perfettamente adatto all'interno di un sottosistema . Se hai un'interfaccia ben definita tra la tua schifezza e il resto del sistema, e una buona serie di test unitari che ti confermano che il tuo brutto codice veloce e sporco fa la cosa giusta, potrebbe andar bene.

Ad esempio, potresti avere qualche orribile hack di espressioni regolari e offset di byte per analizzare alcuni file provenienti da terze parti. Supponiamo che tu abbia un test che dice che il risultato ottenuto dall'analisi dei file di esempio è quello che ti aspetti. Potresti pulire questo in modo che tu possa ... Non so, reagire più velocemente quando una terza parte cambia un formato di file? Questo non succede abbastanza spesso. Più probabilmente passeranno a un'API completamente nuova e getterai via il vecchio parser e ne inserirai uno nuovo conforme alla stessa API, e voilà, hai finito.

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

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

Ho conosciuto una persona che considera i test unitari una perdita di tempo. Dopo molte discussioni, ne ha finalmente scritto uno. Consisteva in un lungo metodo cosparso di & & e || e ha restituito un valore booleano per asserire 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 cima "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. Un po 'più tardi ho parlato con lui di nuovo, e si è scoperto che il suo compagno di squadra ha cambiato il valore di un letterale e non l'ha aggiornato altrove. Non era una costante. Così ha cambiato anche gli altri letterali in modo che il suo bug fosse risolto. Si è lamentato del codice spaghetti del suo compagno di squadra. Mi ha detto 'Haha, non sappiamo tutti cosa vuol dire stare svegli tutta la notte con il debugger, non dormire mai per un brutto baco'. Pensa che questo è qualcosa che i programmatori fanno davvero bene e in effetti si sente bene.

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

Eccone altri.

Un'altra volta stavamo scrivendo una classe DatabaseManager per la nostra app web. Ha messo tutte le chiamate al database in esso. 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 sapere su ogni metodo di database. Era in disaccordo, perché era "facile" avere una sola classe per l'intero database ed era "veloce" aggiungere un nuovo metodo ogni volta che ne avevamo bisogno. Alla fine, DatabaseManager aveva oltre 100 metodi pubblici di autenticare l'utente per ordinare le posizioni dei siti archeologici.

La lezione che ho avuto di evitare in modo rapido e sporco è stata quando avevo sei mesi per consegnare quello che era stimato (sottovalutato) per il valore di 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 funzionalità comuni e costruendo le librerie richieste per gestire tali requisiti. Continuo a vedere i programmatori che scrivono il proprio codice quando ci sono routine di libreria disponibili. Questi codificatori spesso riscrivono, o meglio tagliano e incollano, lo stesso codice quando devono risolvere lo stesso problema in seguito. I bug risolti invariabilmente catturano solo alcune delle copie del codice.

Uno sviluppatore ha dato una risposta significativa quando gli ho chiesto di usare il codice della libreria: "Non è questo l'inganno? Ho dovuto scrivere tutto il mio codice a scuola."

In alcuni casi, suppongo che ci possa essere una vasta serie di test di regressione che troveranno bug "tutti" e verificheranno il comportamento, consentendo quindi una tecnica di codifica rapida e sporca. Ma soprattutto è solo una questione di cattiva pianificazione del progetto e un manager che pensa sia più importante farlo, piuttosto che farlo funzionare correttamente.

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

Il prodotto viene spedito.

Il codice non esiste nel vuoto. Ho sofferto indicibili sofferenze a causa di attacchi di fuoco per le conseguenze della codifica rapida, 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 né si preoccuperanno di quanto sia "cattivo" il codice all'interno, e ammetterò che ci sono state volte in cui non mi importava affatto di averlo giusto "finché ho tirato fuori la 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 pesantemente basata sulla scadenza, a livello di programmatore individuale le tue opzioni sono limitate.

Non penso che possano dire onestamente di averlo capito bene se non è facilmente mantenibile. Se ammettono di dover "ripulirlo più tardi", allora probabilmente c'è qualcosa che non hanno pensato abbastanza. Provarlo accuratamente scoprirà solo alcuni problemi con il codice sporco.

Personalmente non mirerei a sviluppare l'abilità di "scrivere codice sporco" e di essere fiducioso sulla sua correttezza. Preferisco scrivere 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 QA e passa, allora direi che hanno capito bene.

Scrivere codice veloce e sporco non è qualcosa che dovrebbe essere fatto come un'abitudine, ma allo stesso tempo ci sono occasioni in cui puoi spendere 20 minuti per scrivere codice che può essere classificato come sporco o 4 ore per refactoring un sacco di codice da fare giusto Nel mondo degli affari a volte 20 minuti è tutto ciò che è disponibile per fare il lavoro e quando affronti le scadenze rapidamente e sporco può essere l'unica opzione.

Sono stato a entrambi i lati di questo, ho dovuto risolvere il codice sporco e ho dovuto scrivere il mio per aggirare i limiti di un sistema che stavo sviluppando. Direi di avere fiducia in il codice che ho scritto perché sebbene fosse sporco e un po 'un trucco a volte mi sono assicurato che fosse stato accuratamente testato e che avesse un sacco di errori nella gestione degli errori, quindi se qualcosa fosse andato storto non avrebbe distrutto il resto del sistema.

Quando guardiamo questi programmatori veloci e sporchi, abbiamo bisogno di ricordare una cosa, un cliente in genere non paga finché non ha il prodotto, se viene spedito e partecipa ai test UAT e trova i bug dal codice veloce e sporco è molto meno probabile che si ritirino quando hanno un prodotto quasi funzionante di fronte a loro, ma se non hanno nulla e tu gli stai dicendo "lo avrai presto lo stiamo aggiustando x" o "è stato ritardato perché noi dovevo lavorare perfettamente "sono più propensi a rinunciare e andare con un concorrente.

Naturalmente, poiché questa immagine dimostra che nessuno dovrebbe sottovalutare il pericolo di un codice veloce e sporco!

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

I can't tell if my new code is correct if it's too dirty.

"Sporco" significa cose diverse per persone diverse. Per me, significa soprattutto affidarsi a cose che sai che probabilmente non dovresti fare affidamento, ma che sai anche che puoi aspettarti di lavorare nel breve termine. Esempi: supponendo che un pulsante sia alto 20 pixel invece di calcolare l'altezza; hard codifica 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 testarlo e sapere che funziona ora , ma è una buona scommessa che si romperà in qualche punto in futuro (o costringerà tutti a camminare su gusci d'uovo per paura di romperlo).

A rischio di sembrare un po 'controverso, direi che nessuno veramente SAI che il loro codice sia corretto al 100% e 100% senza errori. Anche quando hai una buona copertura di test e applichi rigorosamente le buone pratiche BDD / TDD, puoi ancora sviluppare codice contenente errori e sì che può persino contenere effetti collaterali!

Basta scrivere il codice e supponendo che funzioni implica una sicurezza eccessiva da parte dello sviluppatore riguardo alle proprie abilità dello sviluppatore e che quando sorgono problemi (che inevitabilmente lo faranno) lo sforzo di eseguire il debug e mantenere il codice sarà costoso, specialmente se un altro sviluppatore deve mantenere il codice in seguito. La vera differenza si ottiene applicando buone pratiche di ingegneria del software, che assicurano che si possa avere la certezza che il codice funzioni probabilmente la maggior parte del tempo e che se si verifica un errore, è più probabile che sia più facile eseguire il debug e molto meno costoso da cambiare e mantenere indipendentemente dalla persona che lavora su quel codice in seguito.

Il punto saliente è che il codice ben elaborato e ben testato permetterà a OTHERS di avere fiducia nel tuo codice, che nella maggior parte dei casi è più importante della tua fiducia.

Se il codice sporco è ben testato, può essere considerato affidabile. Il problema è che l'unità che sta testando il codice sporco è di solito molto difficile ed ingombrante. Questo è il motivo per cui TDD è così buono; rivela e rimuove lo sporco e gli odori. Inoltre, i test unitari sono spesso la prima cosa a soffrire per il tempo. Quindi, se il ragazzo più pulito avesse mai realizzato il codice più pulito che avesse mai fatto, non mi sarei mai fidato un po ', se avesse omesso i test unitari a causa del tempo a rassicurarlo.

I bravi programmatori (Quick & Dirty e altro) non hanno la hybris per ritenere di aver capito bene. Assumono che tutti i sistemi di grandi dimensioni abbiano difetti e difetti, ma che a un certo punto potrebbero essere sufficientemente testati e rivisti per avere un rischio sufficientemente basso o un costo di errore sufficientemente basso che il codice può fornire.

Quindi perché questi, detti Quick & Sporchi, programmatori, esistono? La mia ipotesi è la selezione darwiniana. I programmatori che spediscono il codice lavorabile velocemente, di tanto in tanto vengono spediti prima della competizione, o il budget si esaurisce, o la compagnia va in bancarotta. Pertanto le loro aziende sono ancora in attività impiegando nuovi programmatori per lamentarsi del caos che deve essere ripulito. Anche il cosiddetto codice pulito viene spedito, ma non differentemente abbastanza bene da guidare Quick & Coder sporchi in via di estinzione.

Probabilmente si potrebbe pensare che una parte non ottimale di un codice non possa fare alcuna differenza, a causa della breve durata, dell'impatto sul business o del poco tempo per farlo. La risposta corretta è che non lo sai davvero. Ogni volta che ascolto qualcuno che dice "questa è una piccola caratteristica", o "rendiamola il più veloce e semplice possibile" e dedica tempo insufficiente a pensare al giusto design, le uniche due cose che effettivamente accadono sono:

1-) Il progetto diventa più grande e la motivazione del team è più bassa, lavorando su codice pieno di "punti". In quel caso il progetto sarà probabile verso una corsia veloce verso il caos.

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

Cerca sempre di fare il miglior codice possibile. Se non hai abbastanza tempo, spiega perché ne 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 è il posto in cui dovresti lavorare.

Discutere con gli anziani e valutare l'impatto dei fallimenti, se del caso. Ad esempio, una situazione in cui è possibile correggere lo sporco richiede 1 giorno e un codice robusto richiede modifiche di progettazione e 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 del progetto.

Dobbiamo prendere una decisione basata su Tempo + Capacità + Priorità nell'elenco. Una buona discussione nella squadra con anziani o persone con una maggiore esperienza può aiutare ad atterrare su una decisione che meglio si adatta al team e al suo risultato.

Il clean code è il primo e più importante approccio in cui il codice è sporco per salvare le escalation, prendere / non prendere le decisioni dei clienti, mostrare i fermi, la reputazione dell'organizzazione sul rogo e molti altri dove il codice sporco lo fa in modo pulito codice.