PHP 5.1, ASP ou Java – Código bom não depende da linguagem

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

Poderia ser assim

Péssima prática

Poderia ser assim

2. Nomes pronunciáveis e palavras no mesmo idioma

Péssima prática

Poderia ser assim

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.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Time limit is exhausted. Please reload CAPTCHA.