Esiste un termine per una complicazione eccessiva di OOP?

Il termine più frequente che ho ascoltato per descrivere questi progetti è overengineering . Il significato originale di quella parola, tuttavia, non è legato allo sviluppo del software e, al di fuori dello sviluppo del software, probabilmente non è così un brutto tono.

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

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

Sì, l'overengineering è il termine più semplice per descriverlo. Ho visto disegni ingegnerizzati, inutilmente complicati, più volte di quanto possa ricordare nel corso degli anni. Molti anni fa, durante l'assunzione di un corso Microsoft GWBasic, l'insegnante ha ripetutamente martellato il metodo KISS (Keep it Simple Stupid). Questo è vero oggi come allora.

Quindi ricordo sempre i KISS e ho sempre progettato con i SOLID Principles in mente. Ma con ciò detto, è ancora possibile prendere in carico un progetto con i principi SOLID pienamente considerati. Devi bilanciare un buon senso, un approccio pragmatico con il desiderio di essere puro e rispettare le linee guida OOP generalmente accettabili. Se ti viene dato abbastanza tempo e se ami creare soluzioni complesse, puoi finire nel percorso di progettazione di un motore per uno skateboard perché pensavi che alla fine sarebbe diventato un'auto. Fortunatamente, sono stato abbastanza disciplinato da non farlo nel corso degli anni, ma l'ho visto molte volte.

Quindi, per riassumere, per evitare la complicazione del codice:

1) KISS (Keep it Simple Stupid)

2) Segui i principi SOLID con in mente la praticità.

3) Non cercare di progettare per ogni eventualità. E a volte piccole, astrazioni che perdono non sono cose orribili, se sono isolati, intenzionali e se lo sforzo per prevenirli supera di gran lunga gli effetti del loro mantenimento.

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

5) Codice come se tu sei colui che lo manterrà.

Quindi, avrai questa intervista e intendi ingannare il candidato per mostrare ciò che sa sull'ingegneria del software e poi dirai "Nah, probabilmente vorrai applicare tutto ciò che sai nel tuo primo incarico, muoviti ora, pluri-over-engineering creatore di valore non commerciale! Shoo! "

Penso che sarebbe più sicuro presentare un esempio concreto e discusare i pro ei contro dell'applicazione di determinati modelli. Di quanto si potrebbe sollecitare risposte come "Dipende, lo vuoi veloce?" Sarà tutto questo? Quanto è complicato il problema? Quali schemi sono già in atto? " e potresti imparare qualcosa da te. Ciò consentirebbe anche al candidato di provare il suo senso del contesto mentre sarebbe una domanda più aperta. Aspettando e volendo una risposta specifica, nel migliore dei casi, otterrai qualcuno con la stessa preoccupazione maggiore della tua. Se non trovi la tua risposta, potrebbe essere il candidato, lo considera un gioco da ragazzi.