Quer ver eu te fazer uma pergunta que te fará pensar o resto do dia? Como olhar para um código e dizer que ele é de qualidade? Essa é sem dúvida uma pergunta que todos nós tentamos responder todos os dias.
Como bem sabemos, podemos olhar trechos de código por vários pontos
de vista diferentes: o quão complexo ele é (muitos ifs, muitas linhas), o
quão coeso ele é, o quão acoplado ele é, etc. Sendo tão difícil pensar
em qualidade de código, vamos tentar mudar o nível. Quando que um
sistema tem qualidade interna, ou seja, do ponto de vista de código?
Nós gostamos de sistemas que sejam fáceis de mexer. Ou seja,
quando o usuário final pede uma mudança, é relativamente fácil de
localizar onde ela deve ser feita e, depois de feita, não há propagação
de problemas.
Para que isso aconteça, o código deve estar bem modularizado; cada
classe deve ter sua responsabilidade, e as relações entre elas devem
estar bem definidas. É aqui que entra a ideia do código sólido,
princípios criados por Michael Feathers e popularizados pelo Uncle Bob há bastante tempo.
A brincadeira com o termo “código sólido” vem do acrônimo SOLID. Cada
letra representa um dos 5 princípios de orientação a objetos que nos
ajudam a manter o código organizado:
Test-Driven Development (TDD), sem dúvida, tornou-se uma das práticas mais populares entre
desenvolvedores de software. A ideia é bem simples: escreva seus testes antes mesmo de escrever o
código de produção. Mas por quê a ideia parece tão boa? Ao escrever os testes antes, o desenvolvedor
garante que boa parte (ou talvez todo) do seu sistema tem um teste que garante o seu funcionamento.
Além disso, muitos desenvolvedores também afirmam que os testes os guiam no projeto de classes do sistema.
Mesmo com toda a indústria gritando as vantagens para quem queira ouvir, ainda existem
mitos em torno da prática. O desenvolvedor agora vai gastar mais tempo escrevendo
testes do que programando? Escrever testes dá trabalho. Testes manuais não são mais
produtivos? TDD deve ser feito 100% do tempo?
Este guia visa responder essas e outras perguntas para você, que é desenvolvedor, gerente,
ou está de alguma forma relacionado ao processo de desenvolvimento de software.