I programmatori a volte intenzionalmente complicano il codice? [chiuso]


26

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?


5
1. Sì, a volte penso. 2. Sì, almeno alcuni programmatori almeno qualche volta hanno complicato troppo il loro codice, almeno alcune volte intenzionalmente. 3. Casi chiusi.
Lavoro

3
Hai mai avuto qualcuno che ti urlava "Avresti dovuto pensarci!" quando hai perso alcuni requisiti che non erano stati indicati nella raccolta dei requisiti iniziali? Questo è ciò che può portare a rendere le cose più complesse del necessario.
JB King,

Risposte:


18

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.


32

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.


Sono colpevole di # 2, temo. Con l'esperienza (e la maturità?) Ora tendo ad astenermi però ... e invece esperimento a casa :)
Matthieu M.

Vedo che le persone fanno sempre 1, finiscono per creare 5 volte più lavoro per se stessi
Ally

11

È 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".


4
-1: Come dicono molti libri, un buon sviluppatore sa come mantenerlo semplice. - Hai assolutamente ragione su questo. Ma poi hai insinuato che l'abuso di nuove tecnologie è la principale causa di complicazioni eccessive del codice. Ti sbagli. Credetemi, c'è un sacco di codice complicato là fuori che non ha nulla a che fare con un abuso di nuove tecnologie.
Jim G.

Dove esattamente ho insinuato che è la "più grande causa di codice eccessivamente complicato"? È certamente un problema, "Ehi, ho appena imparato il modello X, dove posso applicarlo" - Patternitus. Mi hai davvero messo le parole in bocca lì, Jim.
Martin Blore,

4
"Ho reso questa lettera più lunga del solito, solo perché non ho avuto il tempo di accorciarla." - Blaise Pascal Molto applicabile anche qui. "Complicato" è spesso un segno di codifica affrettata, pigra o incompetente.
Bill

@Bill La cosa interessante è che è un buon argomento per un codice più complesso da un punto di vista aziendale - se ti viene pagato un importo fisso per implementare qualcosa e ci vuole più tempo per rifattorizzare o accorciarlo, a meno che tu non possa farlo giusto la prima volta (chi può?) c'è essenzialmente una penalità per rendere il tuo codice già funzionante meno complesso.
Michael,

10

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.


1
Ecco come lo guardo. IE se è troppo facile non vale la pena usarlo?

@Mercfh Non capisco la vista. Che cosa ha a che fare la facilità di una soluzione con la sua efficacia?
GSto

Stavo commentando il suo commento dicendo "Sì, sono d'accordo" che a volte i programmatori pensano che "Oh, se è troppo semplice, non è molto buono".

7

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.


Ho visto programmatori che hanno scritto un ciclo per ogni copia di stringa. Non ho mai usato una chiamata a una funzione di libreria standard. (La cosa peggiore è che la copia delle piattaforme è stata ottimizzata per leggere una parola alla volta.)
BillThor

7

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.


2
+1: troppi programmatori non ci pensano
Luca

5

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.


4

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.


4
Un'altra citazione pertinente è: "Avrei scritto una lettera più breve ma non avevo tempo".
user16764

3
"Il semble que la perfezione attira non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher." ("Sembra, la perfezione si ottiene non quando non c'è altro da aggiungere ma quando non c'è altro da rimuovere. ”) - Pilota, poeta e ingegnere francese Antoine Marie Roger Vicomte de Saint-Exupéry, 1939 (dal libro Terre des Hommes ( Vento, sabbia e stelle )).
Jörg W Mittag,

Grazie, sembra che non abbia mai conosciuto la vera origine :-) Bello.
Stephen Bailey,

3

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.


3
Ahia! Stavo per darti un +1, ma poi ho visto la tua analogia con la politica, e nella migliore delle ipotesi è debole. // È vero - C'è un sacco di offuscamento, movimento sprecato, agitando le mani e interessi speciali incorporati nella politica e, di conseguenza, i conti possono diventare eccessivamente complicati. Ma l'eccessiva complicanza è un sottoprodotto dell'offuscamento, del movimento sprecato, dell'ondeggiamento della mano e di interessi speciali. Non una causa principale.
Jim G.

Qualunque sia la ragione, ci sono soluzioni molto semplici a molti dei problemi del paese, ma i politici scelgono di renderli più difficili di quelli di cui hanno bisogno. Supponiamo che ciò sia dovuto al denaro, al potere o ai voti, ma credo anche che si tratti in gran parte di capacità. Nel qual caso la mia analogia è solida.
Dunk

1
@JimG. Sì, sono d'accordo con te ... mi sembra che molti dei problemi con le soluzioni politiche siano politici che sostengono che esiste una soluzione facile (la loro!) A un problema davvero complicato che in realtà non ha una soluzione facile.
Michael,

2

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.


1

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 .


È sorprendente il numero di sistemi che iniziano con un core davvero semplice che soddisfa quasi tutti i requisiti ma non soddisfa i requisiti in molti modi distinti, per poi finire con l'aggiunta di molte complicazioni per affrontare un sacco di lacune che avrebbero potuto essere evitate con un design leggermente più complicato. Considera il semplice design dei tipi interi di C e alcune delle regole stranamente complesse che ne derivano. Se per ogni tipo ci fosse stata un'opzione "dovrebbe essere promotable", ciò avrebbe raddoppiato nominalmente il numero di tipi (anche se non in modo diverso da un qualificatore come volatile, ecc.) Ma ...
supercat

... avrebbe facilitato notevolmente le regole di promozione / bilanciamento. Un short senza segno non promotable aggiunto a un int promotable produrrebbe un short senza segno non promotable, anche se shortè grande come int. Un promotable unsigned shortaggiunto a un promotable intavrebbe prodotto un int. L'aggiunta di oggetti firmati e non firmati della stessa dimensione, o l'aggiunta di oggetti non promotabili di dimensioni diverse, sarebbe un errore. Aggiungi un po 'di complessità in primo piano, e strani casi angolari a valle scompaiono.
supercat

1

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.


Non sono sicuro del motivo per cui questo è stato sottoposto a downgrade, mi sono imbattuto in progetti estremamente grandi codificati da un uomo, che ha creato il proprio framework, e che è stato pagato ogni ora lavorando esclusivamente su questo progetto. Se il datore di lavoro lo incazzasse, l'intera linea di prodotti sarebbe rovinata. Ci sarebbero voluti mesi prima che un altro sviluppatore comprendesse a fondo il codice, mentre il programmatore "onnisciente" avrebbe impiegato qualche minuto per aggiornare il suo pasticcio di spaghetti.
SSH Questo

0

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.

0

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.


1
-1 Gli sviluppatori senior che incolpano categoricamente i problemi con gli sviluppatori junior probabilmente non comprendono le motivazioni del proprio lavoro o del lavoro degli altri. Se gli sviluppatori junior hanno difficoltà a seguire il tuo codice, allora È troppo complicato.
Brandon

Dirò che se uno sviluppatore Jr trova il codice impossibile da capire, questo è un odore di codice e potrebbe in effetti essere che il codice è troppo complicato, tuttavia stai usando lontano per allargare un pennello qui. Questo odore di codice può in effetti esistere solo perché lo sviluppatore di Jr ha bisogno di aiuto per comprendere una tecnica avanzata, non che la stessa tecnica sia da incolpare.
P. Roe,

-1

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.