Clean Code (Código limpo)

Em software, 80% ou mais do que fazemos é curiosamente chamado de “manutenção” ou seja, gastamos mais tempo arrumando que fazendo novo. Outro ponto importante é que abandonamos nosso código cedo, não porque está pronto, mas porque nosso sistema de valores se concentra mais na aparência externa do que na substância do que entregamos.

Eis então a importância de se ter um código limpo. Mas nem a arquitetura nem o código limpo insistem na perfeição, apenas na honestidade e em fazer o melhor que podemos. Isso não é fácil, boas práticas de software requerem essa disciplina: foco, presença de espírito e pensamento

Introdução

Existem duas partes para aprender una arte: conhecimento e trabalho.

Você deve obter o conhecimento dos princípios, padrões, práticas e heurísticas que um artesão conhece, e também deve triturar esse conhecimento em seus dedos, olhos e mente, trabalhando duro e praticando constantemente.

Aprender a escrever código limpo é um trabalho árduo. Requer mais do que apenas o conhecimento de princípios e padrões. Você deve suar sobre isso. Você deve praticar sozinho e observar a si mesmo fracassar. Você deve observar os outros praticarem e falharem. Você deve vê-los tropeçar e refazer seus passos. Você deve vê-los agonizando com as decisões e ver o preço que pagam por tomar essas decisões da maneira errada.

Aprender esses conceitos exigirá tempo e esforço, mas tenho certeza que vai valer a pena.

Sobre Código Limpo

Lembre-se de que o código é realmente a linguagem em que expressamos os requisitos e assim como os requisitos queremos poder lê-los de forma organizada e padronizada.

Todos nós já sentimos o alívio de ver nosso programa bagunçado funcionar e decidir que uma bagunça funcionando é melhor do que nada. Mas lembre-se da lei de LeBlanc: Mais tarde é igual a nunca.

Conforme a bagunça aumenta, a produtividade da equipe continua diminuindo, aproximando-se assintoticamente de zero. À medida que a produtividade diminui, a administração faz a única coisa que pode, eles adicionam mais pessoas ao projeto na esperança de aumentar a produtividade. Mas essa nova equipe não tem conhecimento no design do sistema. Eles não sabem a diferença entre a mudança que corresponde à intenção do projeto e uma mudança que causa dano ao projeto. Além disso, eles e todos os outros membros da equipe estão sob forte pressão para aumentar a produtividade. Então, todos eles fazem mais e mais bagunça, levando a produtividade cada vez mais para zero.

Atitude do desenvolvedor

Os usuários nos procuram para validar a forma como os requisitos vão caber no sistema. Os gerentes de projeto nos procuram para ajudar a definir o cronograma. Os profissionais de marketing nos procuram em busca das informações que precisam para fazer promessas e compromissos com clientes, e mesmo quando todas estas pessoas não olham para nós, não devemos ter vergonha de dizer a eles o que pensamos.

Somos profundamente cúmplices no planejamento do projeto e compartilhamos grande parte da responsabilidade por quaisquer falhas; especialmente se essas falhas tiverem a ver com código ruim!

O grande dilema

Quase todos os desenvolvedores sabem que as bagunças anteriores os atrasam. E ainda assim todos os desenvolvedores sentem a pressão para fazer bagunça a fim de cumprir prazos.

Os verdadeiros profissionais sabem que se você não vai cumprir o prazo fazendo bagunça. Na verdade, a bagunça vai atrasá-lo instantaneamente e forçá-lo a perder o prazo.

A arte do Código Limpo?

Um programador que escreve código limpo é um artista que consegue passar uma tela em branco por uma série de transformações até que se torne um sistema elegantemente codificado.

“O código limpo sempre parece ter sido escrito por alguém que se importa”

– Michael Feathers

“Você sabe que está trabalhando em um código limpo quando cada rotina que lê acaba sendo praticamente o que você esperava”

– Ward Cunninghan

A proporção de tempo gasto lendo e escrevendo é bem mais de 10:1. Ou seja, estamos constantemente lendo códigos antigos como parte do esforço para escrever novos códigos. Como essa proporção é tão alta, queremos que a leitura do código seja fácil, mesmo que torne a escrita mais difícil.

Então se você quiser que seu código seja fácil de escrever, torne-o fácil de ler.

A má notícia é que escrever um código limpo é muito parecido com pintar um quadro. A maioria de nós sabe quando uma pintura é boa ou ruim. Mas ser capaz de reconhecer a boa arte da má não significa que sabemos pintar.

A regra do escoteiro

“Deixe o acampamento mais limpo do que o encontrou”

Ao contrário do que muito desenvolvedor pensa, a limpeza não precisa ser algo grande. Melhore um nome de variável, quebre uma função que seja um pouco grande em outras menores, elimine um pequeno pedaço de duplicação, limpe uma instrução if composta. Estas pequenas ações vão se somando e com o tempo o código se torna cada vez mais limpo.

Conclusão

Livros e artigos sobre arte não prometem fazer de você um artista. A mesma coisa vale com estes artigos, tudo o que eles pode fazer é mostrar os processos de pensamento de bons programadores e os truques, técnicas e ferramentas que eles usam.

Sobre os artigos

Primaira Parte: os artigos Nomes, Funções, Comentários, Formatação e Objetos e estrutura de dados podem ser agrupados pois todos tratam de decisões de baixo nível.

Segunda parte: Os artigos Manipulação de erros e Limites vão falar sobre como tratar erros e interação com sistemas externos.

Terceira parte: cobre testes unitários

Quarta parte: cobrem conceitos de desenho de alto nível: classes e Design Emergente

Quinta parte (em desenvolvimento): Concorrência