Desenvolvimento de Software A Prtica do Clean Code

Em dezembro de 2013, comecei a ler o livro Clean Code do autor Robert C. Martin e devo dizer que aprendi muita, muita coisa
com ele. Para quem se recorda, na parte 9 sobre dicas para o desenvolvimento de um software fiz uma breve introduo ao Clean Code, como
tambm venho elaborando alguns artigos recentes sobre este assunto.
Imagem via Shutterstock
Hoje dia de entrar um pouco mais nos detalhes dessa prtica e conhecer algumas orientaes de como empreg-la. Limpeza no
cdigo j!
Antes de iniciar o artigo, gostaria de fazer um agradecimento ao Rmulo Pelachini, um mega profissional em programao, pela
gentileza em me emprestar o livro. Valeu, Rmulo!
Todos ns, desenvolvedores, temos o desejo de ver o nosso cdigo funcionando da melhor forma, no ? Quando digo
funcionando, no me refiro apenas execuo correta da funcionalidade, mas tambm qualidade do cdigo e o nvel de expressividade
que ele expe. Afinal, quando implementado um cdigo, o resultado ser visto tanto pelo cliente quanto por ns mesmos. Quem j no se
deparou com um cdigo antigo e ficou por horas interpretando a lgica? Quem j no teve de refazer blocos de cdigo por causa da falta de
clareza? A propsito, vou deixar a questo da expressividade para outro artigo.
O conceito de Clean Code foi elaborado justamente para evitar a ilegibilidade do cdigo e aprimorar a qualidade da nossa
codificao. Na verdade, um conjunto de prticas que deve ser adotado por qualquer programador que queira ser reconhecido como um
bom profissional. Porm, ao contrrio do que muitos pensam, no basta somente ler um livro e acreditar que j conhece as diretrizes do Clean
Code. preciso prtica, raciocnio e, acima de tudo, determinao para produzir algo de qualidade. Por esse motivo, decidi reunir alguns
pontos apresentados no livro e compartilh-los aqui no PTI para disseminar essa prtica. Leia-os atentamente e lembre-se deles ao
implementar o seu prximo cdigo.

1) No possvel criar um cdigo limpo de primeira
Por mais que um desenvolvedor tente, praticamente impossvel. Claro, extremamente importante que um desenvolvedor j
comece a programar com as diretivas do Clean Code em mente mas, eventualmente, ele acabar voltando ao cdigo para refatorar ou
renomear alguns mtodos que ficaram passveis de m interpretao. No entanto, isso perfeitamente natural. Quando iniciamos uma nova
implementao, no sabemos exatamente quais, quantos e como sero os mtodos que devemos implementar. medida que o cdigo vai
tomando forma que comeamos a nossa limpeza.

2) Pare de programar quando notar que o cdigo est ruim
Evite implementar o cdigo por completo e s depois partir para o Clean Code. A limpeza deve ser feita aos poucos, caso contrrio,
bem provvel que o desenvolvedor perca o foco do cdigo como um todo. Aquela ideia de vou deixar assim por enquanto e depois eu volto
para arrumar uma passagem grtis para o esquecimento. Portanto, quando perceber que o cdigo est tomando propores inadequadas e
apresentando sinais de duplicao, interrompa a implementao e faa uma limpeza antes de continuar. Na verdade, a mesma situao de
um bloco de cimento recm aplicado: aproveite para arrum-lo enquanto ainda no est seco. Se ele secar, o trabalho de remov-lo ou
reform-lo ser muito mais difcil.

3) Aprenda a programar com pacincia
Um dos efeitos do Clean Code o trabalho constante de remover e adicionar o mesmo cdigo repetidas vezes. Isso faz parte do
processo de maturidade para alcanar o nvel ideal de qualidade. J perdi a conta das vezes que criei, alterei, removi, criei novamente e
renomeei uma classe. A cada etapa, eu levantava um ponto de vista diferente do cdigo e o alterava para torn-lo mais claro.
Como analogia, imagine que voc tenha acabado de se mudar para uma nova casa e est organizando os mveis da sala para
descobrir qual a acomodao mais confortvel. Para isso, voc provavelmente precisar mudar os mveis de lugar vrias vezes, concorda?
Esse o sentido! Assim como voc busca a melhor disposio dos mveis na sala, tambm deve buscar a melhor organizao do cdigo no seu
programa. Aproveitando a analogia, lembre-se de que, da mesma forma que voc receber visitas na sua sala, o seu cdigo tambm receber
visitas de outros programadores.
Em concluso, se voc deseja criar um cdigo limpo e com qualidade, esteja preparado para desfazer e refazer blocos de cdigo
quantas vezes forem necessrias.

