Qualità vs tempo

Il problema con l'over-engineering è che, proprio come con le ottimizzazioni, gli sviluppatori tendono a sovra-ingegnerizzare pezzi completamente irrilevanti. E quelli di solito non saranno mai toccati attraverso 10 revisioni del prodotto.

Anche se i requisiti aziendali cambiano, la soluzione sovra-ingegnerizzata richiede comunque un ulteriore engineering.

Quindi hai davvero bisogno di trovare un equilibrio per scrivere codice estensibile, stabile e leggibile. Sforzarsi di implementare tutto ciò che hai mai letto nei libri è, IMHO, pessimo.

È qui che entra in gioco la fase di pianificazione architettonica. Trova gli oggetti principali, trova le relazioni principali, individua le probabili modifiche del business nel prossimo futuro e progetta uno scheletro estensibile da quello che hai trovato.

È una bugia. Il codice Rushing rende il codice errato, che impedisce il progresso di tutti coloro che cercano di lavorare con esso e aumenta la possibilità di bug.

Cerchiamo di mantenere il codice pulito, specialmente quello che ti fa guadagnare denaro o quello che ti costa. I recenti lavori su "churn" e "heat map" ci mostrano che una piccola parte del nostro codice è altamente volatile, una differenza più severa di quanto la regola 80/20 avrebbe previsto.

Conoscere, pulire, migliorare il codice. Non dorarlo. Non sovrastimolarlo. Usa le regole del design semplice: 1) passa tutti i test, 2) nessuna duplicazione, 3) esprime chiaramente l'intenzione, 4) non ha parti superflue.

Guarda le virtù del codice: link

Queste sono alcune linee guida vaghe, ma questa non è una scienza esatta:

1. Se dici a te stesso, "Spero di non dover mai più rivedere quel codice." Fissalo al punto che è tollerabile.
2. Fai attenzione al desiderio di dedicare tempo alle cose che ti piacciono per evitare quelle che non ti piacciono. Lo farai.
3. Scopri cosa è importante per l'utente. A loro non dispiace preoccuparsi di caricare un modulo di grandi dimensioni se possono inserire dati più velocemente. Anche se l'attività complessiva richiede la stessa quantità di tempo, si tratta di percezione non logica.
4. Seguire le migliori pratiche non significa sempre che richiedono più tempo. Quando stabilisci buone abitudini, acquisisci scioltezza.
5. Se sei ossessionato dal punto di non fare nulla, ottieni aiuto.

Tempo e qualità sono per lo più ortogonali. Certamente, si ottiene una qualità scadente se si corre attraverso un'implementazione e una qualità migliore se si ha tutto il tempo necessario per l'implementazione, il test e la lucidatura. Ma trascorrere solo molto tempo non garantisce una buona qualità e ottenere rapidamente un compito non significa necessariamente che sia stato affrettato o che la soluzione sia di scarsa qualità.

La cosa che collega tempo e qualità è complessità . Generalmente, più un sistema è complesso più tempo è necessario per implementare, più difficile è verificare e più alto è il suo tasso di difetti. Le soluzioni più semplici sono più facili da capire, più veloci e facili da implementare correttamente, con probabilità di avere un tasso inferiore di difetti (ad esempio, una maggiore qualità). La soluzione semplice non è sempre quella ovvia; spesso è necessario più tempo per creare un design più semplice, ma di solito questo tempo è ben speso e paga i dividendi in termini di tempo di sviluppo e qualità.

Uno dei nostri ingegneri al lavoro è un aderente abbastanza strong al principio 80/20 . Se riesci a ottenere l'80% del vantaggio per circa il 20% dello sforzo, è importante fermarti e pensare se stai acquisendo qualcosa che desideri davvero spendendo più tempo e impegno.

Cioè, non dovresti scendere a compromessi su qualcosa di importante, ma per elementi più generali, otterrai gran parte dei benefici senza andare fino in fondo, inseguendo i dettagli.

