Minha regra geral é que, quando tenho que fazer algo pela terceira vez, é hora de escrever um pequeno script para automatizá-lo ou repensar minha abordagem.
Não estou criando uma "ferramenta" completa neste momento, apenas um pequeno script (geralmente bash ou python; o perl também funcionaria ou até PHP) que automatiza o que eu fazia manualmente antes. É basicamente uma aplicação do princípio DRY (ou o princípio Fonte Única da Verdade, que é essencialmente a mesma coisa) - se você precisar alterar dois arquivos de origem em conjunto, deve haver alguma verdade comum que eles compartilhem, e que a verdade deve ser fatorada e armazenada em um local central. É ótimo se você pode resolver isso internamente refatorando, mas às vezes isso não é possível, e é aí que entram os scripts personalizados.
Posteriormente, o script pode ou não evoluir para uma ferramenta completa, mas geralmente começo com um script muito específico, com muitas coisas codificadas nele.
Eu odeio o trabalho pesado com paixão, mas também acredito fortemente que é um sinal de design ruim ou incorreto. Ser preguiçoso é uma qualidade importante em um programador, e é melhor que você se esforce ao máximo para evitar trabalho repetitivo.
Claro, às vezes o saldo é negativo - você passa três horas refatorando seu código ou escrevendo um script para economizar uma hora de trabalho repetitivo; mas, geralmente, o saldo é positivo, mais ainda se você considerar os custos que não são diretamente aparentes: falha humana (humanos são muito ruins em trabalhos repetitivos), base de código menor, melhor capacidade de manutenção devido à redundância reduzida, melhor auto-documentação, futuro mais rápido desenvolvimento, código mais limpo. Portanto, mesmo que o saldo pareça negativo agora, a base de código crescerá ainda mais e a ferramenta que você escreveu para gerar formulários da web para três objetos de dados ainda funcionará quando você tiver trinta objetos de dados. Na minha experiência, o equilíbrio é geralmente estimado em favor do trabalho pesado, provavelmente porque tarefas repetitivas são mais fáceis de estimar e, portanto, subestimadas, enquanto refatoração, automação e abstração são percebidos como menos previsíveis e mais perigosos e, portanto, superestimados. Geralmente, a automação não é tão difícil, afinal.
E há o risco de fazê-lo tarde demais: é fácil refatorar três novas classes de objetos de dados e criar um script que gere formulários da Web para elas. Depois de fazer isso, é fácil adicionar mais 27 classes que Também trabalhe com seu script. Mas é quase impossível escrever esse script quando você atinge um ponto em que existem 30 classes de objetos de dados, cada uma com formulários da Web manuscritos e sem consistência entre elas (também conhecida como "crescimento orgânico"). Manter essas 30 classes com seus formulários é um pesadelo de codificação repetitiva e substituição semi-manual de pesquisa. A alteração de aspectos comuns leva trinta vezes o tempo necessário, mas a escrita de um script para resolver o problema, o que seria um acaso para o almoço quando o projeto começou, agora é um projeto assustador de duas semanas, com a terrível perspectiva de um mês de duração, que consiste em corrigir bugs, educar os usuários e possivelmente até desistir e reverter para o projeto. base de código antiga. Ironicamente, escrever a bagunça de 30 classes demorou muito mais do que a solução limpa teria, porque você poderia estar usando o script conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração. porque você poderia estar usando o roteiro conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração. porque você poderia estar usando o roteiro conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração.