4) Considere a codificao como uma atividade de risco
Se um requisito funcional no documentado, simples refazer a documentao. Se houve uma falha na estimativa, fcil refazer
o cronograma. Porm, se um cdigo estiver ruim, refaz-lo algo demorado e, muitas vezes, custoso. Alm disso, no se garante que ele ter
o mesmo funcionamento como antes.
Devemos nos comprometer com a relevncia da nossa codificao, visto que o resultado do cdigo (e, consequentemente, da
funcionalidade) est intimamente relacionado com o nosso nvel de responsabilidade. A ideia aqui no pressionar a conscincia do
programador e penaliz-lo por construir um cdigo imperfeito, mas apenas sugerir que ele considere a importncia dessa atividade no ciclo de
vida do projeto.

5) Aumente a sua sensibilidade ao cdigo
Conforme utiliza as prticas do Clean Code, o desenvolvedor produz e amplia uma habilidade conhecida como sensibilidade ao
cdigo. Este termo se refere capacidade de visualizar um cdigo mal escrito e imediatamente pensar em diferentes formas de limp-lo.
Renomear variveis, desfazer blocos aninhados, refinar condies, extrair mtodos e at mesmo considerar alternativas mais viveis
para tratar as regras de negcio so exemplos de sensibilidade tcnica de um profissional. Quanto maior for este nvel de sensibilidade, melhor
sero as solues propostas e desenvolvidas pelo desenvolvedor.

6) Codifique pensando na leitura
Uma boa recomendao para praticar o Clean Code implementar o cdigo j imaginando que outro desenvolvedor futuramente
ir interpret-lo. Na realidade, isso ir acontecer! Portanto, procure ler cada mtodo logo aps implement-los e mea o nvel de legibilidade.
Ou ento, tente se colocar no lugar de outra pessoa e encontre as dificuldades que ela possivelmente teria ao ler o seu cdigo. Embora parea
uma tarefa maante, at gratificante, j que voc acaba contemplando a qualidade do seu prprio cdigo.
Leitores, sei que o artigo ficou um pouco extenso, mas espero ter transmitido as premissas adequadas para comear a praticar
o Clean Code. Continuarei elaborando alguns artigos sobre este assunto nos prximos meses. Aguardem!
Um grande abrao a todos e at a prxima!

