Um fator da corrupção da arquitetura é o compromisso com o custo de desenvolvimento
Categories:
As características de uma arquitetura corrupta são: muitos tratamentos especiais, tratamentos de compatibilidade, acoplamento severo, peso acumulado difícil de reverter. Toda arquitetura apodrece lentamente. A arquitetura corrupta dificulta o desenvolvimento de novos recursos, bugs são difíceis de corrigir, mexer em uma parte afeta o todo, o que torna os testes e QA também muito difíceis de fazer. Já vi um entusiasta de desenvolvimento de outra área postar dizendo que restringir o comportamento de abstração do modelo ao escrever código faz o código ser mais fácil de entender. Código que as pessoas entendem mais facilmente, os LLMs também entendem mais facilmente, portanto é possível desenvolver rapidamente e reduzir erros. Imagino que o desenvolvedor de outra área provavelmente tem projetos menores e está acostumado com lógica tipo linha de montagem; se houver expectativa de expansão de escala, a forma de pensar não pode se limitar à linha de montagem, mas deve adotar a mentalidade de operário da construção civil. Se a expectativa é construir um prédio de 30 andares, é preciso fazer uma fundação de 10 metros; se a expectativa é ter água e energia, é preciso reservar casa de água e casa de energia. Este é um projeto com objetivo claro; além disso, há projetos com objetivo não claro, como reservar tomadas em algum lugar da casa para colocar um eletrodoméstico no futuro, mas sem saber qual, basta reservar a tomada. A engenharia de software já possui os princípios SOLID para guiar o projeto. Muitas vezes, na aparência, seguir os princípios SOLID para implementar a mesma funcionalidade exige passar por mais arquivos e escrever mais código; no curto prazo, projeto ou não projeto quase não faz diferença para o chefe/testes/usuários, e o benefício do projeto só aparece a longo prazo. Uma boa arquitetura facilita adicionar recursos, modificar recursos, corrigir bugs e introduzir menos problemas. O pensamento necessário para o projeto costuma ser maior do que simplesmente começar a desenvolver a funcionalidade direto; o projeto exige considerar a granularidade. Cobrir a casa toda com painéis de tomada como se fossem azulejos é outro absurdo. No passado, ao desenvolver, eu considerava o ciclo de desenvolvimento e fazia concessões; quando o tempo era curto, nem projetava, só adicionava algumas funções e pronto, o futuro se resolve no futuro. Agora, com a IA, podemos tornar a granularidade do projeto menor, e o código gerado fica mais difícil para humanos lerem, mas a engenharia fica mais fácil de manter. Após aumentar a abstração, modelos piores realmente podem não lidar bem, é melhor usar o melhor modelo atual. Se for apenas escrever scripts, a diferença de capacidade entre modelos pode não ser tão óbvia. Sobre se a IA reduziu a barreira de entrada para desenvolvedores? Tenho dúvidas, afinal o caminho de aprendizagem de novos desenvolvedores é totalmente diferente do passado, discutir se a barreira é alta ou baixa pode não fazer sentido, pois não sabemos para onde a barreira foi movida.
