Em mais de 15 anos trabalhando e produzindo sistemas para web tenho escutado muitas discussões tolas, ironias e sarcasmos sobre o uso de tecnologias A, B ou C. Pense bem, se os problemas das coisas feitas com má qualidade em software estivesse relacionado a linguagem, ou a versão do servidor, tipo de framework, etc, nunca teríamos certeza se o que estamos desenvolvendo hoje tem qualidade ou não, se o Uncle Bob tem razão, ou se o Martin Fowler tem mesmo autoridade para falar de código, afinal de contas, se a qualidade depende da ferramenta então seria impossível coisas bem produzidas nas décades de 1970, 80 e 90. Se é apenas com Python ou Ruby e suas belas indentações forçadas que podemos escrever arte através de códigos, o papel do programador é de mero coadjuvante, sem importância alguma.
Felizmente todos nós sabemos que construir software de qualidade está nas mãos de quem o faz. As aberrações em abundância que costumamos encontrar em códigos fontes não são responsabilidade da linguagem. A lentidão da aplicação não é culpa do Java, assim como as falhas de segurança não são culpa do PHP. Nem mesmo a culpa é exclusiva da aplicação ASP que estoura erros na tela do usuário.
Quando um prédio desaba a culpa é da qualidade do cimento ou do engenheiro medíocre que não calculou corretamente?
Seja o típico sistema que só funciona na minha máquina, ou o código que não resiste a uma atualização. O desenvolvedor consciente e que é profissional de verdade conhece e assume a sua responsabilidade.
Eu não sou um grande programador; Sou apenas um bom programador com excelentes hábitos.
Kent Beck
Qualquer tolo pode escrever código que um computador consiga entender. Bons programadores escrevem código que HUMANOS consigam entender.
Martin Fowler
Seguem algumas recomendações do livro Clean Code, escrito por Roberto C. Martin e que facilitam muito a vida, não apenas quando você escreve código, mas principalmente, quando você precisa alterá-lo.
1. Nomes significativos e que revelem a intenção
Péssima prática
|
1 |
int x; // dias do ano |
Poderia ser assim
|
1 |
int diasDoAno; |
Péssima prática
|
1 2 3 4 |
public List<int> get() { ... } |
Poderia ser assim
|
1 2 3 4 |
public List<int> getDay() { ... } |
2. Nomes pronunciáveis e palavras no mesmo idioma
Péssima prática
|
1 2 3 4 |
function getNomUsu { ... } |
Poderia ser assim
|
1 2 3 4 |
function getName() { ... } |
3. Nomes de classes
Use substantivos. Exemplo: Cliente, Carro, Perfil, etc.
4. Nomes de métodos
Use verbos. Exemplo: salvar, excluir, editar, etc.
5. Regras para funções/métodos
Faça uma coisa só. Lembre-se do SOLID e da regra de responsabilidade única. Evite “if”. Geralmente, evidenciam que o método faz mais de uma coisa.
Resumindo a ópera: código e sistemas ruins evidenciam as qualidades de quem fez e não das tecnologias utilizadas.
Como melhorar? Nunca parar de ler os melhores, estudar continuamente e praticar. As tecnologias evoluem muito e rapidamente e quem acha que sabe tudo fica para trás. Se você não gosta de alterar código ruim, reclama dos programadores que já colocaram a mão em tal código, então faça o mínimo: não produza esse tipo de código.