Come evitare soluzioni o progetti troppo complicati?[Chiuso]

Question

Molte volte ci troviamo a lavorare su un problema, solo per scoprire che la soluzione che si sta creando è molto più complessa di quanto richiesto dal problema.Esistono controlli, migliori pratiche, tecniche, ecc. che ti aiutano a controllare le complicazioni sul posto di lavoro?

Answer 1

Convincere qualcuno di nuovo a guardarlo.

Answer 2

Se è troppo difficile da testare, il tuo progetto è troppo complicato.Questa è la prima metrica che utilizzo.

Answer 3

Nella mia esperienza, progettare per un caso eccessivamente generale tende a generare troppa complessità.

La cultura ingegneristica incoraggia progetti che fanno meno ipotesi sull’ambiente;questa di solito è una buona cosa, ma alcune persone si spingono troppo oltre.Ad esempio, esso Potrebbe sarebbe carino se il design della tua auto non presupponesse una specifica attrazione gravitazionale, nessuno guiderebbe effettivamente la tua auto sulla luna, e se lo facessero, non funzionerebbe, perché non c'è ossigeno per far bruciare il carburante.

La parte difficile è che la persona che ha sviluppato il progetto "funziona su qualsiasi pianeta" è spesso considerata intelligente, quindi potresti dover lavorare di più per sostenere che il suo progetto è pure Intelligente.

Comprendere i compromessi, in modo da poter prendere una decisione tra ipotesi buone e ipotesi sbagliate, contribuirà notevolmente a evitare una progettazione inutilmente complicata.

Answer 4

Ecco alcune idee per semplificare la progettazione:

