Sembra un sacco di volte su StackOverflow, che le persone (specialmente i programmatori) tendono a complicare eccessivamente una soluzione a un problema in cui la soluzione è molto più complicata del problema originale? Non sono un esperto in alcun modo, ma molte volte cerco di scegliere la soluzione più semplice che funzioni (e ovviamente non funziona OVUNQUE) ma ho avuto un discreto successo nel suggerire soluzioni semplici sul lavoro che la gente sembra trascurare per MOLTE soluzioni più complicate?

È una cosa normale per i programmatori ..... o non sto pensando nella prospettiva corretta?

Ovviamente, alcuni programmatori sono ansiosi di mostrare quanto sono intelligenti creando un codice scandalosamente complicato che nessuno può capire. Altri programmatori stanno sparando a un livello così alto, che la complicazione nelle soluzioni è una naturale evoluzione.

Alcuni dei peggiori codici che abbia mai visto erano un metodo che conteneva oltre 2000 righe di codice. Senza dubbio questo codice era complesso, ma era anche molto scarso.

Penso che un buon programmatore eviti il ​​codice troppo complicato. Ciò include evitare la tentazione di forzare un modello di progettazione a inserirsi in una soluzione che non lo richiede realmente. Include anche evitare oggetti-dio, pulsanti magici, ottimizzazione prematura, generalizzazione prematura e altri anti-schemi.

Sto costantemente refactoring e cerco opportunità per semplificare le mie soluzioni perché la crescita della complessità è una cosa organica. Come molte altre cose organiche, deve essere tagliato e potato se vogliamo che continui a essere utilizzabile. Odio dover interagire con soluzioni eccessivamente complicate perché con una maggiore complessità arriva una maggiore probabilità di infrangere il codice.

Penso che la leggibilità sia l'elemento più importante della manutenzione del codice e che soluzioni troppo complicate riducano quasi sempre la leggibilità e aumentano i costi di manutenzione.

Ho visto un sacco di codice che era più complesso del necessario e quasi sempre per questi tre motivi:

1) Ingegnerizzato a causa della generalizzazione prematura o cercando di anticipare bisogni futuri che non sono mai sorti

2) Gli sviluppatori volevano imparare / sperimentare un nuovo modello o tecnologia di design che non avevano mai usato prima e lo hanno calpestato anche quando era eccessivo. Lo fanno perché rende il loro lavoro più interessante e imparano qualcosa di nuovo.

3) Sono state aggiunte funzionalità e correzioni di bug, ma il codice esistente non è stato correttamente refactored al momento insieme ad esso. Potrebbe essere solo un piccolo pezzo di duplicazione o affrontare un altro argomento flag su un metodo, ma tutto sommato. In effetti, vengono aggiunti hack e non ci vuole molto perché tutto diventi troppo complicato a causa di tutti gli odori del codice. Questo è il più comune e di solito solo per non conoscere meglio o la pressione del tempo.

È assolutamente una cosa comune. Come dice la maggior parte dei libri, un buon sviluppatore sa come mantenerlo semplice. È troppo semplice complicare troppo qualcosa con una nuova tecnologia o un framework "cool" che hai appena trovato, quindi inizi a cercare modi per usarlo, invece di pensare dal punto di vista dei problemi.

Come ha affermato Martin Fowler, coloro che apprendono una nuova tecnologia hanno un problema a breve termine in cui le sue soluzioni basate sulla "tecnologia".

Non penso che sia normale per tutti i programmatori, ma ho sicuramente visto molti programmatori fare questo.

Penso che alcune persone credano che alcune persone vedano rendere qualcosa di veramente semplice "troppo facile", e che non sia una buona vetrina delle loro abilità. Pertanto, devono creare una soluzione grande e complessa che sia lì per dire "guarda cosa posso fare!", Anche se potrebbe non essere la soluzione migliore per il problema in questione.

Ho visto spesso i programmatori scrivere diverse righe di codice per svolgere un compito che non sapevano fosse già incorporato nel linguaggio. Questo non è esattamente intenzionale, ma può sicuramente essere prevenuto.

Dipende da ciò che chiami "semplice". Alcune persone vedono il codice altamente refactored come più "complesso" perché c'è più codice e più grafici di chiamata. Tuttavia, questo codice è più "semplice" in quanto è molto più semplice apportare modifiche.

Trovo spesso che una grande funzione appaia "semplice" fino a quando non è necessario apportare modifiche, quindi diventa rapidamente complessa.

In altre parole, il semplice è negli occhi di chi guarda in molti casi.

