Dove traccia la linea per il tuo perfezionismo? [chiuso]

Il perfezionismo può essere positivo o negativo durante la programmazione.

• Quando e dove traccia la linea quando risolvi i problemi?
• Quando decidi quando una soluzione è eccessiva, troppo generale o semplicemente troppo futuristica?

Si prega di commentare se la domanda non è chiara.

KISS e YAGNI , in particolare YAGNI.

Crea una soluzione solo per le cose che sai che ti serviranno presto. Non progettarlo per le cose che potrebbero essere necessarie tra due anni, perché molto probabilmente avrai bisogno di cose molto diverse e dovrai riprogettarle comunque.

Nel momento in cui inizi a parlare di "con questo design ad un certo punto in futuro potremmo fare X, o anche Y", invece di "questo design ci consente di soddisfare il requisito Z del cliente nella prossima versione", ecco quando stai ottenendo nell'astronomia dell'architettura.

In risposta ai commenti:

• KISS = Keep It Simple, Stupid = fingi di essere un idiota e devi capire il design
• YAGNI = Non ne avrai bisogno = smetti di fingere di poter prevedere il futuro nel tuo design

Usa un approccio iterativo e questo problema scompare per lo più. Il codice dovrebbe essere eseguito il primo giorno e quasi ogni giorno successivo. Soddisfa prima i requisiti minimi e aggiungine altri man mano che hai tempo. Non abbandonare mai grandi cambiamenti in cui non è possibile eseguire il codice per molto tempo.

Una soluzione è eccessiva quando il tempo extra impiegato per completarla vale più del potenziale impatto negativo da quando la soluzione più semplice è finita a quando verrebbe successivamente aggiornato / modificato naturalmente.

Fondamentalmente stai scambiando tempo ora con tempo dopo. Se trascorri più tempo adesso, risparmierai più tardi, lo stai facendo male. Se sei davvero troppo ingegneristico, stai trascorrendo del tempo ora che non influisce su quanto tempo (o addirittura lo rende più) che spendi in seguito.

Migliorerai nel risolverlo, più esperienza avrai. Il modo migliore per affrontare le cose (in base alla mia esperienza) è quello di fare ciò di cui hai bisogno ora, ma in un modo che possa essere facilmente aumentato se i requisiti successivi lo richiedessero. Capire come farlo è un po 'complicato.

Ero molto perfezionista (passare il tempo a creare framework, non soluzioni).

Ma la cosa che mi ha davvero aiutato ad accelerare la mia produzione è stata l'apprendimento e il rispetto dei principi BDD / TDD, compreso l'esterno in linea di principio (che ho trovato particolarmente difficile da imparare ad abbracciare).

Questo mi ha davvero insegnato a non scrivere una singola riga di codice prima che esista un test. Ma i test unitari non esistono neanche prima che esista un test di accettazione. E i test di accettazione provengono da reali esigenze dell'utente.

Pertanto, tutte le righe di codice provengono da un'esigenza reale dell'utente.

Se in linea di principio non si ha familiarità con l'esterno, si impone di iniziare a scrivere test per il livello più esterno nell'applicazione (ovvero la GUI in quasi tutti i casi) utilizzando i test doppio per simulare il comportamento dei livelli inferiori. Quindi implementate quanto basta per il superamento dei test. Questa implementazione del livello superiore determina quindi i test che è necessario scrivere per il livello successivo, ecc., Fino a quando non si raggiunge il livello inferiore dell'applicazione.

Noto che sto migliorando per esperienza.

Quando ero (molto) giovane cercavo sempre la soluzione più perfetta, senza compromessi. Ora sono più bravo a tenere a mente cose come budget e tempo.

Il limite di tempo traccia questa linea piuttosto chiaramente.

Il mio capo effettivamente :)

Devo ammettere che sto migliorando, ma non sono ancora molto per il compromesso. Per fortuna ho il mio capo che mi ha aiutato;)

Vorrei tuttavia sollevare un altro problema rispetto all'ingegnerizzazione eccessiva, poiché l'eccessiva ingegnerizzazione è abbastanza facile da rilevare.

Il mio problema principale è con il refactoring. Il problema è che la maggior parte delle volte, anche se ho cercato di scrivere il codice il meglio possibile, non sapevo allora cosa so ora (visto più codici, più schemi, nuovi modi di dire, nuovi numeri, nuovo soluzioni). E così, anche se funziona, ora conosco modi migliori per farlo:

• Modi che potrebbero migliorare l'usabilità e ridurre le possibilità di ottenere un bug
• Modi che ridurrebbero le dipendenze, migliorando il tempo di compilazione

Tuttavia, funziona così com'è, e quindi il refactoring non è una priorità, e la verità è che mi tormenta; Comprendo le ragioni economiche e comprendo le aspettative del cliente (non vedono il codice e preferiscono nuove funzionalità e correzioni di bug), ma vorrei avere il tempo di lavorarci ancora.

Per ora, seguo semplicemente l'ordine del mio capo, ma devo ammettere che mi sento a disagio sapendo che il codice consegnato in produzione non è il migliore che potrei inventare ora. Perfezionismo, immagino.

Sia a livello professionale che personale, lo standard che cerco di applicare a me stesso è:

Sii contento di vincere.

Se il mio codice risolve il problema che dovrebbe risolvere e non crea nuovi problemi *, è molto probabile che sia il momento di andare avanti. Quando impari a impostare la barra su quanto deve essere impostato, "Abbastanza buono" diventa, beh, abbastanza buono.

La perfezione è come la velocità della luce: non ci arriverai mai, ma non c'è limite all'energia che puoi spendere per provare.

(* - Notare che "Buggy" e "Difficile da mantenere" rientrano entrambi saldamente sotto il titolo di "Nuovi problemi". Quindi non lo chiamo completo fino a quando il codice non è stato testato, se i bit superflui sono stati tagliati e i commenti / documentazione API aggiornati.)

Con l'esperienza mi sono reso conto che il perfezionismo non è nemmeno possibile fino a quando non avrò almeno qualche anno sotto la cintura in qualsiasi contesto particolare (linguaggio, struttura, piattaforma, standard). Come principiante ci saranno tutti i tipi di idiosincrasie di cui non sarai a conoscenza (fuga, precedenza, parole riservate, zucchero sintattico, timeout, chiamate asincrone, funzionalità e bug non documentati), quindi cerco solo una buona soluzione, tutti i mentre impari il più possibile. È importante sottolineare che cerco sempre di semplificare il refactoring del risultato: architettura modulare, commenti dove necessario e nessun trucco intelligente .

Come molti altri programmatori, ho un sacco di codice legacy da mantenere. La tentazione di rifare tutto sarà sempre lì, ma essenzialmente l'ho ridotta a un principio:

Devo (o qualcun altro) doverlo capire di nuovo ?

Questo di solito si occupa di un sacco di codice spaghetti in un codice spaghetti-chunk un po 'più gestibile. Estrarre alcuni dei pezzi, lanciare i test e ora non sembra tanto aver bisogno di perfezione.