Como evitar o overengineering? Eu não sei, você sabe?

Eu sei como tentar, conseguir é um pouco mais complicado.

Eu sei que é comum as pessoas fazerem isso e é mais fácil ver acontecendo de fora. Em geral, a pessoa que faz sempre vai defender que não está fazendo e vai justificar, desde algumas defesas mais sensatas  até as mais absurdas. Então eu posso cair nessa armadilha como qualquer um.

Eu sempre falo que seguir boa prática é péssimo, e a maior consequência é fazer over engineering. O certo é entender profundamente a área que está trabalhando, assim não precisará das boas práticas, a não ser como lembrete. Sabendo o que está fazendo, dá para tomar decisões mais certas.

Então um jeito de evitar isso é abominar boas práticas, elas são muletas de quem não sabe o que está fazendo. Você deve conhecê-las, criticá-las e saber se por acaso fará algo que está dito ali.

E aí vem o outro ponto, que é se formar bem. Formação geral, e específica. Seu conhecimento precisa ter boa forma e entregar resultados melhores. Quem entende o todo e os detalhes do que está fazendo tem mais chance de evitar abusos, a pessoa pelo menos consegue entender o erro que pode estar cometendo.

Outro não tem como comprar, acelerar, ou fazer nada para obter. É a experiência. Sem ela você vai errar muito nisso. Dá para conseguir acertar mais e mais rápido, mas o que ajuda é justamente errar mais e o tempo atrás do tempo, que te ensina como lidar melhor com isso.

Ajuda entender muito bem o que são o KISS e o YAGNI para não usar o que não precisa, mesmo que ache que precisa ou porque alguém disse que você precisa sem prova alguma, principalmente no seu contexto, e fazer algo que seja complexo, mesmo que seja justificado que está diminuindo a complexidade. Sim, as pessoas vivem dando essas desculpas sem provas de resultado.

Assim como o nude engineering pode ser um problema também. Fazer esculachado é um problema tão grande ou maior. Fazer tudo na intuição tem a mesma origem do euroengineering, a falta de conhecimento, experiência e sobra de crenças.

Se você evitar modinhas, de todo tipo e duração (moda não é algo passageiro, é o que você usa porque os outros estão usando), já ajuda bastante, boa parte do over engineering é porque a pessoa quer usar tudo o que estão falando por aí.

Eu tenho um pouco de medo "vá aprendendo a fazer robusto com o passar do tempo" porque isso é under engineering e acaba virando gambiarra, mesmo que a pessoas justifique que está só combatendo o over engineering. Pra falar a verdade eu nunca vi essa técnica dar certo. Pode ter acontecido com alguém, só não vi na frente. Vi muito a pessoa achar que está dando certo.

Não podemos evitar algo indo pro outro lado, não pode servir de desculpa para fazer o oposto.

Acha que é fácil evitar? Então você é bom. Porque eu, depois de 40 anos fazendo isso, ainda não consigo fazer tão bem assim. Falar é sempre mais fácil que fazer.

Se você arrumar sarna pra se coçar vai pagar por isso.

Vou dar um exemplo de como é fácil cair nisso: um belo dia o Stack Overflow descobriu que o cache está causando mais problemas que benefício. Todo mundo acha que o cache é muito necessário e traz muito benefício, mas isso se mostra falso em mais casos do que você imagina. Porque em vez de medirem e depois fazer, fizeram antes indo na onda do que é a crença popular. Quando tiraram isso tiveram ganho de manutenção e desempenho.

Outro exemplo: a pessoa cria a complicação e ineficiência para fazer a aplicação poder trocar de banco de dados no futuro. Isso nunca é necessário, e quando vai ser feito assim mesmo a pessoa descobre que não fez tudo o que era necessário e o trabalho é mais ou menos o mesmo que não tivesse preparado para trocar.

Entenda que você não consegue fazer previsões sobre o futuro.

Faz sentido?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Infelizmente eu acabo passando um pouco por isso no dia a dia. Acabo nas minhas implementações fazendo muito pattern e camada pra desacoplamento que depois acaba complicando um pouco o time.
Mas eu consigo até me justificar o problema é que nem sepre

• Praticamente todas as vezes

Fazem a análise do domínio e isso atrapalha muito, porque a gente acaba programando sem nem saber o que aquilo vai fazer. Eu tou num projeto a mais de 1 ano que eu praticamente fiz do zero e se me perguntarem sobre o negócio eu não sei praticamente nada daquilo. Aqui a cultura é fazer tabelas no banco e depois montar aplicação por cima disso. No meu caso eu acabo programando nas cegas, não faz sentido nem ter um DDD definido e já ir logo fazer relacionamento com as tabelas.
É a tal história do "Assa um pizza ai, mas depois eu escolho o sabor".

O problema nem sempre tá no dev que implementou esses monte de overengineer mas sim na parte superior, que não transmite bem o conceito do negocio.

Enfim acaba que fica como um desabafo aqui pra vocês.

Tenho estudado muito mais sobre DDD e análise de sistema do que código em sí e isso tem aberto muito meus horizontes para conseguir criticar aquilo que faço no dia a dia. E quando eu falo de DDD não é fica fazendo pasta e sim sentar com o cliente, levantar requisitos, estabelecer uma linguagem oblíqua, fazer uma prototipagem e todo o resto. To cansado de começar pelo código e depois descobrir que os meses que passei pensando que aquilo na verdade era pra ser outra coisa e depois no fim acaba que fica tudo remendado nas gambiarras porque agora já não tem tempo de refazer tudo de novo.

Com isso deixo aqui um conselho ao escritor do post: As vezes o problema aí é falta de comunicação e planejamento prévio. O que depois acaba causando essas frustrações.

Seu post foi como alguem falando de um lado e eu respondendo do outro kkk

muito foda essa comunidade!

pesquisando assim no google
overengineering site-tabnews.com.br
foram encontrados 271 resultados em artigos e comentários
ʘ‿ʘ
atualizei no texto com o primeiro artigo que já matou a charada, pelo menos pra mim.