Il problema è se non riesci a vedere chiaramente le soluzioni semplici (è qui che entrano in gioco le discussioni con i colleghi) o se ti generalizzi troppo presto.

In altre parole, fai dei semplici loop in funzioni di libreria avanzate perché pensi di averne comunque bisogno per il tuo prossimo progetto (tranne che non lo farai in questa forma esatta). Fallo per troppo tempo e avrai un'applicazione estremamente complessa con un nucleo molto semplice.

Potresti anche scoprire che devi avere un codice molto robusto, e tutta la robustezza lo rende complesso per impostazione predefinita. Non credo però che questo sia il tuo problema.

In alcuni casi potrebbe essere solo la complessità di trovare una soluzione pulita / semplice.

C'è una citazione che non riesco a ricordare o trovare che va da sola le righe di "Il codice non è completo una volta che hai scritto tutto ciò che devi scrivere, ma completa solo quando non hai più nulla da rimuovere"

La mancanza di chiarezza ostacolerà la capacità delle persone di rimuovere tutto l'eccesso.

I migliori ingegneri sono quelli che possono affrontare problemi davvero complicati e trasformarli in soluzioni facili da implementare e da capire. Sembra semplice, ma non ci sono molti ingegneri / sviluppatori come quelli che esistono. In realtà non ci sono molte persone come quelle che esistono. In realtà la maggior parte delle persone là fuori fa esattamente il contrario. Prendono problemi semplici e li complicano oltre il riconoscimento. Basta guardare i nostri politici per un esempio di persone che riescono a prendere semplici problemi e trasformarli in un caos totale. I programmatori non sono diversi in questo senso.

Personalmente, non ho mai cercato intenzionalmente di complicare un software. Tuttavia, ho finito qualcosa e ho pensato "wow, è troppo complicato" e sono tornato su di esso e riformattato. Alcune persone potrebbero vederlo e pensare che funzioni ed è abbastanza buono e non lo refactoring.

Si presume che un saggio abbia detto che dovresti mantenere le cose il più semplice possibile, ma non più semplice. Lo stesso potrebbe valere per il codice. A volte devi usare una tecnica che alcuni considerano complessa (la ricorsione potrebbe essere un buon esempio, spesso spaventa i programmatori junior).

Tuttavia, in generale, penso che il codice complesso spesso insorga organicamente. Un semplice problema viene risolto con un codice semplice, quindi l'ambito si espande e il codice viene modificato senza pensarci troppo, e nel tempo si ottiene un codice che tenta di coprire il nuovo problema ma è stato davvero progettato per risolvere un altro problema. Diventa una trapunta patchwork di diversi pezzi di logica. Tale codice può quindi apparire spesso molto più complesso di quanto il problema richieda, ma lo è stato perché ogni piccola modifica sembrava, al momento, essere il modo più semplice per far funzionare il codice.

Non penso che la maggior parte degli sviluppatori abbia deliberatamente deciso di rendere il codice complesso (anche se si ottiene lo strano spettacolo che utilizzerà una tecnica per dimostrare la propria abilità), penso che il codice ottenga solo in questo modo se non viene mantenuto e refactored aggressivamente .

Un altro motivo che non è stato ancora sollevato è che le persone potrebbero complicare eccessivamente le soluzioni fornite per garantire che in futuro siano necessari i loro servizi per supportare tali soluzioni. In altre parole: per la sicurezza del lavoro.

Forse un problema di un classico errore?

30. Sviluppatore placcatura in oro.

Gli sviluppatori sono affascinati dalle nuove tecnologie e a volte sono ansiosi di provare nuove funzionalità del loro linguaggio o ambiente o di creare la propria implementazione di una funzionalità che hanno visto in un altro prodotto, indipendentemente dal fatto che sia richiesto o meno nel loro prodotto. Lo sforzo richiesto per progettare, implementare, testare, documentare e supportare le funzionalità che non sono necessarie allunga la pianificazione.

• Steve McConnell, Sviluppo rapido.

Sì, a volte compliciamo troppo il codice per divertirci. Soprattutto anche se la percezione che il codice sia troppo complicato proviene da un partecipante ignorante o junior al progetto.

SÌ ... e ho pagato il prezzo troppe volte.

La mia lavagna ora ha una dichiarazione in asterischi nella parte superiore che legge

"Se non è semplice, non è giusto"

... e ogni volta che prototipo qualcosa sulla lavagna attira sempre la mia attenzione.

Funziona davvero per me perché i miei progetti complessi diventano molto più semplici, il che si traduce in un codice più pulito.