¿Existe un término para una complicación excesiva de la POO?

Hace un año o dos vi un excelente artículo sobre OOP (Java), que mostraba la progresión de un simple registrador concreto de dos o tres líneas de código, y un proceso teórico de pensamiento excesivo por parte del desarrollador inexperto que básicamente decía oh, debería ¡agregue esto en caso de que alguna vez lo deseemos! Al final del artículo, este simple registrador era un desorden gigante de basura que el desarrollador original apenas podía entender ...

¿Existe un término común para este tipo de complicación excesiva? Ese artículo (que desearía poder encontrar de nuevo) muestra el concepto maravillosamente para un caso aislado, pero me he encontrado con proyectos completos en los que los desarrolladores se habían programado esencialmente en un nudo por el uso excesivo de patrones, marcos, bibliotecas y otros asuntos. A su manera, esto es tan malo (o incluso peor) que las aplicaciones de espagueti VB6 heredadas que heredamos para su reemplazo.

Lo que realmente estoy buscando es mencionar esto cuando entrevisto. Quiero saber si alguien es consciente y consciente de lo fácil que es caer en esto con falta de arquitectura / planificación previa (y obtener una idea de si parecen tener el equilibrio correcto), pero en realidad no es algo Puedo encontrar mucha información sobre.

El término más frecuente que escuché para describir tales diseños es la ingeniería excesiva . El significado original de la palabra, sin embargo, no está relacionada con el desarrollo de software, y fuera del desarrollo de software que tiene, probablemente, no es un mal tono tan.

En un nivel más general, Joel Spolsky dio a los diseñadores que complicaron demasiado los diseños arquitectónicos el nombre de " astronautas de la arquitectura ".

Sin embargo, especialmente para una entrevista, creo que es más importante saber cómo se llama lo contrario, poner solo las cosas en un diseño que realmente se necesitan y olvidarse del enfoque poco saludable "por si acaso": esto se llama el principio YAGNI .

Sí, la sobreingeniería es el término más simple para describir esto. He visto diseños excesivamente complicados y innecesariamente complicados más de lo que puedo recordar a lo largo de los años. Hace muchos años, cuando tomaba un curso de Microsoft GWBasic, el instructor repetidamente golpeó el método KISS (Keep it Simple Stupid). Esto es tan cierto hoy como lo fue entonces.

Así que siempre recuerdo KISS y siempre diseño con los principios SOLID en mente. Pero dicho esto, todavía es posible diseñar un diseño con principios SÓLIDOS plenamente considerados. Debe equilibrar un enfoque pragmático de sentido común con el deseo de ser puro y adherirse a las pautas OOP generalmente aceptables. Si se le da suficiente tiempo y le encanta crear soluciones complejas, puede terminar en el camino del diseño de un motor para una patineta porque pensó que eventualmente se convertiría en un automóvil. Afortunadamente, he sido lo suficientemente disciplinado como para no hacer esto a lo largo de los años, pero lo he visto muchas veces.

Para resumir, para evitar la complicación excesiva del código:

1) BESO (Mantenlo simple estúpido)

2) Siga los principios SÓLIDOS con la practicidad en mente.

3) No intentes diseñar para cada eventualidad. Y a veces, las abstracciones pequeñas y con fugas no son cosas horribles, si están aisladas, son intencionales y si el esfuerzo para evitarlas supera con creces los efectos de mantenerlas.

4) Considere la implementación de soluciones mientras las diseña. No puede simplemente decir "oh, ese es un detalle de implementación", y asumir que su diseño es práctico. Solía ​​trabajar con un arquitecto que hacía esto con frecuencia, y, por desgracia, sus diseños nunca funcionaron, y como resultado, ya no trabajo allí.

5) Codifique como si fuera usted quien lo mantendrá.

Entonces, va a tener esta entrevista y tiene la intención de engañar al candidato para que muestre lo que sabe sobre ingeniería de software y luego dirá "No, probablemente quiera aplicar todo lo que sabe en su primera tarea, avance ahora , creador de chapa dorada sobre ingeniería sin valor comercial! Shoo! "

Creo que sería más seguro presentar un ejemplo concreto y discutir los pros y los contras de aplicar ciertos patrones. De lo que estaría solicitando respuestas como "Depende, ¿lo quiere rápido? ¿Será todo esto? ¿Qué tan complicado es el problema? ¿Qué patrones ya existen?" y puedes aprender algo tú mismo. Esto también permitiría al candidato demostrar su sentido del contexto, mientras que sería una pregunta más abierta. Esperar y querer una respuesta específica, en el mejor de los casos, le brindará a alguien con la misma mayor preocupación que la suya. Si no obtiene su respuesta, podría ser que el candidato lo considere obvio.