La mia esperienza mi dice anche che il modo in cui un progetto software va, quanta confusione è, e quanta revisione ha bisogno dopo aver raggiunto la scadenza per convertirla in qualcosa di più gestibile è una funzione dell'esperienza.

Man mano che acquisisci più esperienza come sviluppatore (a patto che tu stia lavorando per migliorare), i progetti si integrano naturalmente con meno sforzo.

Un altro modo di dirlo, una buona soluzione oggi batte la soluzione perfetta domani (con l'addendum che domani non arriverà mai: -)

La mia regola: QUALITÀ PRIMA DI QUANTITÀ O TEMPO!

Perché? Perché odio quando le persone mi mostrano codice disordinato che non ha commenti. Se qualcuno ti da 2 settimane per portare a termine il lavoro, prendi due settimane. Non c'è fretta.

Non è difficile bilanciare tempo e qualità. Soprattutto se usi sempre le Best Practices e sei abituato ad avere una buona qualità. Ecco la mia regola per la qualità:

Durante la scrittura di un programma, digita come se il ragazzo che lo manterrà riceverà una motosega su di te se c'è qualcosa che non capisce! : -)

Mi sembra che meno tempo hai per la codifica, è probabile che ci siano ancora più preoccupanti tagli nei tempi dei test, che quasi sicuramente avranno un impatto sulla qualità.

Inoltre, se sei a corto di tempo, la tua migliore scommessa per ottenere un buon codice pulito (per quanto possibile) è in a) avere requisiti chiari, chiari e non ambigui e una base di codice che sia già abbastanza pulita che la disciplina è già in atto. Sfortunatamente, esistono pochissimi mondi ideali.

Per me è abbastanza vero. C'è una quantità di tempo richiesta da un'attività prima della sua chiamata completa. Se si spendeva meno del tempo assegnato, allora tende ad essere troppo poco ingegnerizzato, se si spendeva di più sarebbe stato sovradimensionato. È una matematica molto complicata trovare la soglia esatta. Quindi un manager in realtà non può quasi mai sapere se era sovradimensionato o meno.

Riguardo all'ingegneria, credo che un manager possa dare l'aspettativa su cosa si può fare su un tecnico. Assegnerei priorità molto alta a coprire quasi ogni singola riga di codice con i casi di test. Ciò significa che per ogni riga di codice scritta lo sviluppatore deve dedicare 4-10 volte tanto tempo a scrivere solo casi di test. Questo alla fine aumenterà la qualità del prodotto. Se hai degli sviluppatori davvero bravi, supereranno l'ingegnere nonostante questo.

Inoltre, non considero che un po 'di ingegneria è una perdita di tempo

• Uno sviluppatore che sovra ingegneri svolge spesso il compito con molto interesse.
• Dà un po 'di soddisfazione allo sviluppatore, quindi è probabile che rimanga più a lungo con la società
• Uno sviluppatore a lungo termine deve imparare ad allineare la sua ingegneria eccessiva con quella del business (poiché a nessuno piace scrivere un codice che nessuno vuole usare).
• Il codice più elaborato rispetto a un codice ingegnerizzato è migliore di un codice settimanale che richiede una visita al dipartimento bug fix ogni settimana.
• L'ingegnerizzazione sovente consente spesso agli sviluppatori di esprimere i loro concetti appena appresi, quindi fondamentalmente insegnerà all'intero team ciò che ha appreso attraverso il codice.
• Consentire agli sviluppatori di sovrastare gli ingegneri ti dà il vero potere di chiedere loro di sviluppare rapidamente alcune cose. Considereranno questa una richiesta seria.

Alla fine si riduce a ciò che sta facendo la tua azienda. Se un'azienda utilizza il proprio codice, non è un problema di questo tipo, ma se si tratta di un'azienda che sta sviluppando per conto di altri a $ / ora, allora si potrebbe voler impostare le proprie priorità con la società pagatrice.

Modifica: La mia idea di sovra-ingegneria sembra essere che lo sviluppatore impieghi più tempo con il codice di quanto effettivamente necessario dopo averlo completato nel modo più semplice possibile che crede possa essere fatto.