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


37

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.


7
Buona domanda - Faccio sempre fatica con questo.
Nessuno

Risposte:


40

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

5
+1 - È abbastanza difficile risolvere i problemi che sappiamo di avere, senza anche cercare di risolvere i problemi che pensiamo di poter avere.
Jon Hopkins,

6
Mi piace questo, ma sarebbe utile una chiara definizione degli acronimi. Non ne avevo mai sentito parlare YAGNIfino ad oggi.
Philip Regan,

+1 per Filippo che impara qualcosa oggi! +1 anche per KISS.

Bene, la risposta è buona Sebbene ovviamente qualsiasi interfaccia (sia che si tratti di archiviazione permanente (file), rete o IPC) deve almeno essere versionabile o sai che la riprogettazione renderà impossibile la retrocompatibilità.
Deduplicatore

7

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.


6

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.


6

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.


5

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.


1
+1 Per esperienza ti fanno scendere a compromessi di più.
Amir Rezaei,

4

Il limite di tempo traccia questa linea piuttosto chiaramente.


1
Un buon punto, ma in futuro potrebbe essere necessario più tempo per risolvere una cattiva soluzione.
Amir Rezaei,

Penso che devi dare un giudizio su cosa sia il software "abbastanza buono". La linea dovrebbe essere definita dalle specifiche e dal tuo buon senso.
Nessuno

3

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.


Condivido con te il fastidio. Credo che la programmazione sia come un tipo di arte in cui non c'è perfezione.
Amir Rezaei,

2

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.)


0

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 .


Il perfezionismo non è possibile nemmeno dopo MOLTI anni di esperienza; vale a dire, se mai vuoi davvero CONSEGNA qualcosa. La cosa più preziosa che l'esperienza insegna è quando riconoscere "abbastanza buono".
Jeff Knecht,

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.