Ossessionato dal trovare la soluzione più elegante [duplicato]

È compito tuo avere un codice sorgente ben scritto e refactored. Ci riesci, ed è grandioso.

È anche compito tuo consegnare in tempo. Se vuoi una motivazione a smettere di ossessionare la qualità del codice, che dire del fatto che se passi del tempo prezioso a fare cambiamenti sul codice che è già corretto, soddisfa i requisiti e funziona come previsto, non sarai in grado di soddisfare le scadenze per le altre funzionalità richieste, quindi non svolgere il lavoro per il quale sei pagato?

@bmused, conosco troppo bene il tuo dolore. Gran parte di questo per me deriva dallo straordinario codice WTF che ho avuto a che fare in vari posti. È professionalmente imbarazzante imbrogliare gli altri. Ci sono anche 2 volte che ricordo chiedendo alla squadra di rifiutare di permettere qualche codice nel sistema. Oh bene; alla fine la consegna supera la qualità anche se il codice viene riconosciuto come non valido . Il codice che tutti abbiamo a che fare lo dimostra.

Motivazioni

• Un buon scout lascia sempre il suo campeggio meglio di come l'ha trovato. Amen.
• È ancora meglio dell'horror esistente.
• Divertimento. Un buon design rende la codifica più semplice e divertente.
• Evitare il dolore, sia il sé che il capo inflitti. Ho semplicemente imparato a essere abbastanza buono. È stato difficile, e devo sempre stare attento a questo.
• Un "atteggiamento di miglioramento continuo" mi ha permesso di non preoccuparmi così tanto in anticipo.

Buono, premuroso, completo , design all'avanguardia è estremamente importante. Non cercare di essere troppo intelligente per il tuo (e nostro) bene. Non sto dicendo "elegante", "brillante", "realistica implementazione di caratteristiche linguistiche oscure", ecc. Sto dicendo completo, diretto, orientato agli oggetti. Combatti per il tempo necessario per creare un design decente prima della codifica.

Un buon design si presta naturalmente a codifiche "abbastanza buone" che ti permettono di dormire la notte. Codice completo (un gioco su un titolo di un libro) in modo da non preoccuparti di inventare posti per future estensioni. Ed essendo "completi" c'è meno voglia di continuare ad armeggiare con esso.

Ho avuto 2 esperienze molto diverse con la stessa base di codice. Il ben progettato più di qualsiasi altra classe di dominio aziendale completamente definita per soddisfare i requisiti; è stato criticato da PEBCAK OO-collaboratori ignoranti per "troppo", "troppo occupato" - ma codificato più facile e veloce ( potresti rimanere sorpreso di quanto tempo hai bisogno di miglioramenti durante la codifica! ), e navigato attraverso test in pochi giorni. Rispetto all'altro tempo in cui il design era incompetente nella migliore delle ipotesi e siamo rimasti bloccati in un ciclo infernale di prova e fallimenti di 3 mesi. Immagina come potresti provare a renderlo assolutamente perfetto la prossima volta, date queste due esperienze.

Il miglioramento continuo è un posto più felice. Ottieni il tuo nuovo codice abbastanza buono e le opportunità che si presentano migliorano.

• Il codice base di uno sta peggiorando o migliorando; miglioramento continuo o busto.
• Migliorare in seguito, di fronte a requisiti mutevoli conosciuti, o solo il tempo di pensarci, è molto preferibile pensare a ogni potenziale futuro in anticipo.
• Impedisce consapevolmente la sovraingegnerizzazione in previsione di cambiamenti che non arrivano mai: il mio punto debole è l'interfaccia implementata da una sola classe. Una cosa innocente che penseresti, ma la vedo troppe volte e IMHO in un grande code base ogni bit inutile e inutile è doloroso.

Buone pratiche di refactoring insieme a unit test è il modo per implementare il miglioramento continuo. Consiglio vivamente Refactoring di Martin Fowler.

C'è un merito nel lavorare su ciò che chiamiamo debito tecnico su base continuativa. Mantenere pulito il tuo codice mantiene il sistema agile e manutenibile. Ma devi trovare un equilibrio; Da un lato, non vuoi che la progettazione del sistema vada alla deriva così tanto che il software diventa non mantenibile, ma d'altra parte, non vuoi essere un "gold-plating" per un vantaggio marginale e mancare le scadenze.

Seth Godin lo dice in questo modo: il tuo compito è quello di spedire. Il modo in cui lo fai in tempo e in budget è, quando finisci i soldi o finisci il tempo, spedisci . Devi pianificare il tuo lavoro in modo da non rimanere senza.

Seth discute questo in modo più dettagliato nel suo Ted Talk, qui:
link

Sì, mi trovo di fronte a questo quando si progetta molto più che quando si sviluppa. Se non riesco a pensare ad una soluzione elegante tendo a spostarmi dove è possibile e lascia che il mio subconscio faccia il duro lavoro per me - questo evita di procrastinare.

Alla fine della giornata devi ricordare che vuoi finire il sistema (presumibilmente) e come tale devi solo dirti di andare oltre per raggiungere il tuo obiettivo finale.

Considera la quantità di tempo impiegata per risolvere il problema come uno dei costi che stai cercando di minimizzare. Non sarai in grado di ottimizzarlo perfettamente, quindi usa il tuo miglior giudizio.

Le soluzioni perfettamente eleganti che prendono troppo a lungo e le orribili bruttezze sono entrambe modalità di fallimento. Cerca di massimizzare l'eleganza per unità di tempo, non l'eleganza diretta.

Inoltre, c'è un buon principio chiamato YAGNI: non ne hai bisogno. Penso che sia un po 'overhyped, al punto che alcune persone pensano che sia una scusa per non pianificare mai per il futuro, ma il più delle volte, si applica. Se metti qualcosa nel tuo software che non viene mai usato, non è elegante, anche se sarebbe stata una buona soluzione per un problema che non si presentava mai.

Penso che troverai peggio è meglio per essere una buona lettura. È un tentativo di spiegare il fallimento delle macchine LISP agli hacker di LISP ei dettagli sono ormai storia antica, ma i dettagli non sono la parte importante.