Overengineering vs UnderEngineering, o dilema da vida dos Devs

Faaaala pessoal, minha empresa atual é minha primeira (e talvez única) experiência como desenvolvedor pra valer.
Entrei como trainee em 2011 e ano a ano fui avançando de fases até chegar à senioridade 👴
O que pude aprender nestes 12 anos, tendo passado por códigos legados em todas as nossas stacks (Delphi, Python, C#, Java, Node, ESB, Angular, React),
é que para um código ser bem feito, basta seguir alguns princípios básicos, como:

• Não repetir código (preferir métodos de responsabilidade única e que, sempre que possível, possam ser usados em mais lugares com a mesma necessidade)
• Não utilizar valores fixos dentro de métodos (preferir classes de constates e enum)
• Manter as responsabilidades das classes a todo custo (regra de negócio é em classe de regra de negócio)
• Faça código para os outros e não para você (a menos que você vá dar manutenção pra sempre, ai o filho é teu então crie como quiser 😅)
• Commit = Legado (que legado você quer deixar?)

Enfim, gostei desse artigo e principalmente do vídeo, onde são expostos alguns destes princípios que sempre carreguei comigo, mas nunca cheguei a trocar figuras com alguém sobre.

Bons códigos a todos ✌️🤓

Acho que entre OverEngineering e UnderEngineering eu prefiro fazer Engineering. Ou seja, utilizar código pequenos apenas nos pontos em que precisam ser utilizados que é normalmente automatização e/ou integração