Ovviamente, alcuni programmatori sono desiderosi 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 è un'evoluzione naturale.

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

Penso che un buon programmatore eviti un codice eccessivamente complicato. Questo include evitare la tentazione di forzare un modello di progettazione per adattarsi a una soluzione che non lo richiede realmente. Include anche evitare oggetti di Dio, pulsanti magici, ottimizzazione prematura, generalizzazione prematura e altri anti-pattern.

Riattivo costantemente 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 ad essere utilizzabile. Odio dover interagire con soluzioni eccessivamente complicate perché con l'aumento della complessità aumenta la possibilità di rompere il codice.

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

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

1) Over-engineered a causa della generalizzazione prematura o cercando di anticipare i bisogni futuri che non sono mai sorti

2) Gli sviluppatori volevano imparare / sperimentare con un nuovo modello o tecnologia di progettazione che non avevano mai usato prima e calzato in un punto in cui era eccessivo. Lo fanno perché rende il loro lavoro più interessante e imparano qualcosa di nuovo.

3) Sono state aggiunte funzionalità e correzioni di errori, ma il codice esistente non è stato correttamente refactored al momento insieme ad esso. Potrebbe essere solo un piccolo pezzo di duplicazione o virare su un altro argomento di bandiera su un metodo, ma tutto sommato. In pratica, vengono aggiunti gli 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 dovuto a non conoscere la pressione migliore o il tempo.

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

Come ha detto Martin Fowler, chi apprende una nuova tecnologia ha un problema a breve termine in cui le sue soluzioni "tecnologiche" guidano.

Non penso 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 è una buona dimostrazione delle loro abilità. Pertanto, devono fare una soluzione grande e complessa che è il modo di dire "guarda cosa posso fare!", Anche se potrebbe non essere la soluzione migliore per il problema in questione.

Ho visto i programmatori scrivere spesso diverse righe di codice per eseguire un compito che non sapevano essere già incorporato nella lingua. Questo non è esattamente intenzionale ma può certamente essere prevenuto.

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

Spesso scopro che una funzione di grandi dimensioni sembra "semplice" finché non è necessario apportare modifiche, quindi diventa complessa rapidamente.

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

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

In altre parole, fai semplici loop nelle funzioni di libreria avanzate perché pensi ti servirà comunque per il tuo prossimo progetto (eccetto che non lo farai in questa forma esatta). Fai questo per troppo tempo e hai un'applicazione estremamente complessa con un core molto semplice.

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

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

C'è una citazione che non riesco a ricordare o che trova qualcosa di solo le righe di "Il codice non è completo una volta che hai scritto tutto ciò di cui hai bisogno per 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 prendere problemi davvero complicati e trasformarli in soluzioni facili da implementare e facili da capire. Sembra semplice, ma non ci sono molti ingegneri / sviluppatori come questo 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 semplici problemi 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 rendere più complicato un software. Tuttavia, ho finito qualcosa e ho pensato "wow, è troppo complicato" e sono tornato su e refactored. Alcune persone potrebbero vederlo e pensano che funzioni e sia abbastanza buono e non refactoring.

Si dice che un uomo saggio abbia detto che dovresti mantenere le cose il più semplici possibile, ma non più semplici. 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 si presenti organicamente. Un semplice problema viene risolto con un codice semplice, quindi l'ambito si espande e il codice viene modificato senza pensarci troppo e col tempo si ottiene codice che tenta di coprire il nuovo problema ma che è stato davvero progettato per risolvere un problema diverso. Diventa una trapunta patchwork di diversi pezzi di logica. Tale codice può quindi sembrare spesso molto più complesso di quanto il problema richieda, ma è stato così perché ogni piccolo cambiamento sembrava, al momento, il modo più semplice per far funzionare il codice.

Non penso che la maggior parte degli sviluppatori abbia deliberatamente deciso di rendere complesso il codice (sebbene tu abbia la strana esperienza di usare una tecnica per dimostrare le proprie capacità), penso che il codice ottenga quel modo se non è aggressivo mantenuto e refactored.

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

Forse un problema di un errore classico?

30. Developer gold-plating.

Developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product--whether or not it's required in their product. The effort required to design, implement, test, document, and support features that are not required lengthens the schedule.

• Steve McConnell, Rapid Development.

Sì, a volte complichiamo troppo il codice per intrattenere noi stessi. Principalmente sebbene la percezione che il codice sia troppo complicato viene da un ignorante o da un partecipante Junior nel progetto.

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

La mia lavagna ora ha un'istruzione in asterischi in alto che legge

"If it ain't simple, it ain't right"

... e ogni volta che realizzo un prototipo sulla lavagna, attira sempre la mia attenzione.

Funziona davvero per me perché i miei disegni complessi diventano molto più semplici e si traducono in codice più pulito.