Programao: Como escrever um cdigo limpo?
Todos ns estamos cansados de ouvir o quanto escrever um bom cdigo essencial para o desenvolvimento de qualquer projeto,
e que caso no sigamos essa linha de pensamento teremos os ruins e velhos problemas conhecidos, como por exemplo:
Problemas com a leitura do cdigo: um cdigo mal escrito o torna ilegvel, fazendo com que o prprio desenvolvedor que
o escreve, caso volte a ler aquele trecho algum tempo depois, corre o risco de no entender o que ele mesmo havia escrito.
Problemas com manutenibilidade: um cdigo ilegvel consequentemente dificulta a manuteno e extenso das
funcionalidades do sistema, fazendo com que esse processo seja complicado e desgastante para o programador que venha a execut-lo.
J ouvi muito na faculdade a seguinte frase: s trs da madrugada de um domingo voc no enxerga mais nada (Prof. Dr. talo
Vega). Esta frase est intimamente ligada ao fato da importncia de voc ter um cdigo limpo e bem escrito. Pense na seguinte situao: voc
procurando um bug em uma funo que no foi voc quem a escreveu, e s 19hrs de uma sexta-feira, em uma aplicao que entrar em
produo no sbado (o que muito comum de acontecer). Se caso o programador que tenha escrito aquela funo, um simples pedao da
aplicao, no tenha se preocupado com uma boa prtica em codificao provavelmente far com que voc fique madrugada dentro lendo e
relendo todas aquelas linhas at entender o que de fato elas fazem, at encontrar o erro e finalmente corrigi-lo.
Levar mais tempo para fazer manuteno significa que voc gastar mais dinheiro para estender ou corrigir pequenas
funcionalidades, e gastar dinheiro alm do previsto uma das coisas que nenhum gerente de projetos gosta.
Sendo assim, como podemos codificar de modo que tenhamos um cdigo limpo, legvel e produtivo?
Alguns princpios bsicos envolvem:
Escolher bons nomes para suas variveis, nomes significativos e que estejam de acordo com o contexto empregado so to
importantes quanto todo o cdigo escrito. Dar bons nomes as suas variveis faz com que todos que leiam seu cdigo compreendam o real
motivo dela estar sendo utilizada, facilitando a leitura e compreenso do cdigo.
Uma funo deve fazer apenas UMA coisa - leia isso novamente! Uma funo que desempenha mais de uma tarefa torna
ainda mais complexa a sua compreenso e se transforma em uma funo bombril, um pedacinho de cdigo com mil e uma utilidades, o que
na hora da manuteno se tornar em um monstro de 7 cabeas, ou dependendo do cdigo escrito 7^7 cabeas.
Dar bons nomes a funes to importante quanto dar bons nomes a variveis, os nomes dados a funes devem
expressar literalmente o que elas fazem de modo que um programador no precise ler o cdigo inteiro de uma funo para entender o que ela
faz. Um problema ainda muito encontrado so funes em que seu nome no possu nenhuma relao com o cdigo que descreve o seu
verdadeiro comportamento, o que ir confundir o desenvolvedor que usar est funo pois ele perceber que o que ela promete cumprir no
condiz com o que ela de fato faz.
A melhor forma de darmos bons nomes a funes e variveis fazermos uma anlise do domnio do problema que estamos
tentando solucionar, assim podemos extrair boa parte dos nomes que representam de fato os elementos que usaremos para solucionarmos o
problema.
Ainda falando sobre funes um outro aspecto muito importante o seu tamanho, funes no devem ser grandes demais
e caso sejam isso um sinal de que algo est errado. No podemos definir exatamente o que um tamanho bom ou o que um sinal de que
temos um problema vista, antigamente programadores consideravam o tamanho da tela uma boa mtrica para o tamanho de funes
porm hoje em dia temos diversos tamanhos de monitores, o que faz com que essa no seja a maneira correta de medirmos o tamanho de
uma funo. Podemos considerar uma funo de tamanho ideal quando a sua quantidade de linhas est na faixa de 15 a 20 linhas, o que
suficiente para desempenhar apenas uma atividade, mas claro que em alguns momentos isso pode variar para mais ou para menos
dependendo do contexto que a qual funo pertence fazendo com que tenhamos que usar o bom senso.
Princpios como estes nos ajudam a desenvolver cdigos de maior qualidade, fazendo com que tenhamos maior produtividade e
torne prazerosa a escrita de qualquer que seja a funcionalidade que o sistema exija, influenciando na manutenibilidade e complexididade do
que produzido, ou seja, so de extrema importncia em nosso dia-a-dia.
Recomendo como leitura sobre boas prticas e como escrever um bom cdigo o livro Cdigo Limpo de Robert C. Martin, este
livro trata a fundo estes pontos e muitos outros considerados indispensveis para que possamos obter um cdigo bem escrito e funcional.
Ame o seu cdigo, pois ele descreve o profissional que voc .

