Limita la complessità inutile nel codice [duplicato]

Bene, nel tuo esempio hai già fornito l'unica soluzione che funziona davvero: chiedi a qualcun altro di rivedere il tuo codice .

Per limitare la complessità inutile di prima mano, hai bisogno di esperienza che passi per anni imparando, imparando, imparando. Non esiste un "proiettile d'argento".

Un paio di principi per aiutare lungo la strada:

• YAGNI - Non ne hai bisogno : non costruire cose che non ho bisogno Il che ci porta a:
• KISS - Keep It Simple, Stupid : le soluzioni più semplici sono spesso le migliori.
• DRY - Non ripetere te stesso : il codice duplicato spesso si occupa di una varietà di problemi . Come faresti per normalizzare un DB, dovresti normalizzare il tuo codice.
• Separazione dei dubbi / Modularità / SRP . Mantieni le cose focalizzate, semplici. Questo li rende riutilizzabili e comprensibili. Questo vale doppiamente per funzioni / metodi, che diventano esponenzialmente più difficili da eseguire (in modo completo) durante il debug (maggiori informazioni: complessità ciclomatica ).
• Principio di astensione - le persone non dovrebbero essere sorprese dal tuo codice. Dovrebbe fare ciò che afferma di fare (ad es. Se i getter stanno impostando le cose o hanno effetti collaterali importanti, probabilmente stai facendo qualcosa di sbagliato, un'eccezione potrebbe essere un caricamento lento).

Ricorda che il codice è pensato per essere letto dalle persone, non solo dal compilatore. Assicurati che il tuo codice si spieghi avendo nomi chiari per tutto. Se qualcosa è sorprendente, lascia dei commenti per spiegare l'intenzione / perché funziona così, non quello che fa. Un buon libro da leggere su questo argomento potrebbe essere Pulisci codice .

Sono anche un grande fan del perfezionamento delle soluzioni in modo iterativo. Immagino che tu possa chiamarlo refactoring , eccetto che spesso è privo dell'elemento TDD, e talvolta comporta cambiamenti importanti piuttosto che piccoli.

Penso che il valore delle pratiche e dei principi di cui sopra si uniscano veramente quando vengono applicati tutti; le cose diventano brevi, semplici, ovvie.

Ecco alcuni modi:

1. Scegli il livello di complessità corretto. La funzionalità richiesta determina il livello minimo di complessità e la soluzione dovrebbe utilizzare tale livello. Troppo complesso e hai bisogno di gestirne troppo, troppo semplice e non puoi soddisfare il requisito.
2. Non puoi prevedere il futuro. Alcune persone pensano di dover scegliere una versione più complessa semplicemente per consentire di soddisfare alcuni requisiti futuri arbitrari. Questa è una cattiva idea. Arbitrario significa che tutto è possibile. L'unica cosa che la tua soluzione complessa può fare è renderla più complicata. Non può risolvere alcun problema, dal momento che non hai abbastanza dettagli sul problema.
3. I dettagli sono il re. I requisiti complessi richiedono che tutti i dettagli siano corretti. Non è complesso se i dettagli più piccoli non sono importanti. Segui la struttura dei requisiti in modo accurato e funzionerà.