quinta-feira, janeiro 22, 2009

Benefícios do código limpo e o custo total de ser proprietário de uma bagunça

Se você já foi um programador por algum tempo, provavelmente já teve de codificar mais lentamente devido a código ruim e mal feito. O grau de lentidão varia e muitas vezes é significativo. Equipes que se movem rapidamente no início do projeto podem se encontrar mancando a passos de tartaruga alguns meses depois. É aquela situação em que qualquer mudança, por mais trivial que seja, quebra outras partes do código e é feita com medo do impacto que irá gerar.

Conforme o tempo vai passando a bagunça e o lixo aumentam e se tornam tão grandes e tão profundos que ninguém mais consegue limpá-los. Quanto mais a bagunça do código cresce, mais a produtividade do time cai. Os gerentes acham que podem ajudar e fazem a única coisa que está em seu poder: contratam mais gente para manter o sistema. Porém, esse novo pessoal não conhece os meandros do sistema. E o pior, para conhecerem vão levar muitos meses e ainda impactar nas atividades dos desenvolvedores que conhecem (essa é a famosa lei de Brooks: "Incluir mais gente em um projeto atrasado vai atrasá-lo ainda mais"). Vão ainda gerar mais bagunça e mais código macarrônico.

Eventualmente a equipe e/ou os gerentes se revoltam e declaram que não conseguem mais trabalhar com essa base de código odiosa. A alta gerência não quer gastar tanto para refazer todo o sistema, mas também sabe e percebe que a produtividade é horrenda. Eventualmente acabam aceitando e construindo um sistema do zero, mas com as mesmas funcionalidades, para substituir o código antigo. Eu já vi esse filme algumas vezes na minha vida profissional. Você também já viu? Quem já viu sabe, portanto, que manter o código limpo de forma contínua não é apenas mais barato que deixar bagunça. É também uma questão de sobrevivência profissional.


Muitas vezes os programadores são pressionados para fazer o código de qualquer jeito, para atender seus prazos e cronogramas. Muitas vezes precisam também passar horas em claro vomitando linhas e linhas de código ruim. Temos que frisar outro ponto importante, tanto para desenvolvedores como para seus gerentes: Vocês NÃO cumprirão o prazo fazendo bagunça e escrevendo código porcaria. Pelo contrário, a sujeira vai te atrasar instantaneamente e irá forçá-lo a estourar o prazo. A ÚNICA forma de cumprir o prazo e a única forma de se mover rápido é manter o código o mais limpo possível o tempo todo.

Portanto, para ser um excelente programador siga sempre a regra dos escoteiros: Deixe a área do acampamento ainda mais limpo do que quando você a encontrou. Isto é, não limpe só o seu código mas também o código de outros que você precisa modificar. Não precisa ser uma mudança gigantesca. Mude o nome de uma variável para algo que faça mais sentido, quebre um método que esteja muito grande, elimine alguma duplicação de código, refatore um conjunto de ifs encadeados. Se todos limparem um pouquinho de código a cada check-in, a base de código sempre se manterá organizada e limpa.

Vamos supor que agora você acredite que escrever código tosco, ruim, fedido e macarrônico gera impedimentos significativos. Vamos dizer que você aceita a idéia de que a única forma de desenvolver com velocidade alta é ter uma base de código limpo. Você então deve estar se perguntando: "Como eu posso escrever código limpo? E mais, como posso identificar se um código é limpo ou não?". Bom, é aí que entra algo que todos os desenvolvedores deveriam fazer mais em suas carreiras: LER!

Algumas dicas iniciais de livros (há muitos mais, mas é melhor começar com os melhores :-) !) que te farão um melhor programador (confie em mim e leia os livros abaixo todinhos. Mas não leia apenas... ATUE no seu dia a dia usando o que aprendeu):

- Clean Code de Robert Martin
- Code Complete de Steve McConnell
- Emergent Design de Scott Bain

Vamos buscar uma maior qualidade e produtividade para a área de TI e todos sairão ganhando: clientes, fornecedores, desenvolvedores e o Brasil.

2 Comentários:

At 1:35 PM, Blogger Bruno disse...

Olá Papo,
Gostaria de lhe agradecer pelos bons concelhos apesar de serem gratuitos (parafraseando o velho ditado)... :)

Percebi que és um cara iterado a respeito de métodos de desenv. de software especialmente os Ágeis, então gostaria de compartilhar contigo uma dúvida.

Sempre me vem uma questão à mente que não costuma calar; Por que se investe tanto na criação de padrões e literaturas que falam da Qualidade de Padrões e Processos de construção Software e numca em Qualidade de Código?

Vamos imaginar um projeto seguindo as boas práticas do ITIL/CMMI/PMBOK/RUP/Agile... ainda vejo que com todas essas boas práticas, e instruções dadas por esses métodos (processos, bibliotecas, etc...) não conseguem por sí só salvar um projeto de um fracasso ou pelo menos de um atraso eminente! Aí me vem a cabeça a história da Qualidade de Código. Sem dúvidas isso trará inúmeros benefícios como facilidade e redução de custos de manutenção e integração. Agora por que cargas d'agua isso não é uma preocupação da indústria de eng. de software? pelo menos não ouço nenhuma grande empresa comentando ou demonstrando essa preocupação em projetos de software, confiando apenas na boa índole e experiência de cada programador.

Será que estou falando alguma grande bobagem?

Obrigado desde já.

abraços,

 
At 11:11 PM, Blogger Irmão mais velho disse...

Olha, em poucas palavras, vi meu trabalho em seus poucos paragráfos.
Ótimo texto..

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas