Existe um termo para excesso de complicações do POO?

Há um ou dois anos, vi um excelente artigo sobre OOP (Java), que mostrava a progressão de um simples logger concreto de duas ou três linhas de código, e um excesso de processos teóricos por parte do desenvolvedor inexperiente que basicamente dizia oh, eu deveria adicione isso caso desejemos isso! No final do artigo, esse simples logger era uma enorme bagunça que o desenvolvedor original mal conseguia entender.

Existe um termo comum para esse tipo de complicação excessiva? Esse artigo (que eu gostaria muito de encontrar novamente) mostra o conceito maravilhosamente para um caso isolado, mas me deparei com projetos inteiros nos quais os desenvolvedores essencialmente se programavam em um nó pelo uso excessivo de padrões, estruturas, bibliotecas e outros problemas. A seu modo, isso é tão ruim (ou até pior) que os aplicativos espaguetes VB6 herdados que herdamos para substituição.

O que realmente estou procurando é trazer isso à tona durante as entrevistas. Quero saber se alguém está ciente e consciente de como é fácil cair nessa com falta de arquitetura / pré-planejamento (e se desentender se parece que eles têm o equilíbrio correto no lugar), mas não é realmente algo Eu posso encontrar muitas informações sobre.

O termo mais frequente que ouvi para descrever esses projetos é superengenharia . O significado original dessa palavra, no entanto, não está relacionado ao desenvolvimento de software e, fora do desenvolvimento de software, provavelmente não tem um tom tão ruim.

Em um nível mais geral, Joel Spolsky deu aos designers que complicam demais os projetos arquitetônicos o nome " astronautas da arquitetura ".

No entanto, especialmente para uma entrevista, acho que é mais importante saber como se chama o contrário, colocando apenas coisas em um design que são realmente necessárias e esquecer a abordagem doentia do tipo "apenas no caso" - isso é chamado de princípio YAGNI .

Sim, superengenharia é o termo mais simples para descrever isso. Eu já vi projetos superengenharia e desnecessariamente complicados mais vezes do que me lembro ao longo dos anos. Muitos anos atrás, ao fazer um curso Microsoft GWBasic, o instrutor repetidamente martelou o método KISS (Keep it Simple Stupid). Isso é tão verdadeiro hoje como era então.

Por isso, lembro-me sempre do KISS e sempre projetei com os princípios do SOLID em mente. Porém, com isso dito, ainda é possível sobreaquecer um projeto com os princípios do SOLID totalmente considerados. Você precisa equilibrar uma abordagem pragmática do senso comum com o desejo de ser puro e aderir às diretrizes de OOP geralmente aceitáveis. Se você tiver tempo suficiente e se gosta de criar soluções complexas, pode acabar desenvolvendo um motor para um skate, porque pensou que ele acabaria sendo transformado em carro. Felizmente, fui disciplinado o suficiente para não fazer isso ao longo dos anos, mas já o vi muitas vezes.

Então, para resumir, para evitar a complicação excessiva do código:

1) BEIJO (Mantenha Simples Estúpido)

2) Siga os princípios do SOLID com praticidade em mente.

3) Não tente projetar para todas as eventualidades. E, às vezes, abstrações pequenas e vazadas não são coisas horríveis, se isoladas, intencionais e se o esforço para evitá-las supera em muito os efeitos de mantê-las.

4) Considere a implementação de soluções ao projetá-las. Você não pode simplesmente dizer "ah, isso é um detalhe de implementação" e assumir que seu design é prático. Eu costumava trabalhar com um arquiteto que fazia isso com frequência e, infelizmente, seus projetos nunca funcionavam e, como resultado, não trabalho mais lá.

5) Codifique como se você fosse o responsável por mantê-lo.

Então, você terá esta entrevista e pretende induzir o candidato a exibir o que ele sabe sobre engenharia de software e então dirá "Nah, você provavelmente deseja aplicar tudo o que sabe em sua primeira tarefa, siga em frente agora , seu criador de valor acima dos negócios, que não empresta ouro à engenharia! Shoo! "

Eu acho que seria mais seguro apresentar um exemplo concreto e discutir os prós e contras da aplicação de certos padrões. Do que você solicitaria respostas como "Depende, você quer isso rápido? Isso é tudo? Qual é o problema do complicado? Que padrões já existem?" e você pode aprender algo sozinho. Isso também permitiria ao candidato provar seu senso de contexto, enquanto seria uma pergunta mais aberta. Esperando e desejando uma resposta específica, você terá, na melhor das hipóteses, alguém com a mesma maior preocupação que a sua. Se você não receber sua resposta, pode ser que o candidato considere isso um acéfalo.