Regra de negcio: um desafio para o desenvolvedor
Ns conhecemos a linguagem de programao, a sintaxe, os componentes e a ferramenta, mas para desenvolvermos um sistema
preciso conhecer tambm a Regra de Negcio do cliente, tambm conhecida como Domnio da Aplicao. Este um dos desafios que todo
programador encara no incio de um projeto ou de um emprego, ao menos que ele j conhea a regra de negcio por experincias anteriores.
Bem, existem softwares para diversas finalidades, como controle de estoque, administrao financeira, contabilidade, emisso de
pedidos, recursos humanos, entre outros. Cada um desses sistemas respeita uma srie de validaes, restries e funcionalidades para que a
sua utilizao seja objetiva, ou seja, atenda as necessidades apontadas pelo cliente. Em um sistema de controle de estoque, por exemplo, a
regra de negcio basicamente consiste nas entradas e baixas da quantidade dos produtos quando uma nota entra no sistema ou quando o
produto vendido. Todo esse fluxo de entradas e sadas deve ser controlado pelo software por meio de banco de dados, funes e
procedimentos implementados pelo programador. Um simples erro na semntica do cdigo ou na execuo de uma funo pode afetar o
controle desses dados no sistema, que por sua vez, no armazenar informaes ntegras.
J a regra de negcio de um sistema contbil diferente. preciso conhecer leis, tributaes, cdigos contbeis e impostos para
desenvolver um sistema eficiente para este ramo. Eis que surge uma observao: nem todos os desenvolvedores conhecem as regras de
negcio (ou domnio da aplicao) para qual o sistema ser desenvolvido. Cabe a ele pesquisar, informar-se com outros profissionais e
compreender como as engrenagens do sistema funcionam. Apesar da complexidade, existem regras de negcio que possuem caractersticas
semelhantes e ajudam desenvolvedores a reduzir a dificuldade em aprender um novo segmento.
Na maioria das vezes, o desenvolvedor contratado para trabalhar em um sistema que j est desenvolvido, e para isso, preciso
que ele conhea toda a regra de negcio antes de comear a produzir cdigo. O tempo de adaptao relativo, embora muitas empresas
busquem reduzir este tempo por meio de cursos e treinamentos. Normalmente em dois ou trs meses j possvel adquirir um conhecimento
mediano sobre o domnio da aplicao do sistema.
Uma forma simples e rpida de abranger a regra de negcio comunicar-se com o cliente. Agendar visitas e acompanhar, nem que
for por um dia, os processos operacionais do cliente (ou empresa) j denota uma grande base de conhecimento. Conversar com o cliente
tambm essencial, pois, afinal, ele quem est adquirindo o software e conhece completamente a rea de negcio da empresa. E lembre-se:
faa perguntas, pea explicaes e simule cenrios. Cada detalhe sobre a regra de negcio muito importante!
Mesmo assim, se voc um desenvolvedor e atualmente se encontra no tipo de situao citada neste artigo, no h o que se
preocupar. Nada como a prtica do dia-a-dia para aprender cada vez mais sobre a regra de negcio do cliente. Em pouco tempo, voc tambm
estar sugerindo melhorias nos processos do cliente e criando novas rotinas para aprimorar o software.
Caro desenvolvedor, boa sorte no seu trabalho!
Papinho de TI: Melhoria Contnua
Nosso papinho de TI de hoje, sobre melhoria contnua. O famoso PDCA: Planejar, Executar, Avaliar, Agirdo nosso amigo
Edward Demig, que para alguns o pai do controle de qualidade moderno resume na minha viso o que a melhoria contnua.
A melhoria contnua nada mais do que repetir continuamente um mtodo para realizar um processo, de forma que possamos
aprimorar o mtodo para conseguir fazer o processo cada vez melhor, mais rpido e mais barato.
E como podemos melhorar continuamente os processos da TI? Aqueles processos do ITIL que estamos implementando? Na minha
viso, h uma maneira apenas: Escrever o mtodo e mais importante: repetir..repetir..repetir o que est escrito. As ISOs, que todas as
empresas desejam ter, servem entre outras coisas para verificar se os procedimentos adotados pela organizao so os mesmos que esto
escritos nas nossas Intranets. Por que ser? Porque sem repetio no h melhora. cincia!
Oscar Schmitd, o melhor jogador de basteque do Brasil que vi jogar, o mo santa, que destruiu junto com seus companheiros os
EUA no pan-americado de Indianpolis em 1987, o que significa o mesmo se os EUA ganhassem hoje a copa de 2014 no Brasil, tinha uma
receita para ser to bom nos arremessos: Treino, treino, treino.
Uma vez numa entrevista, um apresentador perguntou para o Oscar sobre o dom para o basquete que ele tinha. O Oscar
respondeu: Dom? Que nada, treinei muito, sou o cara que mais treinou nessa vida. Minha mo no santa, treinada! Depois dos treinos, a
esposa dele ficava com ele no ginsio para buscar as bolas que ele arremessava, para que ele no perdesse tempo e o treino rendesse mais.
Achei a reportagem que comentei no youtube http://www.youtube.com/watch?v=C0n7WJt7L-8&feature=related. Um vdeo de
6:45 minutos, vale pena conferir. Tem outro tambm interessante: http://www.youtube.com/watch?v=IgvOTzIS4WQ&feature=related.
E voc vem aprimorando seus mtodos ?


