Come scrivere un buon codice con nuove cose? [chiuso]

Finché esegui il refactoring lo stai facendo bene.

Considera questo: in qualsiasi momento puoi tracciare una soluzione al problema. Tuttavia, con il passare del tempo, stai scoprendo sempre di più il problema che ti porta a essere in grado di trovare soluzioni migliori. La prima iterazione potrebbe essere arretrata, e l'ultima è, si spera, elegante. Se mantieni il refactoring man mano che la tua conoscenza cresce, otterrai sempre risultati migliori. Non esiste una scorciatoia per passare subito alla soluzione più elegante senza passare attraverso i passaggi di "apprendimento" a meno che tu non abbia già riscontrato un problema simile, sia in grado di generalizzare da problemi passati o di essere fortunato.

I am curious to know how people deal with such agony, especially on big projects shared between many people ?

• Riconosci che esiste.
• Pianifica il tempo per la prototipazione.
• Cerca di imparare cose nuove in progetti di hobby piuttosto che in codice di produzione.

Bene, faccio TDD con i test unitari. L'intero mantra del TDD ruota attorno al seguente ciclo:

DatochestousandoTDD,sonocostrettoascriveretestunitari.Seuntestèdifficiledascrivere,èunsegnalecheilmiodesignètroppocomplicatoedeveesseresemplificato.

Ilciclononterminasenonsirefactoringperrimuoverelaridondanza,quindilamaggiorpartedeltemporefactoringèfattoinpiccolipezzienonèinterminiditempo.Inoltre,dopoognirefactoringeseguotuttiitestcaseperassicurarmidinonaverrottonulla.

fonteimmagine: link

Tutti imparano come scrivere un programma scrivendolo. Il refactoring è parte del processo, perché sei più qualificato a scriverlo la seconda volta. Il trucco non è cercare di evitare il refactoring, ma farlo prima e più frequentemente. Refactor non appena noti un problema, invece di aspettare fino alla "fine".

Una volta scritto e corretto il codice, mettilo da parte e scrivilo di nuovo in un modo diverso. Variare le strutture dati. O le strutture di controllo. Prova i disegni stravaganti. Ripetere. Spesso la struttura del codice più pulita non è immediatamente evidente e provando diverse appraoches potresti imbatterti in una soluzione migliore.

Ho rilevato dal mio studio che scrivo un codice più chiaro e semplice quando capisco completamente il dominio problematico. Purtroppo, i clienti spesso non riescono a chiarire esattamente ciò che vogliono e questa è una normale situazione lavorativa. Se hai frainteso il dominio, questo si rifletterà nel tuo codice. E se sei un capo progetto, uno dei tuoi compiti principali è quello di aiutare il cliente a ottenere una nuova visione della sua soluzione aziendale che vuole implementare. Quindi, cerca di dare più tempo per un'analisi del dominio e ti aiuta a scrivere un codice più semplice e chiaro.