Codice efficace e efficiente [chiuso]

I due estremi sono ugualmente cattivi: da un lato gli astronauti / accademici dell'architettura che non riescono nemmeno a guardare una classe senza definire due fabbriche e un modello strategico. Dall'altro i cosiddetti "programmatori di duct tape", spesso alimentati da almeno una parte dell'ignoranza, che si iscrivono a YAGNI ("Non ne avrai bisogno") fino all'estremo.

I buoni programmatori atterrano da qualche parte nel mezzo. Non sovrastano o complicano eccessivamente le cose, ma aggiungono una certa flessibilità ed eliminano ridondanze / dipendenze ove opportuno

Personalmente ho sempre stimato per corretto, preferirei quindi ritardare il rilascio del codice affrettato.

Il mio backup standard per tale affermazione è che non posso garantire la qualità o le prestazioni complessive se lo inganniamo e costerà al PM più mal di testa a lungo termine.

Da una prospettiva di sviluppo se non puoi afferrare il mio codice e sapere immediatamente che cosa sta facendo, allora è un problema. Se la struttura non ha senso per cominciare, è meno probabile che abbia senso quando hai finito.

Se il tuo cliente / azienda esegue revisioni di codice durante la fase di progetto / supporto, aiuta a costruire la certezza che tu sapevi cosa stavi facendo per iniziare.

Raggruppare le cose va bene per Proof of Concepts ma mai per qualcosa di produttivo degno.

Questa definizione di efficacia non tiene conto del costo finale di manutenzione, bug fixing, test e integrazione.

La codifica iniziale è MAI la parte più costosa di un progetto. Sembra la parte più costosa perché le persone sono molto cattive nel misurare il TCO. Il QA e le operazioni sono viste come inevitabili centri di costo e non viste come un risultato diretto dei processi di sviluppo (o della mancanza di processo).

Le persone che sviluppano il codice sono giudicate su quanto costa svilupparlo e non sui costi nel corso della vita del codice; ovviamente ottimizzano per la metrica con cui vengono giudicati.

Una volta ero seduto in ufficio fino alle 22:00, perché dovevo trovare la causa di un bug SUPER-URGENT. Si è scoperto che questo bug era causato da una soluzione rapida e sporca per un altro bug, che a sua volta era causato da un'altra correzione rapida e sporca per un altro bug, causato da un'altra correzione rapida e sporca a un altro bug (storia vera).

Conosco tutto questo perché ho dovuto rintracciare gli ultimi bug in questa catena magica (sfortunatamente non ero qui per correggerli effettivamente, e in entrambi i casi i miei manager preferivano correzioni rapide e sporche a quelle corrette quindi è possibile non mi permetterebbero di scrivere effettivamente un codice corretto).

La cosa divertente è che tutti i programmatori che sapevano qualcosa del bug originale (quello il cui fix rapido e sporco ha fatto tutti i problemi per cominciare) se ne andarono, e tutti erano così impauriti da rimuovere questo codice bacato, noi non poteva fare nulla MA fissando in modo rapido e sporco.

Questo risponde alla tua domanda?

Sono stato bruciato dagli sviluppatori che hanno fatto un rapido e amp; approccio sporco. Tutto spesso, ritorna come un bug che impiega il doppio del tempo per risolverlo, come avrebbe dovuto farlo correttamente la prima volta. Il poco tempo risparmiato sul fronte è quasi sempre ripreso molte volte più tardi.

Ho visto il termine debito tecnico gettato prima (purtroppo, non so da dove proviene). Penso che si applica bene qui. Riducendo i costi in anticipo, si sta solo ipotecando il tempo di sviluppo futuro.

Immagino che ti sia sbagliato in due modi. Il codice, che fa ciò che dovrebbe, è efficace, ma a che ora serve per eseguire.

Il codice efficiente è efficace e funziona bene. Il codice performante che produce risultati errati non è efficace, né efficiente.

La codifica efficiente è un'altra cosa. Sì, forse il tuo codice funziona bene, e giusto, ma richiede un costoso refactoring in poche settimane. Oppure trascorri ore e ore a guardare e sentire diversi, a cui nessuno importa. Non è una programmazione efficiente, ma il prodotto potrebbe funzionare in modo efficiente comunque.

Nella mia esperienza, veloce & sporco è un ossimoro per quanto riguarda il software. Quest'ultimo raramente porta al primo. Ho appena ridisegnato e reimplementato un modulo con 100.000 righe di codice. Mi ci è voluta una settimana e il risultato è di 4.000 linee. Il "progettista" originale mi ha probabilmente superato nelle righe di codice all'ora nei primi due giorni mentre stavo facendo più riflessioni che scrivere, ma non c'è modo che abbia finito in una settimana, e probabilmente non in un mese. Per non parlare di tutte le ore in più che il povero design ha creato durante la sua manutenzione.