Qual a melhor linguagem de programao?
Ultimamente tenho visto muitos usurios questionarem sobre a melhor linguagem de programao, principalmente em fruns de
desenvolvimento. E essa, sem dvidas, uma questo relativamente polmica. A influncia cada vez maior da tecnologia da informao na
vida pessoal e corporativa trouxe o surgimento de novos recursos e linguagens para o desenvolvimento de sistemas desktop e web.
Atualmente o leque de opes vasto, e cabe ao desenvolvedor estudar e utilizar a linguagem que mais preenche o foco do seu objetivo.
A lgica de programao a mesma, a diferena est nos recursos e as tecnologias que cada linguagem traz consigo. Cada
linguagem tem suas vantagens e desvantagens quando comparada s outras, formas diferentes de declarar variveis e funes, definies de
blocos de cdigos distintas e utilizao de conceitos de Orientao a Objetos.
Mas enfim, vamos ao que interessa: um exemplo prtico!
Certa vez, uma entidade educacional me convidou para ministrar aulas particulares de Delphi para uma garota que estava
interessada em aprender programao. Logo no primeiro dia, ela disse que ouviu falar bem da linguagem, e que muitas empresas a utilizavam
para desenvolver softwares por fornecer bons componentes para desenvolvimento desktop.
J no segundo dia de aula, para minha surpresa, ela foi at a coordenao dizendo que no queria mais aprender Delphi, e sim
Java! Aps algumas pesquisas na Internet, ela observou que o Java cresceu nos ltimos anos devido sua compatibilidade e portabilidade, e
que programadores em Java seriam uma grande demanda no mercado de trabalho.
Pois bem, eu aceitei a sua deciso, apesar de nunca ter trabalhado com Java. No terceiro dia, ela novamente me surpreendeu por
mais uma vez mudar de idia agora o seu foco era aprender C#, pois essa era a linguagem que estava sendo lecionada na maioria das
instituies de ensino no Brasil. Isso foi o suficiente: eu disse ela a mesma coisa que o meu professor na poca do curso tcnico de
informtica disse turma:
No procure aprender uma linguagem simplesmente porque ela est na moda, mas sim aquela que voc mais se identificou.
E exatamente o que acontece com desenvolvedores atuais. Muitos tentam migrar de uma linguagem para outra pelo fato de
ouvirem falar que a melhor linguagem de programao. Portanto, venho com a resposta do ttulo deste artigo: no existe a melhor
linguagem de programao, e sim aquela que voc mais se identifica. Se voc se sente vontade com a linguagem e nota que a sua
produtividade bem maior, ento continue programando nesta linguagem e procure aprimorar seus conhecimentos sobre ela. Um sistema
desenvolvido na linguagem que voc se identifica com certeza proporcionar melhores resultados do que um sistema desenvolvido em uma
linguagem que voc se adaptou, mesmo que essa linguagem tenha mais recursos.
Porm, vale ressaltar uma observao: no mundo da informtica uma das exigncias acompanhar a evoluo das tecnologias. Se
a linguagem de programao que voc utiliza no fornece suporte para as tecnologias atuais, como touch-screen, multi-camadas, mobile,web
services e IntraWeb, talvez seja hora de estudar uma nova linguagem de programao, apesar de que em geral, todas as linguagens atuais
oferecem tais recursos, ao menos que voc no venha a utilizar nenhuma dessas tecnologias.
No entanto, assim como eu mencionei no comeo do artigo, a lgica de programao a mesma! Uma vez que o desenvolvedor
tenha plenos conhecimentos em lgica de programao, aprender ou estudar uma nova linguagem se torna uma tarefa mais fcil.
Se o seu interesse a demanda no mercado de trabalho, procure pesquisar nos principais sites de emprego, como o InfoJobs,
Catho, LinkedIn e Ceviu. Observe que existem vagas de emprego para programadores de diversas linguagens de programao em todo o
territrio nacional. Portanto, mo de obra para desenvolvimento de softwares e websites algo que no vai faltar por um bom tempo