• leggere alcuni libri e articoli di programmazione, e poi fare domanda a inserirli nel tuo lavoro e scrivere il codice
• leggere un sacco di codice (buono e cattivo) scritto da altre persone (come i progetti Open Source) e imparare a vedere cosa funziona e cosa no
• costruire reti di sicurezza (test unitari) per consentire sperimentazioni con il codice
• utilizzare il controllo della versione per abilitare il rollback, se tali sperimentazioni prendono la direzione sbagliata
• TDD (sviluppo basato sui test) E BDD (sviluppo guidato dal comportamento)
• cambia il tuo atteggiamento, chiediti come puoi renderlo tale "funziona semplicemente" (la convenzione sulla configurazione potrebbe aiutare in questo caso;o chiedi come farebbe Apple)
• pratica (come i musicisti jazz - suona con il codice, prova Codice Kata)
• scrivere lo stesso codice più volte, con lingue diverse e dopo che è trascorso un po' di tempo
• impara nuove lingue con nuovi concetti (se usi un linguaggio statico, impara quello dinamico;se usi il linguaggio procedurale, impara quello funzionale;...) [una lingua all'anno è più o meno giusta]
• chiedi a qualcuno di rivedere il tuo codice e chiedi attivamente come puoi renderlo più semplice ed elegante (e poi realizzarlo)
• accumula anni facendo le cose migliori (il tempo aiuta la mente attiva)

Answer 5

Creo un disegno ecc., poi lo guardo e cerco di rimuovere (aggressivamente) tutto ciò che non sembra necessario.Se risulta che ne ho bisogno più tardi, quando sto lucidando il disegno, lo aggiungo di nuovo.Lo faccio in diverse iterazioni, perfezionando man mano che procedo.

Answer 6

Leggi "Lavorare in modo efficace con il codice legacy" di Michael C.Piume.

Il punto è che, se hai un codice che funziona e devi modificare la progettazione, niente funziona meglio che rendere testabile la tua unità di codice e suddividere il codice in parti più piccole.

Answer 7

Utilizzando il Test Driven Development e seguendo Robert C.Martino Tre regole del TDD:

1. Non è consentito scrivere alcun codice di produzione a meno che non sia necessario per superare un test unitario con esito negativo.
2. Non è consentito scrivere uno unit test più di quanto sia sufficiente per fallire;e gli errori di compilazione sono fallimenti.
3. Non è consentito scrivere più codice di produzione di quanto sia sufficiente per superare l'unico test unitario fallito.

In questo modo difficilmente otterrai molto codice che non ti serve.Sarai sempre concentrato sul far funzionare una cosa importante e non andrai mai troppo avanti rispetto a te stesso in termini di complessità.

Answer 8

Prova prima può aiutare qui, ma non è adatto a tutte le situazioni.E comunque non è una panacea.

Inizia in piccolo è un'altra grande idea.Hai davvero bisogno di inserire tutti e 10 i modelli di progettazione in questa cosa?Prova prima a farlo in "modo stupido".Non lo taglia del tutto?Ok, fallo in "un modo un po' meno stupido".Eccetera.

Fallo rivedere.Come ha scritto qualcun altro, due paia di occhi sono migliori.Ancora meglio sono due cervelli.Il tuo compagno potrebbe semplicemente vedere uno spazio per la semplificazione, o un'area problematica che pensavi andasse bene solo perché passi molte ore ad hackerarla.

Usa un linguaggio snello. Linguaggi come Java, o talvolta C++, a volte sembrano incoraggiare soluzioni sgradevoli e contorte.Le cose semplici tendono a estendersi su più righe di codice e devi solo utilizzare 3 librerie esterne e un grande framework per gestire il tutto.Considera l'utilizzo di Python, Ruby, ecc.- se non per il tuo progetto, quindi per uso privato.Può cambiare la tua mentalità favorire la semplicità e avere la certezza che la semplicità è possibile.

Answer 9

È inevitabile che ciò accada una volta che sei stato un programmatore.Se hai davvero sottovalutato lo sforzo o hai riscontrato un problema in cui la tua soluzione semplicemente non funziona, smetti di scrivere codice e parla con il tuo project manager.Mi piace sempre portare con me le soluzioni alla riunione, il problema è A, puoi fare x che richiederà 3 giorni oppure possiamo provare y che richiederà 6 giorni.Non fare la scelta da solo.

Answer 10

• Parla con altri programmatori in ogni fase del processo.Più occhi ci sono sul design, più è probabile che un aspetto troppo complicato venga rivelato presto, prima che diventi troppo ossificato nel codice base.
• Chiediti costantemente come utilizzerai ciò su cui stai attualmente lavorando.Se la risposta è che non sei sicuro, fermati a ripensare a quello che stai facendo.
• Ho trovato utile annotare pensieri su come potenzialmente semplificare qualcosa su cui sto attualmente lavorando.In questo modo, una volta che funziona davvero, è più facile tornare indietro e rifattorizzare o ripetere quanto necessario invece di scherzare con qualcosa che non è ancora nemmeno funzionale.

Answer 11

Questo è un delicato atto di equilibrio:da un lato non vuoi qualcosa che richieda troppo tempo per essere progettato e implementato, dall'altro non vuoi un hack che non sia abbastanza complicato da affrontare il problema della prossima settimana, o peggio ancora richieda una riscrittura per adattarsi .

Un paio di tecniche che trovo utili:

Se qualcosa sembra più complesso di quanto vorresti, non sederti mai per implementarlo non appena hai finito di pensarci.Trova qualcos'altro da fare per il resto della giornata.Molte volte finisco per pensare a una soluzione diversa per una prima parte del problema che rimuove gran parte della complessità in seguito.

Allo stesso modo, chiedi a qualcun altro da cui rimbalzare le idee.Assicurati di poter spiegare loro perché la complessità è giustificata!

Se stai aggiungendo complessità perché pensi che sarà giustificato in futuro, prova a stabilirlo Quando in futuro lo utilizzerai.Se non puoi (realisticamente) immaginare di aver bisogno della complessità per un anno o tre, probabilmente non è giustificabile pagarla adesso.

Answer 12

Riduci la quantità di dati con cui lavori serializzando l'attività in una serie di attività più piccole.La maggior parte delle persone può tenere in testa solo una mezza dozzina (più o meno) di condizioni durante la codifica, quindi rendila l'unità di implementazione.Progetta per tutte le attività che devi svolgere, ma poi modifica spietatamente il design in modo da non dover mai giocare con più di una mezza dozzina di percorsi attraverso il modulo.

Ciò segue dal post di Bendazo: semplifica finché non diventa facile.

Answer 13

Chiedo ai miei clienti Perché hanno bisogno di alcune funzionalità.Cerco di andare a fondo della loro richiesta e identificare il problema che stanno riscontrando.Questo spesso si presta a una soluzione più semplice di quanto io (o loro) penseremmo.

Naturalmente, se conosci le abitudini lavorative dei tuoi clienti e quali problemi devono affrontare, puoi capirli molto meglio fin dall'inizio.E se li "conosci", li conosci, allora capisci meglio il loro discorso.Quindi, sviluppa uno stretto rapporto di lavoro con i tuoi utenti.È il passo zero dell'ingegneria.

Answer 14

Prenditi del tempo per nominare bene i concetti del sistema e trova nomi correlati, questo rende il sistema più familiare.Non esitare a rinominare i concetti, migliore è la connessione con il mondo che conosci, meglio il tuo cervello potrà lavorarci.

Chiedi opinioni a persone che si entusiasmano per soluzioni pulite e semplici.

Implementa solo i concetti necessari per il progetto attuale (il desiderio di prove future o sistemi generici gonfiano il tuo progetto).