- Este texto não é um conselho, mas sim uma descrição dos hábitos de desenvolvimento que o autor aplica atualmente
- É um artigo que organiza a experiência de se esforçar para evitar maus hábitos e criar bons hábitos, abordando 10 práticas que ajudaram a melhorar a produtividade e manter a qualidade
1. Manter commits pequenos
- Os commits devem ser mantidos o menor possível. Commits pequenos permitem reverter apenas um commit específico quando surge um bug, evitando conflitos de merge complexos
- O autor adota como regra que "deve ser possível fazer commit quando o software compila"
2. Refatoração contínua
- Conselho de Kent Beck: "Quando quiser mudança, primeiro torne a mudança fácil, e então faça a mudança fácil."
- Pelo menos metade dos commits deve incluir refatoração. Pequenas refatorações ajudam muito quando chegam requisitos maiores
- Grandes refatorações devem ser evitadas. Em vez disso, faça continuamente pequenas melhorias de até 10 minutos
3. A importância de implantar o código
- O código em si é uma dívida potencial, e código não implantado é a maior dívida de todas
- Testes trazem confiança, mas a implantação real representa a verdadeira aprovação
- Quanto maior a frequência de implantação, maiores podem ser os custos de hospedagem, mas confirmar que o trabalho mais recente realmente funciona é uma vantagem importante
4. Não testar funcionalidades do framework
- Não teste funcionalidades do framework. O framework já foi suficientemente validado
- Se os componentes forem mantidos pequenos, o framework fará a maior parte do trabalho, reduzindo a necessidade de testes
- Componentes grandes adicionam complexidade e, por isso, exigem muitos testes
5. Criar novos módulos
- Se uma determinada funcionalidade não se encaixa em um módulo existente, é melhor criar um novo módulo
- É melhor deixá-la como um módulo independente do que forçar a funcionalidade para dentro de um módulo existente
6. Aplicação flexível de desenvolvimento orientado a testes (TDD)
- Quando o design da API não está claro, escreva primeiro os testes para pensar do ponto de vista do "cliente"
- O TDD não é seguido como um princípio religioso. Quando necessário, é possível trabalhar em uma unidade maior primeiro e testar depois
- Não é preciso manter pequenas unidades de código em estado de falha, nem ficar preso a um dogmatismo que prejudica a produtividade
7. Ctrl+C/Ctrl+V só é permitido uma vez
- Copiar uma vez tudo bem, mas a partir da segunda cópia já existe duplicação
- Nesse ponto, a duplicação deve ser removida com a abstração adequada. Mesmo que a parametrização pareça um pouco estranha, ainda é melhor do que juntar várias implementações
8. Aceitar mudanças no design
- O design envelhece com o tempo. A refatoração pode retardar esse envelhecimento, mas no fim ele inevitavelmente muda
- Não se apegue demais ao design anterior; é preciso aceitar a mudança
- Não existe design perfeito, e a capacidade de lidar bem com mudanças é o núcleo do desenvolvimento de software
9. Três tipos de dívida técnica
- A dívida técnica pode ser classificada em três tipos:
- O que atrapalha o trabalho atual
- O que pode atrapalhar trabalhos futuros
- O que talvez possa vir a atrapalhar
- A dívida do primeiro tipo deve ser minimizada, o foco deve estar no segundo tipo, e o terceiro tipo deve ser ignorado
10. Relação entre testabilidade e bom design
- Se é difícil testar, há grande chance de haver um problema no design
- O design dos testes também pode ser melhorado. Por exemplo, se for difícil criar um mock de
em.getRepository(User).findOneOrFail({id}), é melhor separá-lo em uma função própria ou usar utilitários de teste
- A razão de os testes não serem escritos é que eles são difíceis de testar, e isso pode ser um problema de design
9 comentários
Pelo visto, mais importante do que
DRYé atingir oSRP; assim, mesmo deixando na mão da IA, ela tende a não falar besteira.Acho que o mais importante é o quanto você conseguiu criar um código e um ambiente que consigam se adaptar rapidamente às mudanças.
E, por meio de uma abstração adequada, é possível aumentar a reutilização e a escalabilidade do código, além de maximizar a velocidade de desenvolvimento com o uso de ferramentas de IA.
Texto realmente excelente. Dá vontade de recomendar por toda parte.
Aceite mudanças, faça copiar e colar só uma vez, melhore os testes, faça commits menores...!
Bom texto.
Acho que vale muito a pena ver o original deste texto. Sempre que é uma notícia que me interessa, costumo olhar a fonte original, mas neste caso isso parece ainda mais importante. No item 1, por exemplo, no texto original está: Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. mas aqui foi resumido como "é preciso manter os commits o menor possível"...
Que texto realmente excelente.
O item 7 é realmente muito bom.
Comentários do Hacker News
É melhor usar parâmetros para evitar várias implementações. Melhorar os parâmetros é mais fácil do que unificar várias implementações.
Copiar código uma vez tudo bem, mas a partir da segunda vez deve-se evitar duplicação. Boas abstrações devem ser criadas quando houver dados suficientes.
DRY (não se repita) ou WET (escreva tudo duas vezes) não são regras absolutas. O problema difícil é entender a duplicação de código e o momento de unificá-lo.
Como alternativa a commits pequenos, é possível adicionar um novo commit que corrige o bug sem reverter um commit grande.
Testabilidade está relacionada a um bom design. Algo que não pode ser testado facilmente pode ser um sinal de que o design precisa mudar.
É preciso ter cuidado ao testar funcionalidades do framework. Frameworks podem mudar com o tempo.
Sobre o tamanho dos commits, deve-se buscar commits que possam ser revertidos com facilidade caso seja necessário desfazer uma mudança específica.
As empresas querem uma base de código estável, mas refatoração contínua é necessária. Isso pode entrar em conflito com a estabilidade.