Il codice "sporco" è solo più veloce il primo paio d'ore.

Nelle aree di math più tecniche che lavoro, il grosso problema, ottengo sempre le equivoci equazioni algebriche giuste. Un sacco di errori possono avere solo un piccolo impatto inaffidabile sul test dell'unità, e quindi possono passare inosservati. E il vero incubo è avere centinaia di linee di algebra densa, cioè "quasi" giuste, e dover capire dove si trova il difetto. L'ultima volta che ho avuto questo problema, ho riavviato da zero e non ho mai scoperto perché / dove l'implementazione originale era sbagliata.

La scorsa settimana ho avuto una discussione con uno sviluppatore, riempiendo una grande matrice con i numeri delle formule. Diverse pagine di codice ... Stava facendo questo modificando manualmente una soluzione esistente simile. Come sai che l'originale è giusto? Come sai che non stai introducendo errori impercettibili? Se quando risolvi il sistema risultante di equazioni e il risultato risulta evidentemente sbagliato, come puoi individuare il difetto? Stai usando una sorta di generatore di codice, per ridurre al minimo il numero di posti che l'errore umano può propagare in codice errato?

Sono noto per scrivere 300 righe di codice, che generano 100 righe di codice effettivo. Non perché fosse più facile, ma perché c'erano meno posti dove un sottile errore avrebbe prodotto un risultato leggermente sbagliato.

E poi c'è un modo rapido e sporco in termini di metodo di soluzione. L'algoritmo di ordine N al quadrato è braindead facile da scrivere e verificare, ma il metodo N logN è molto più complicato. Meglio iniziare con il metodo braindead e rifattorizzare nel metodo efficiente se / quando necessario -o almeno in un modo che ti permetta di usarlo per verificare la correttezza del metodo difficile ma efficace.

Dipende.

Durante il tempo di sviluppo pianificato, cerco di essere il più "efficiente" possibile. Ma se si tratta di un bug di produzione che deve essere corretto YESTERDAY, allora implementerò l'hack più veloce che non rompa altre funzionalità.

Succede anche quando i requisiti cambiano (come fanno sempre) in ritardo nel processo di sviluppo per un particolare progetto, e le nuove funzionalità richiedono un lavoro di rielaborazione più importante, ma possono essere eseguite "sporchi" senza troppi costi di sviluppo, abilitando la spedizione del progetto in anticipo.

Penso che la cosa importante da fare sia tornare indietro e modificare la progettazione per tenere conto di questa nuova "funzionalità" e correggerla correttamente una volta che la crisi è stata scongiurata o il prodotto è stato spedito. Se lo fai, gli hacker sporchi non si accumulano e causano altri problemi in futuro.

"Veloce e sporco" di solito significa implementare una nuova funzionalità duplicando e modificando l'implementazione di una funzionalità simile. Questo è quasi sempre più rapido rispetto alla scrittura di un test unitario per la nuova funzione, il refactoring del codice esistente per il riutilizzo e l'implementazione della nuova funzione. Almeno oggi è più veloce. Alla fine, la programmazione taglia e incolla risulta in un'applicazione che costa di più modificare rispetto al valore di qualsiasi nuova funzione. L'ho visto accadere con il sistema di ordinazione online di una grande compagnia telefonica. Aveva uno strato intermedio di circa 500.000 righe di C ++, tagliato e incollato fino alla nausea. Poteva gestire solo account con un massimo di 12 linee telefoniche. La direzione ha richiesto una stima del costo per modificare l'applicazione per gestire account aziendali di grandi dimensioni. Dopo cinque anni di programmazione "taglia e incolla", il limite di 12 righe è stato inserito nel programma in centinaia di punti. Dopo alcune settimane di riunioni di più ore, il team del software è tornato con una stima di oltre $ 10 milioni. La gestione non era felice. L'intero team è stato licenziato e l'applicazione è stata consegnata a un team offshore per una manutenzione minima.

La programmazione di taglia e incolla è come eseguire una compagnia di autobus e non cambiare mai l'olio del motore. Ogni giorno, è più veloce e meno costoso non cambiare l'olio. Alla fine il motore smette di funzionare. Quindi la compagnia assume un meccanico specializzato. Il meccanico dice che il motore ha bisogno di una revisione completa. La società risponde che non c'è tempo per questo, i clienti sono sul bus. Quindi l'azienda dice al meccanico di mettersi dietro l'autobus e di aiutare a spingere.

Devi essere molto nuovo allo sviluppo. Non c'è alcuna correlazione tra codice che non soddisfa gli standard e l'efficacia. Se puoi garantire che nessun altro sviluppatore dovrà mai capire - e tanto meno modificare - il tuo codice, allora puoi saltare le linee guida e scriverlo in uno 0 e un 1 per tutti quelli a cui tengo. Ma se hai torto e rimango bloccato con y