Esiste un termine per l'eccessiva complicazione di OOP?

Un anno o due fa ho visto un eccellente articolo su OOP (Java), che mostrava la progressione di un semplice logger concreto di due o tre righe di codice e un eccessivo processo teorico di pensiero da parte dello sviluppatore inesperto che sostanzialmente diceva oh, dovrei aggiungi questo nel caso in cui lo desiderassimo! Alla fine dell'articolo questo semplice logger era un enorme casino di immondizia che lo sviluppatore originale non riusciva a capire da solo ...

C'è un termine comune per questo tipo di complicazioni eccessive? Quell'articolo (che desidero ardentemente poter trovare di nuovo) mostra il concetto meravigliosamente per un caso isolato, ma mi sono imbattuto in interi progetti in cui gli sviluppatori si erano sostanzialmente programmati in un nodo con un uso eccessivo di schemi, framework, librerie e altri problemi. A suo modo, questo è tanto male (o anche peggio) delle app di spaghetti VB6 legacy che ereditiamo per la sostituzione.

Quello che sto davvero cercando è di sollevarlo durante l'intervista. Voglio sapere se qualcuno è consapevole e consapevole di quanto sia facile cadere in questo con mancanza di architettura / pre-pianificazione (e rimettersi in sesto per se sembrano avere il giusto equilibrio in atto), ma non è davvero qualcosa Posso trovare molte informazioni su.

Il termine più frequente che ho sentito per descrivere tali progetti è l' ingegnerizzazione eccessiva . Il significato originale di quella parola, tuttavia, non è legato allo sviluppo del software e al di fuori dello sviluppo del software probabilmente non ha un tono così cattivo.

A un livello più generale, Joel Spolsky ha dato ai designer che complicano eccessivamente i progetti architettonici il nome di " astronauti dell'architettura ".

Tuttavia, soprattutto per un'intervista, penso che sia più importante sapere come si chiama il contrario, mettendo solo le cose in un progetto che sono effettivamente necessarie e dimenticano l'approccio malsano "nel caso in cui" - questo si chiama principio YAGNI .

Sì, l'ingegnerizzazione eccessiva è il termine più semplice per descriverlo. Ho visto progetti ingegnerizzati, inutilmente complicati più volte di quanto riesca a ricordare negli anni. Molti anni fa, durante un corso Microsoft GWBasic, l'istruttore ha ripetutamente martellato il metodo KISS (Keep it Simple Stupid). Questo è vero oggi come lo era allora.

Quindi ricordo sempre KISS e disegno sempre pensando ai principi SOLID . Detto questo, è ancora possibile progettare in modo eccessivo un progetto con i principi SOLID pienamente considerati. Devi bilanciare un senso comune, un approccio pragmatico con il desiderio di essere puro e aderire alle linee guida OOP generalmente accettabili. Se ti viene concesso abbastanza tempo e se ti piace creare soluzioni complesse, puoi finire per progettare un motore per uno skateboard perché pensavi che alla fine sarebbe stato trasformato in un'auto. Fortunatamente, sono stato abbastanza disciplinato da non farlo negli anni, ma l'ho visto molte volte.

Quindi, per riassumere, per evitare un'eccessiva complicazione del codice:

1) KISS (Keep it Simple Stupid)

2) Seguire i principi SOLID tenendo presente la praticità.

3) Non provare a progettare per ogni evenienza. E a volte le piccole astrazioni che perdono non sono cose orribili, se sono isolate, intenzionali e se lo sforzo di prevenirle supera di gran lunga gli effetti del mantenerle.

4) Considerare l'implementazione di soluzioni durante la progettazione. Non puoi semplicemente dire "oh, questo è un dettaglio di implementazione" e presumere che il tuo design sia pratico. Lavoravo con un architetto che lo faceva spesso, e purtroppo i suoi progetti non hanno mai funzionato e, di conseguenza, non ci lavoro più.

5) Codice come se tu fossi quello che lo manterrà.

Quindi, avrai questa intervista e intendi indurre il candidato a mostrare ciò che sa sull'ingegneria del software e poi dirai "No, probabilmente vorrai applicare tutto quello che sai nel tuo primo incarico, andare avanti adesso , creatore di valore eccessivo non ingegneristico e placcatura in oro! Shoo! "

Penso che sarebbe più sicuro presentare un esempio concreto e discuterne i pro e i contro dell'applicazione di determinati schemi. Di quanto solleciteresti risposte come "Dipende, lo vuoi in fretta? Sarà tutto questo? Quanto è complicato il problema? Quali schemi sono già in atto?" e potresti imparare qualcosa tu stesso. Ciò consentirebbe anche al candidato di dimostrare il suo senso del contesto, mentre sarebbe una domanda più aperta. Aspettare e desiderare una risposta specifica ti darà nel migliore dei casi qualcuno con la stessa preoccupazione più grande della tua. Se non ottieni la tua risposta, potrebbe essere il candidato a considerarlo un gioco da ragazzi.