Il perfezionismo può essere buono e cattivo durante la programmazione.
Si prega di commentare se la domanda non è chiara.
KISS e YAGNI , in particolare YAGNI.
Progetta solo una soluzione per le cose che sai che avrai bisogno presto. Non programmarlo per le cose che potrebbero essere necessarie in due anni, perché molto probabilmente avrai bisogno di cose molto diverse e dovrai comunque riprogettarlo.
Nel momento in cui inizi a parlare di "con questo design in un certo momento del futuro potremmo fare X, o anche Y", invece di "questo design ci consente di fare il requisito Z del cliente nella prossima versione", quando tu stai entrando nell'astronomia dell'architettura.
In risposta ai commenti:
Utilizza un approccio iterativo e questo problema scompare. Il codice dovrebbe essere eseguito il primo giorno e quasi ogni giorno dopo. Soddisfa prima i requisiti minimi e aggiungi altro come hai tempo. Non abbandonare mai grandi cambiamenti in cui non puoi eseguire il codice per un lungo periodo.
Una soluzione è eccessiva quando i tempi supplementari necessari per completarlo valgono più del potenziale impatto negativo dal momento in cui la soluzione più semplice è terminata a quando sarà naturalmente aggiornato / modificato.
Fondamentalmente stai facendo trading ora con il tempo dopo. Se passi più tempo ora risparmierai più tardi, lo stai sbagliando. Se sei davvero sopra l'ingegneria, stai trascorrendo del tempo ora che non influisce sul tempo (o addirittura fa più) passi più tardi.
Migliora la tua esperienza di lavoro e più esperienza hai. Il modo migliore di fare le cose (dalla mia esperienza) è quello di fare ciò che ti serve ora, ma in un modo che è più facilmente accresciuto qualora i requisiti successivi lo richiedano. Elaborare come farlo è un po 'complicato.
Ero molto perfezionista (spendendo tempo a creare quadri, non soluzioni).
Ma la cosa che mi ha veramente aiutato ad accelerare la mia produzione è stata l'apprendimento e il rispetto dei principi BDD / TDD, incluso l'esterno in linea di principio (che ho trovato particolarmente difficile imparare ad abbracciare).
Questo mi ha veramente insegnato a non scrivere una sola riga di codice prima dell'esistenza di un test. Ma i test unitari non esistono prima che esista un test di accettazione per questo. E i test di accettazione derivano da reali esigenze degli utenti.
Quindi, tutte le righe di codice provengono da una reale necessità dell'utente.
Se non si ha familiarità con l'esterno in linea di principio, si impone di iniziare a scrivere test per il livello più esterno nell'applicazione (cioè la GUI in quasi tutti i casi) utilizzando i duplicati di prova per simulare il comportamento degli strati inferiori. Quindi implementa quel tanto che basta per far passare i test. Questa implementazione del livello superiore impone i test che devi scrivere per il livello successivo, ecc., Fino a raggiungere il livello inferiore dell'applicazione.
Ho notato che sto meglio con l'esperienza.
Quando ero (molto) giovane ho sempre optato per la soluzione più perfetta, senza compromessi. Ora sono più bravo a tenere a mente cose come budget e tempo.
Il limite di tempo disegna questa linea in modo abbastanza chiaro.
Il mio capo in realtà:)
Devo ammettere che sto migliorando, ma non ho ancora intenzione di scendere a compromessi. Per fortuna ho il mio capo per salvarmi;)
Mi piacerebbe sollevare un altro problema rispetto all'ingegneria, anche se la sovrastruttura è abbastanza facile da rilevare.
Il mio problema principale è con il refactoring. Il problema è che il più delle volte, anche se ho provato a scrivere il codice nel miglior modo possibile, non sapevo cosa avrei fatto adesso (visto più codici, più schemi, nuovi idiomi, nuovi problemi, nuovi soluzioni). E così, anche se funziona, ora conosco i modi migliori per farlo:
Tuttavia, funziona come è, e quindi refactoring non è una priorità, e la verità è che mi sta tormentando; Capisco le ragioni economiche e capisco le aspettative del cliente (non vedono il codice e preferiscono nuove funzionalità e correzioni di bug), ma mi piacerebbe 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 si intende risolvere e non crea nuovi problemi *, è molto probabile che il tempo di andare avanti. Quando impari ad impostare la barra più in alto che deve essere impostata, "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 provando.
(* - Si noti che "Buggy" e "Difficile da mantenere" sono entrambi fermamente sotto il titolo di "Nuovi problemi". Quindi non lo chiamo completo finché il codice non è stato testato, i bit superflui sono stati tagliati e ha aggiornato i commenti / la documentazione dell'API.)
Con l'esperienza mi sono reso conto che il perfezionismo non è nemmeno possibile finché non avrò almeno qualche anno di vita in un contesto particolare (linguaggio, struttura, piattaforma, standard). Come novizio, sarà di tutti i tipi di idiosincrasie di cui non sarai a conoscenza (escape, precedenza, parole riservate, zucchero sintattico, timeout, chiamate asincrone, caratteristiche non documentate e bug), quindi ho solo prova per una buona soluzione, imparando il più possibile. È importante sottolineare che cerco sempre di semplificare il refactoring del risultato: architettura modulare, commenti dove necessario e no astuti trucchi .
Io, come molti altri programmatori, ho un sacco di codice legacy da mantenere. La tentazione di rifare tutto sarà sempre lì, ma ho essenzialmente ridotto a un principio:
Am I (or someone else) going to have to figure this out again?
Di solito si prende cura di un sacco di codice spaghetti in un codice chunk spaghetti in qualche modo più gestibile. Estrarre alcuni dei pezzi, lanciare i test e ora non sembra così tanto bisogno di perfezione.
Leggi altre domande sui tag time-management methodology problem-solving decisions