Série de Robert C. Martin ~~ Codigo Limpo Habilidades Praticas do Agile SoftwarePrefacio Um de nossos doces favoritos aqui na Dinamarca é 0 Ga-Jol, cujos fortes vapores de licorice s4o um complemento perfeito para nosso clima timido e, geralmente, frio, Parte do charme do Ga-Jol, para nos dinamarqueses, séo os dizeres sabios impressos em cada caixa. Comprei dois pacotes dessa iguaria essa manhi e nela veio este antigo ditado dinamarqués: Erlighed i sma ting er ikke nogen lille ting. “Honestidade em pequenas coisas no é uma coisa pequena”. Era um bom pressagio para com 0 que eu ja descjava dizer aqui. Pequenas coisas so importantes. Este ¢ um livro sobre preocupagdes modestas cujos valores esto longe de ser pequenos. Deus est nos detalhes, disse o arquiteto Ludwig Mies van der Rohe. Essa citag%o retoma, argumentos com contemporancos sobre o papel da arquitctura no desenvolvimento de software, especialmente no mundo Agile. Bob ¢ eu, as vezes, acabavamos engajados entusiasmadamente debatendo sobre este assunto. E sim, Mies van der Rohe atentava para os utilitarios ¢ as formas imemoriais de construgdo que fundamentam uma étima arquitetura. Por outro lado, cle também selecionava pessoalmente cada maganeta para cada casa que ele projetava. Por qué? Por que pequenas coisas sdo importantes. Em nosso “debate” sobre Desenvolvimento dirigido a testes (TDD, sigla em inglés), Bob € eu descobrimos que concordamos que a arquitetura do software possuir um lugar importante no desenvolvimento, embora provavelmente tenhamos perspectivas diferentes do significado exato disso. Essas diferengas so relativamente irrelevantes contudo, pois podemos admitir que profissionais responsaveis dedicam algum tempo para pensar ¢ planejar o inicio de um projeto. As nogées de desenvolvimento dirigido apenas por testes ¢ por cOdigos do final da década de 1990 ja nao existem mais. Mesmo assim, a atengao aos detalhes é um fundamento de profissionalismo ‘ainda mais critico do que qualquer visio maior. Primeiro, € por meio da pratica em pequenos trabalhos que profissionais adquirem proficiéncia e confianga para se aventurar nos maiores. Segundo, a menor parte de uma construgao desleixada, a porta que nao fecha direito ou o azulejo levemente torto do chao, ou mesmo uma mesa desarrumada, retiram completamente o charme do todo. E sobre isso que se trata 0 cédigo limpo. Ainda assim, a arquitetura é apenas uma metéfora para o desenvolvimento de software, especialmente para a parte que entrega o produto inicial no mesmo sentido que um arquiteto entrega uma construgio imaculada, Nessa época do Scrum e do Agile, o foco esta em colocar 0produto rapidamente no mercado. Desejamos que a indistria funcione em velocidade maxima na producao de software. Essas fabricas humanas: programadores que pensam ¢ sentem que trabalham a partir das pendéncias de um produto ou do user story para criar o produto, A metdfora da fabricago estd mais forte do que nunca no pensamento. Os aspectos da produg&o da manufatura japonesa de automéveis, de um mundo voltado para a linha de montagem, inspiraram grande parte do Scrum. Ainda assim, mesmo na indistria automobilistica, a maior parte do trabalho nao esta na fabricag&o, mas na manuten¢&o — ou na prevengdo. Em software, 80% ou mais do que fazemos é chamado de “manutengao”: 0 ato de reparar. Em vez de abragar o tipico foco ocidental sobre a produgdo de bons softwares, deveriamos pensar mais como um pedreiro que conserta casas na industria de construgdo, ou um mec4nico de automéveis na area automotiva. O que 0 gerenciamento japonés tem a dizer sobre isso? Por volta de 1951, uma abordagem qualitativa chamada Manutengao Produtiva Total (TPM) surgiu no cenario japonés. Seu foco era na manutenc&o em vez da produgao. Um dos maiores fundamentos da TPM €0 conjunto dos chamados 5S principios. 5S ¢€ uma série de disciplinas—uso aqui o termo “disciplina” para fins educativos, Os 5S principios, na verdade, sao os fundamentos do Lean — outro jargao no cenério ocidental, e cada vez mais conhecida no mundo dos softwares. Esses prineipios nao s’o uma op¢&o. Assim como Uncle Bob diz em suas preliminares, a pratica de um bom software requer tal disciplina: foco, presenga de espirito c pensamento. Nem sempre é sobre fazer, sobre pressionar os equipamentos da fabrica para produzir em velocidade maxima. A filosofia dos 5S inclui os seguintes conceitos: Seiri, ou organizacao (pense em “ordenar”). Saber onde esto as coisas — usar abordagens como nomes adequados — é crucial. Acha que dar nome a identificadores nao ¢ importante? Leia proximos capitulos. Seiton, ou arrumacdo (pense em “sistematizar”). Ha um antigo ditado americano que diz: “Um lugar para tudo, ¢ tudo em scu lugar”. Um pedago de cédigo deve estar onde voeé espera encontra-lo — caso ndo esteja, refatore ¢ o coloque la. Seiso, ou limpeza (pensem em “polir”): manter 0 local de trabalho livre de fios pendurados, gordura, migalhas ¢ lixo. O que os autores falam aqui sobre encher seu cédigo com comentarios ¢ linhas de cédigos como comentarios que informa o passado ou os desejos para o futuro? Livre- se deles. Seiketsu, ou padronizago: a equipe concorda em manter o local de trabalho limpo. Vocé acha que este livro fala algo sobre ter um estilo de programagao consistente e uma série de priticas dentro da equipe? De onde vém tais padrdes? Continue a leitura. ‘Shutsuke, ou disciplina (autodisciplina). Isso significa ter disciplina para seguir as praticas e refletir frequentemente isso no trabalho e estar disposto a mudar. Se aceitar 0 desafio — isso, 0 desafio — de ler e aplicar 0 que é aconselhado neste livro. yocé entendera e apreciard o ultimo item. Aqui estamos finalmente indo em direcao as raizes do profissionalismo responsavel numa profisso que deve se preocupar com o ciclo de vida de um produto. Conforme facamos a manutencao de automdveis e outras maquinas na TPM, a manutengdo corretiva — esperar que bugs aparegam — ¢ a excegao. Em vez disso, subimos um nivel: inspecionamos as méquinas todos os dias e consertamos as partes desgastadas antes de quebrarem, ou percorremos o equivalente aos famosos 16km antes da primeira troca de 6leo para testar 0 desgaste. No cédigo, a refatoragdo é impiedosa. Vocé ainda pode melhorar um nivel a mais com o advento do movimento da TPM ha 50 anos; construa maquinas que sejam passiveis de manutengio. Tornar seu cédigo legivel € téo importante quanto torna-lo executavel. A iltima pratica, adicionada 4 TPM em torno de 1960, é focar na incluso de maquinas inteiramente novas ou substituir as antigas. Como nos adverte Fred Brooks, proyavelmente devemos refazer partesprincipais do software a partir do zero a cada sete anos ou entao se livrar dos entulhos. Talvez devéssemos atualizar a constante de tempo de Fred para semanas, dias ou horas, em vez de anos. E ai onde ficam os detalhes. HA um grande poder nos detalhes, mesmo assim existe algo simples ¢ profundo sobre essa abordagem para a vida, como talvez esperemos de qualquer abordagem que afirme ter origem Japonesa. Mas essa nao é apenas uma visio ocidental de mundo sobre a vida; a sabedoria de ingleses e americanos também est cheia dessas adverténcias. A citag3o de Seiton mais acima veio da ponta da caneta de um ministro em Ohio que visualizou literalmente a organizagéo “como um remédio para todos os niveis de mal”. E Seiso? Deus ama a limpeza. Por mais bonita que uma casa seja, uma mesa desarrumada retira seu esplendor. E Shutsuke nessas pequenas questdes? Quem € fiel n0 pouco também € no muito, E que tal ficar ansioso para refatorar na hora certa, fortalecendo sua posigao para as “grandes” decisdes subsequentes, em vez de descarté-las? Um homem prevenido vale por dois. Deus ajuda a quem cedo madruga. Nao deixe para amanhf o que se pode fazer hoje. (Esse era o sentido original da frase “o ultimo momento de responsabilidade”, em Lean, até cair nas maos dos consultores de software). E que tal aplicar local de esforgos pequenos e individuais num grande todo? De grao em grio a galinha enche o papo. Ou que tal integrar um trabalho de prevencao no dia a dia? Antes prevenir do que remediat. O cédigo limpo honra as profundas raizes do conhecimento sob nossa cultura mais ampla, ou como ela fora um dia, ou deve ser, € podera vir a ser com a atengao correta aos detalhes, Mesmo na grande literatura na area de arquitetura encontramos visOes que remetem a esses supostos detalhes. Pense nas macanetas de Mies van der Rohe. Aquilo é seiri. E ficar atento a cada nome de varidvel. Deve-se escolher 0 nome de uma varidvel com cuidado, como se fosse eu primeiro filho. Como todo proprietério de uma casa sabe, tal cuidado e constante refinamento jamais acaba, O arquiteto Christopher Alexander — pai dos padrdes ¢ das linguagens de padrdes ~ enxerga cada o proprio design como um conserto pequeno e local. E ele enxerga a habilidade de uma boa estrutura como 0 Unico objetivo do arquiteto; pode-se deixar as formas maiores para os padrdes: © seus aplicativos para os moradores. O design é constante nao sé ao adicionarmos um novo cémodo a uma casa, mas ao nos atentarmos a repintura, a substituigao de carpetes gastos ou a melhoria da pia da cozinha. A maioria das artes reflete relacdes andlogas. Em nossa busca por outras pessoas que dizem que a casa de Deus foi feita nos minimos detalhes, encontramo-nos em boa companhia do autor francés Gustav Flaubert, do século XIX. O poeta francés Paul Valery nos informa que um poema nunca fica pronto e requer trabalho continuo, e parar de trabalhar nele seria abandona-lo. Tal preocupagao com os detalhes é comum a todos os encargos de exceléncia. Portanto, talvez haja pouca coisa nova aqui, mas ao ler este livro voeé serd desafiado a retomar a disciplina que vocé ha muito largou para a apatia ou um desejo pela espontaneidade ¢ apenas “respondia 4s mudangas”. Infelizmente, nfio costumamos enxergar essas questdes como pegas fundamentais da arte de programar. Abandonamos nosso cédigo antecipadamente, ndo porque ele ja esteja pronto, mas porque nosso sistema de valores se foca mais na aparéncia externa do que no contetido que entregamos. No final, essa falta de ateng%o nos custa: Dinheiro ruim sempre reaparece. Pesquisas, nem no mercado ¢ nem nas universidades, sAo humildes o bastante para se rebaixar ¢ manter 0 codigo limpo. Na época em que trabalhei na empresa Bell Labs Software Production Research (produgao, de fato!), ao ficarmos mexendo aqui e ali, nos deparamos com descobertas que sugeriam que 0estilo consistente de endentacdo era um dos indicadores mais significantes estatisticamente da baixa incidéncia de bugs. Queriamos que a qualidade fosse produzida por essa ou aquela estrutura ou linguagem de programagio ou outra nogao de alto nivel; conforme as pessoas cujo suposto profissionalismo se di ao dominio de ferramentas e métodos de design grandioso, sentimo-nos ofendidos pelo valor que aquelas maquinas de fabricas, os codificadores, recebem devido a simples aplicagio consistente em um estilo de endentagao. Para citar meu préprio livro de 17 anos atras, tal estilo faz.a distingao entre exceléncia e mera competéncia. A visto de mundo japonesa entende o valor crucial do trabalhador diario e, além do mais, dos sistemas de desenvolvimento voltados para as aces simples c diarias desses trabalhadores. A qualidade € 0 resultado de um milhao de atos altruistas de importar-se — nao apenas um grande método qualquer que desga dos céus. Nao € porque esses atos sdo simples que eles sejam simplistas, « muito menos que sejam faccis. Eles so, ndo obstante, a fabrica de magnitude ¢. também, de beleza em qualquer esforyo humano. Ignord-los é nao ser ainda completamente humano. E claro que ainda defendo 0 conceito de um escopo mais amplo, e, especialmente, 0 do valor de abordagens arquiteténicas arraigadas profundamente no conhecimento do dominio ¢ de usabilidade do software. Este livro nao 6 sobre isso — ou, pelo menos, nao de modo direto. Mas ele passa uma mensagem mais sutil cuja esséncia nado deve ser subestimada. Ele se encaixa 4 maxima atual das pessoas que realmente se preocupam com o cédigo, como Peter Sommerlad, Kevlin Henney e Giovanni. “O cédigo 0 projeto” e “Cédigo simples” sao seus mantras. Enquanto devamos tentar nos lembrar de que a interface ¢ o programa, ¢ que suas estruturas dizem bastante sobre a estrutura de nosso programa, € crucial adotar a humilde postura de que o projeto vive no cédigo. E enquanto o retrabalho na metéfora da manufatura leva ao custo, 0 no projeto leva ao valor. Devemos ver nosso cédigo como a bela articulaga0 dos nobres esforgos do projeto — projeto como um processo, € nO uma meta estatica. E no cédige que ocorrem as medidas cstruturais de acoplamento € coesio. Se vocé vir a descrigao de Larry Constantine sobre esses dois fatores, ele os conccitua em termos de eédigo— e no em conceitos de alto nivel como se pode encontrar em UML. Richard Gabriel nos informa em seu artigo Abstraction Descant que a abstragao é maligna. O cédigo é antimaligno, ¢ talvez 0 cédigo limpo seja divino. Voltando a minha pequena embalagem de Ga-Jol, acho importante notar que a sabedoria dinamarquesa nos aconselha a nao s6 prestar atengdo a pequenas coisas, mas também a ser honesto em pequenas coisas. Isso significa ser honesto com o cédigo ¢ tanto com nossos colegas ¢, acima de tudo, com nés mesmos sobre o estado de nosso cédigo. Fizemos o Melhor para “deixar © local mais limpo do que como 0 encontramos"? Refatoramos nosso codigo antes de verificé- lo? Essas ndo sao preocupagdes externas, mas preocupagdes que esto no centro dos valores do Agile. Que a refatoragdo seja parte do conceito de “Pronto”, é uma pritica reeomendada no Scrum. Nem a arquitetura ¢ nem o cédigo limpo exigem perfeigao, apenas honestidade e que fagamos o melhor de nés. Errar é humano; perdoar ¢ divino. No Scrum, tornamos as coisas visiveis, Arejamos nossa roupa suja. Somos honestos sobre o estado de nosso cédigo porque © codigo nunca € perfeito. Tornamo-nos mais completamente humanos, mais merecedores do divino © mais proximos da magnitude dos detalhes. Em nossa profiss4o, precisamos desesperadamente de toda ajuda que conseguirmos. Se o piso de uma loja reduz os acidentes ¢ suas ferramentas bem organizadas aumentam a produtividade, entao sou totalmente a favor. E relagao a este livro, ele ¢ a melhor aplicagdo pragmatica dos principios de Lean ao software que jé vi. Eu no esperava nada mais deste pequeno grupo pratico de individuos que se esforcaram juntos por anos nao s6 para se aperfeigoarem, mas também para presentear com scus conhecimentos o mercado com obras como esta em suas maos agora.Isso deixa o mundo um pouco melhor do que quando 0 encontrei antes de Uncle Bob me enviar © manuscrito. Apés ter finalizado estes exercicios com conhecimentos tio sublimes, agora vou limpar minha mesa. James O. Coplien Mordrup, DinamarcaIntrodu¢ao [he omy vAticl neaueenen oF code Quaciry: WTFs/ninure wrr Good code. BAA codle. Reproduzido com a gentil autorizagaio de Thom Holwerda. http:/Avww.osnews.com/story/19266/WTFs_m (c) 2008 Focus Shift Que porta representa seu cédigo? Que porta representa sua equipe ou sua companhia? Por que estamos naquela sala? E apenas uma revisdio normal de codigo ou encontramos uma série de problemas terriveis logo apés iniciarmos a apresentag’io? Estamos depurando em panico, lendo meticulosamente um cédigo que pensdvamos que funcionava? Os clientes estao indo embora aos bandos e estamos com os gerentes em nossos pescogos? Como podemos garantir que cheguemos atras da porta certa quando 0 caminho fica dificil? A resposta é: habilidade profissional Ha duas vertentes para se obter habilidade profissional: conhecimento e trabalho. Vocé deve adguirir 0 conhecimento dos principios, padrdes, priticas e heuristicas que um profissionalhabilidoso sabe, ¢ também esmiugar esse conhecimento com seus dedos, olhos corpo por meio do trabalho arduo ¢ da pratica Posso the ensinar a mecanica para se andar de bicicleta. Na verdade, a matemitica clissica € relativamente direta. Gravidade, atrito, momento angular. centro de massa, e assim por diante, podem ser demonstrados com menos de uma pagina cheia de equacdes. Dada essas formulas, eu poderia provar para vocé que ¢ pritico andar de bicicleta e Ihe dar todo o conhecimento necessario para que vocé consiga. E mesmo assim vocé caira na primeira vez que tentar. Programar nao ¢ diferente. Poderiamos pér no papel todos os principios necessarios para um cédigo limpo e, entio, confiar que vocé faré as tarefas (isto é, deixar vocé cair quando subir na bicicleta), mas que tipo de professores e de estudantes isso faria de nds? Nao. Essa no ¢ a forma que este livro seguira, Aprender a criar cédigos limpos é uma tarefa ardua e requer mais do que o simples conhecimento dos principios ¢ padrées. Vocé deve suar a camisa: praticar sozinho ¢ ver que cometeu erros; assistir a outros praticarem e errarem; vé-los tropegar e refazer seus passos; Vé- los agonizar para tomar decisdes e 0 prego que pagardo por as terem tomado da maneira errada. Esteja preparado para trabalhar duro enquanto ler este livro. Esse ndo ¢ um livro facil simples que vocé pode ler num aviao e terminar antes de aterrissar. Este livro Ihe fard trabalhar, ¢ trabalhar duro. Que tipo de trabalho vocé far? Vocé leré cddigos aqui, muitos cédigos. E vocé devera descobrir 0 que esta correto ¢ errado nos codigos. Vocé tera de seguir 0 raciocinio conforme dividirmos médulos e os unirmos novamente. Isso levari tempo ¢ esfor¢o, mas achamos que valerd a pena. Dividimos este livro em trés partes. Na primeira ha diversos capitulos que descrevem os principios, padrées ¢ priticas para criar um cédigo limpo. Ha um tanto de cédigos nessa parte. ¢ ser desafiador Ié-los. Eles Ihe prepararao para a se¢do seguinte. Se yocé deixar o livro de lado apés essa primeira parte. Bem, boa sorte! Na segunda parte entra o trabalho pesado que consiste em diversos estudos de caso de complexidade cada vez maior. Cada um é um exercicio para limpar um cédigo — resolver alguns problemas dele. O detalhamento nesta segdo ¢ intenso. Vocé terd de ir e voltar por entre as folhas de textos ¢ cédigos, c analisar ¢ entender 0 cédigo com o qual estamos trabalhando e captar nosso raciocinio para cada alteragao que fizermos. Reserve um tempo para essa parte, pois deveré levar dias. A terceira parte é a compensagao. E um tinico capitulo com uma lista de heuristicas e “odores” reunidos durante a criagao dos estudos de caso. Conforme progredirmos e limparmos os cédigos nos estudos de caso, documentaremos cada motivo para nossas agdes como uma heuristica ou um “odor”. Tentaremos entender nossas proprias reagdes em relag%io ao cédigo quando estivermos Iendo ou alterando-o, ¢ trabalharemos duro para captar por que nos sentimos de tal forma por que fizemos isso ou aquilo. O resultado sera um conhecimento base que descreve a forma como pensamos quando criamos, lemos e limpamos um eédigo. Este conhecimento base possui um valor limitado se vocé no ler com atengiio ao longo dos casos de estudo na segunda parte deste livro. Neles, anotamos cuidadosamente cada alteracio que fizemos com referéncias posteriores as heuristicas. Tais referencias aparecem em colchetes, assim: [H22]. Isso lhe permite ver 0 contexto no qual so aplicadas e escritas aquelas heuristicas! Essas. em si, nio sio téo valiosas, mas, sim, a relagao entre clas ¢ as diferentes decisdes que tomamos ao limpar o cédigo nos casos de estudo. A fim de lhe ajudar ainda mais com essas relagdes, colocamos no final do livro uma referéncia cruzada que mostra o nimero da pagina para cada referéncia, Vocé pode usd-la com um guia répido de consulta para saber onde uma determinada heuristica foi aplicada. Mesmo se vocé ler a primeira e a terceira segdes e pular para os casos de estudo, aindaassim teré lido um livro que satisfaz sobre a cria¢do de um bom software. Mas se no tiver pressa e explorar os casos de estudo, seguindo cada pequeno passo e cada minuto de decisao, se colocando em nosso lugar e se forgando a seguir a mesma linha de raciocinio que usamos, entdo vocé adquiriu um entendimento muito mais rico de todos aqueles principios, padrdes, priticas © heuristicas. Todo esse conhecimento ficara em cada fibra de seu corpo. Ele se tomnara parte de vocé da mesma forma que ao aprender a andar de bicicleta, cla se torna uma parte de sua vontade de pedalé-la. Agradecimentos Tlustracgées Meus agradecimentos a minhas duas artistas, Jeniffer Kohnke ¢ Angela Brooks. Jennifer ¢ a responsavel pelas maravilhosas e criativas figuras no inicio de cada capitulo ¢ também pelos retratos de Kent Beck, Ward Cunningham, Bjame Stroustrup, Ron Jeffries, Grady Booch, Dave Thomas, Michael Feathers e de mim mesmo. ‘Angela é a responsavel pelas figuras engenhosas que enfeitam os capitulos.Ao longo dos anos, ela criou bastantes imagens para mim, incluindo muitas das que est8o no livro Agile Software Develpment: Principles, Patterns, and Practices. Angela também é minha primogénita e de quem me sinto muito orgulhoso.Sobre a capa A imagem da capa se € a M104 — a Galaxia Sombrero ~, que fica na constclago de Virgem e esta a pouco menos de 30 milhdes de anos-luz de nés. Em seu centro hd um buraco negro supermassivo cujo peso equivale um bilhao de vezes a massa do sol. Aimagem Ihe faz lembrar da explosio da lua Praxis, de Klingon? Eu me recordo vividamente a cena de Jornada nas Estrelas VI que mostrava um anel equatorial de destrogos voando devido & explosdo. Desde essa cena, 0 anel equatorial se tornou um componente comum as explosdes em filmes de ficcao cientifica. Ele até foi adicionado & explosao de Alderaan nas iltimas versdes do filme Jomada nas Estrelas. O que causou a formagio desse anel em torno de M104? Por que ele possui um bojo 120 amplo ¢ um nileo tao minusculo ¢ brilhoso? Parece-me como se 0 buraco negro central perdeu sua graca e langou um buraco de 30,000 anos-luz no meio da galaxia, devastando quaisquer civilizagdes que estivessem no caminho daquele distarbio césmico. Buracos negros supermassivos engolem estrelas inteiras_no_almogo, convertendo_uma considerdvel fragaio de sua massa em energia. E = MC2 ja € bastante poténcia, mas quando M é uma massa estelar: Cuidado! Quantas estrelas cairam_ impetuosamente naquelas presas antes de o monstro ficar saciado? O tamanho do vao central poderia ser uma dica? ‘A imagem de M104 da capa é uma combinagao da famosa fotografia de luz visivel do Hubble (foto superior) com a recente imagem infravermelha do observatério espacial Spitzer (foto inferior). E essa segunda imagem que nos mostra claramente a natureza do anel da galaxi Na luz visivel, vemos apenas a extremidade frontal do anel como uma silhueta. O bojo central ofusca o resto do anel. ‘Mas no infravermelho, as particulas “quentes” — isto 6, altamente radioativas — no anel brilham através do bojo central. A combinagaio de ambas as imagens nos mostra uma visdo que ndo haviamos visto antes e indica que, ha muito tempo atras, la havia um inferno enfurecido de ativi ‘Cover mage: © Sper Space TelescopeCédigo Limpo HA duas razdes pelas quais voce esta lendo este livro: vocé é programador e deseja se tomar um ainda melhor. Otimo. Precisamos de programadores melhores.Capitulo 1: Cédigo Limpo Este livro fala sobre programagao ¢ est repleto de cédigos que examinaremos a partir de diferentes perspectivas: de baixo para cima, de cima para baixo e de dentro para fora. Ao terminarmos, teremos um amplo conhecimento sobre cédigos e seremos capazes de distinguir entre um cédigo bom ¢ um cédigo ruim. Saberemos como escrevet um bom cédigo e como tornar um ruim em um bom. O Cédigo Podem dizer que um livro sobre cédigos ¢, de certa forma, algo ultrapassado, que a programago deixou de ser uma preocupagio € que devemos nos preocupar com modelos ¢ requisitos. Outros até mesmo alegam que o fim do eédigo, ou seja, da programagio, esta proximo: que logo todo cédigo sera gerado, ¢ no mais escrito. E que nao precisarao mais de programadores, pois as pessoas criardio programas a partir de especificages. Bobagens! Nunca nos livraremos dos eédigos, pois eles representam os detalhes dos requisitos. Em certo nivel, no hé como ignorar ou abstrair esses detalhes; eles precisam ser especificados. E especificar requisitos detalhadamente de modo que uma maquina possa executé-los é programar ~¢ tal especificagao é 0 cédigo, Espero que 0 nivel de de nossas linguagens continue a aumentar © que 0 mimero de linguagens especificas a um dominio continue crescendo. Isso sera bom, mas no acabaré com a programagdo. De fato, todas as especificagées escritas nessas linguagens de niveis mais altos ¢ especificas a um dominio serdo cédigos! Eles precisardo ser minuciosos, exatos ¢ bastante formais ¢ detalhados para que uma maquina possa entendé-los ¢ executd-los. As pessoas que pensam que 0 codigo um dia desaparecera so como matemiticos que esperam algum dia descobrir uma matemitica que no precise ser formal. Elas esperam que um dia descubramos uma forma de criar maquinas que possam fazer o que desejamos em vez do que mandamos. Tais maquinas terdo de ser capazes de nos entender tio bem de modo que possam traduzir exigéncias vagamente especificadas em programas executaveis perfeitos para mo 0s seres humanos, com toda sua intuigo e criatividade, tém sido capazes de criar sistemas bem-sucedidos a partir das caréncias confusas de seus clientes, Na verdade, se a matéria sobre especificag&o de requisitos ndo nos ensinou nada, é porque os requisitos bem especificados so tao formais quanto os cédigos e podem agir como testes executaveis de tais cédigos! Lembre-se de que o cédigo é a linguagem na qual expressamos nossos requisitos. Podemos ctiar linguagens que sejam mais proximas a eles, Podemos criar ferramentas que nos ajudem a analisar a sintaxe e unir tais requisitos em estruturas formais. Mas jamais eliminaremos a preciso necesséria — portanto, sempre haverd um cédigo.Cédigo Ruim 3 Cédigo ruim Recentemente li o preficio do livro Implementation Patterns! de Kent Beck, no qual ele diz “... este livro bascia-se numa premissa fragil de que um bom cédigo importa...”. Uma premissa fragil? Nao concordo! Acho que essa premissa ¢ uma das mais robustas, apoiadas ¢ plenas do que todas as outras em nossa rea (¢ sei que Kent sabe disso). Estamos cientes de que um bom cédigo importa, pois tivemos de lidar com a falta dele por muito tempo. Lembro que no final da década de 1980 uma empresa criou um aplicativo extraordinario que se tornou muito- popular ¢ muitos profissionais 0 compraram € usaram. ‘Mas, entao, o intervalo entre os langamentos das novas distribuigdes comegou a aumentar. Os bugs ndo eram consertados na distribuicio seguinte. E 0 tempo de carregamento do aplicativo ¢ o ntimero de travamentos aumentaram. Lembro-me do dia em que, frustrado, fechei 0 programa ¢ nunca mais o usei. A empresa saiu do mercado logo depois. Duas décadas depois encontrei um dos funcionarios de tal empresa na época e o perguntei 0 que havia acontecido, e 0 que cu temia fora confirmado. Eles tiveram de apressar 0 langamento do produto ¢, devido a isso, o cédigo ficou uma zona. Entao, conforme foram adicionando mais € mais recursos, o cédigo piorava cada vez mais até que simplesmente nao era mais possivel gerencia-lo. Foi o cddigo ruim que acabou com a empresa. Alguma vez um cédigo ruim jé Ihe atrasou consideravelmente? Se vocé for um programador, independente de sua experiéncia, entdo jé se deparou varias vezes com esse obsticulo. Alids, ¢ como se caminhassemos penosamente por um lamacal de arbustos emaranhados com armadilhas ocultas.Isso é 0 que fazemos num cédigo ruim. Pelejamos para encontrar nosso caminho. esperando avistar alguma dica, alguma indicagdo do que esté acontecendo; mas tudo 0 que vemos é um cédigo cada vez mais sem sentido. E claro que um cédigo ruim ja lhe atrasou. Mas, enti, por que vocé o escreveu dessa forma? Estava tentando ser rapido? Estava com pressa? Provavelmente. Talvez vocé pensou que no tivesse tempo para fazer um bom trabalho; que seu chefe ficaria com raiva se vocé demorasse um pouco mais para limpar seu cédigo. Talvez vocé estava apenas cansado de trabalhar neste programa ¢ queria termina-lo logo. Ou verificou a lista de coisas que havia prometido fazer ¢ percebeu que precisava finalizar este médulo de uma vez, de modo que pudesse passar para o proximo. Todos jé fizemos isso, j4 vimos a bagunga que fizemos e, ent&o, optamos por arruma- las outro dia. Todos j4 nos sentimos aliviados ao vermos nosso programa confuso funcionar ¢ decidimos que uma bagunga que funciona ¢ melhor do que nada. Todos nos ja dissemos que revisariamos ¢ limpariamos o cédigo depois. E claro que naquela época nao conheciamos a lei de LeBlane: Nunca é tarde. 1. ecko)4 Capitulo 1: Cédigo Limpo O Custo de Ter um Codigo Confuso Se vocé programador a mais de dois ou trés anos, provavelmente 0 cédigo confuso de outra pessoa ja fez com que vocé trabalhasse mais lentamente e provavelmente seu proprio cédigo jé Ihe trouxe problemas. © nivel de retardo pode ser significative. Ao longo de um ou dois anos, as equipes que trabalharam rapidamente no inicio de um projeto podem perceber mais tarde que esto indo a passos de tartaruga. Cada alteragdo feita no eédigo causa uma falha em outras duas ou trés partes do mesmo eédigo. Mudanca alguma ¢ trivial. Cada adiea0 ou modificagdo ao sistema exige que restauragdes, amarragées e remendos sejam “entendidas” de modo que outras possam ser incluidas. Com 0 tempo, a bagunga se tomna tao grande e profunda que nao da para arrumé-la. ‘Nao hé absolutamente solugiio alguma. Conforme a confusio aumenta, a produtividade da cquipe diminui, assintoticamente aproximando-se de zero. Com a redugo da produtividade, a geréncia faz a unica coisa que cla pode; adiciona mais membros ao projeto na esperanga de aumentar a produtividade. Mas esses novos membros néo conhecem o projeto do sistema, nao sabem a diferenga entre uma mudanga que altera o propésito do projeto ¢ aquela que o atrapalha. Ademais, cles, ¢ todo 0 resto da equipe, esto sobre tremenda pressio para aumentar a produtividade. Com isso todos criam mais € mais confuses, levando a produtividade mais perto ainda de zero (veja a Figura 1.1). co8 S888 Time Figura 1.1 Produtividade v. tempoO Custo de Ter um Cédigo Confuso 5 O Grande Replanejamento No final, a equipe se rebela. Todos informam a geréncia que nao conseguem mais trabalhar neste irritante cédigo-fonte e exigem um replanejamento do projeto. Apesar de a geréncia naio querer gastar recursos em uma nova remodelagdo, ela nfo pode negar que a produtividade esta péssima. No final das contas, ela acaba cedendo as exigéncias dos desenvolvedores ¢ autoriza o grande replanejamento desejado. F, entdo, formada uma nova equipe especializada. Por ser um projeto inteiramente novo, todos querem fazer parte dessa equipe. Eles desejam comegar do zero e criaralgo belo de verdade. Mas apenas os melhores e mais brilhantes sAo selecionados ¢ os outros deverao continuar na manutengao do sistema atual. ‘Agora ambos os times estao numa corrida. A nova equipe precisa construir um novo sistema que faca o mesmo que o antigo, além de ter de se manter atualizada em relagdo as mudangas feitas constantemente no sistema antigo. Este, a geréncia ndo substituira até que 0 nove possa fazer tudo também. Essa corrida pode durar um bom tempo. Jé vi umas levarem 10 anos, E, quando ela termina, ‘os membros originais da nova equipe j4 foram embora ha muito tempo, e os atuais exigem 0 replanejamento de um novo sistema, pois esta tudo uma zona novamente. Se vocé ja vivenciou pelo menos um pouco dessa situagéo, entio sabe que dedicar tempo para limpar seu cédigo nao ¢ apenas eficaz em termos de custo, mas uma questo de sobrevivéncia profissional. Atitude Vocé ja teve de trabalhar penosamente por uma confuséo tio grave que levou semanas 0 que deveria ter levado horas? Vocé ja presenciou o que deveria ser uma alteragao Gnica ¢ direta, mas que em vez disso foi feita em diversos médulos distintos? Todos esses sintomas so bastante comuns. Por que isso ocorre cm um cédigo? Por que um eédigo bom se decompée tio rapide em um ruim? Temos diversas explicagées para isso. Reclamamos que os requisitos mudaram de tal forma que estragaram o projeto original. Criticamos os prazos por serem curtos demais para fazermos as coisas certas. Resmungamos sobre gerentes tolos ¢ clientes intolerantes ¢ tipos de marketing iniiteis e téenicos de telefone. Mas 0 padrao, querido Dilbert", nao esti em nossas estrelas, mas sim em nés mesmos. Somes profissionais Isso pode ser algo dificil de engolir. Mas como poderia essa zona ser nossa culpa? E os requisitos? E 0 prazo? E os tolos gerentes ¢ tipos de marketing iniiteis? Eles no carregam alguma parcela da culpa? Nao. Os gerentes ¢ markeieiros buscam em nds as informagdes que precisam para fazer promessas ¢ firmarem compromissos; e mesmo quando no nos procuram, nfo devemos dar uma de timidos ao dizer-lhes nossa opinifio. Os usuarios esperam que validemos as maneiras pelas quais os requisitos se encaixarao no sistema. Os gerentes esperam que os ajudemos a cumprir 0 prazo. Nossa cumplicidade no planejamento do projeto é tamanha que compartilhamos de uma grande parcela da responsabilidade em caso de falhas: especialmente se estas forem em relag3o a um cédigo ruim.6 Capitulo 1: Cédigo Limpo erei demitid “Mas, espere!”, voce di provavel que nao. ‘A maioria dos gerentes quer a verdade, mesmo que demonstrem o contrario. A maioria deles quer um cédigo bom, mesmo estourando o prazo. Eles podem proteger com paixao 0 prazo ¢ 03 requisitos, mas essa é a fungdio deles. A swa ¢ proteger o cédigo com essa mesma paixio. Para finalizar essa questo, e se vocé fosse médico e um paciente exigisse que vocé parasse com toda aquela lavagao das maos na preparacao para a cirurgia s6 porque isso leva muito tempo?” E obvio que 0 chefe neste caso ¢ 0 paciente; mas, mesmo assim, o médico deverd totalmente se recusar obedecé-lo, Por qué? Porque 0 médico sabe mais do que o paciente sobre os riscos de doengas e infecgées. Nao seria profissional (sem mencionar criminoso) que o médico obedecesse ao paciente neste cenério. Da mesma forma que nio é profissional que programadores cedam & vontade dos gerentes que nao entendem os riscos de se gerar cédigos confusos. . “E se eu nfo fizer 0 que meu gerente qui O Principal Dilema Os programadores se deparam com um dilema de valores basicos. Todos os desenvolvedores com alguns anos a mais de experiéncia sabem que bagungas antigas reduzem o rendimento. Mesmo assim todos eles se sentem pressionados a cometer essas bagungas para cumprir os prazos. Resumindo, eles nao se esforgam para. Os profissionais sérios sabem que a segunda parte do dilema esté errada, Vocé nfio cumprira © prazo se fizer bagunga no cédigo, De fato, tal desorganizacao reduzira instantaneamente sua velocidade de trabalho, ¢ vocé perdera o prazo. A winica maneira de isso nao acontecer — a unica maneira de ir mais rapido — é sempre manter o cédigo limpo. A Arte do Cédigo Limpo? Digamos que vocé acredite que um cédigo confuso seja um obstéculo relevante. Digamos que vocé accite que a tinica forma de trabalhar mais répido ¢ manter seu cédigo limpo. Entio, vocé deve se perguntar: “Como escrever um cédigo limpo?” Nao vale de nada tentar escrever um cédigo limpo se voce nao souber o que isso significa. As mis noticias so que escrever um cédigo limpo é como pintar um quadro. A maioria de nés sabe quando a figura foi bem ou mal pintada. Mas ser capaz de distinguir uma boa arte de uma ruim nao significa que vocé saiba pintar. Assim como saber distinguir um cédigo limpo de um ruim nao quer dizer que saibamos escrever um cédigo limpo. Escrever um cédigo limpo exige o uso disciplinado de uma mirfade de pequenas técnicas aplicadas por meio de uma sensibilidade meticulosamente adquirida sobre “limpeza”. A “sensibilidade ao codigo” é 0 segredo. Alguns de nds j4 nascemos com ela. Outros precisam se esforcar para adquiri-la. Ela nao so nos permite perceber se o cédigo é bom ou ruim, como também nos mostra a estratégia e disciplina de como transformar um cédigo ruim em um limpo. Um programador sem “sensibilidade ao c6digo” pode visualizar um médulo confuso & reconhecer a bagunga, mas nao sabera o que fazer a respeito dela. J4 um com essa sensibilidade olhara um médulo confuso ¢ vera alternativas. A “sensibilidade ao codigo” ajudara a esse +> tes 1847. qeamo lunar Sexureslorcis eumsiin pele ertmeira vex biveniom di woke, ala Soi nejeiteda, baasaado.se no Gato dé'que os méllicrs cram ctupadesO Custo de Ter um Cédigo Confuso 7 programador a escolher a melhor alternativa ¢ 0 orientara na criagao de uma sequéncia de comportamentos para proteger as alteragées feitas aqui ¢ ali. Em suma, um programador que escreve um cédigo limpo ¢ um artista que pode pegar uma tela em branco ¢ submeté-la a uma série de transformagées até que se torne um sistema graciosamente programado, O que é um Cédigo Limpo? Provavelmente existem tantas definigdes como existem programadores. Portanto, perguntei a alguns programadores bem conhecidos ¢ com muita experiéneia o que achavam. Bjarne Stroustrup, criador do C++ e autor do livro A linguagem de programagao C++ Gosto do meu cédigo elegante ¢ eficiente. A logica deve ser direta para dificultar o encobrimento de bugs, ‘as dependéncias minimas para facilisar a mamutengao, 0 tratamento de erro completo de acordo com uma estratégia clara € 9 desempenko priximo do mais efielente de modo a néto incitar as pessoas a tornarem 0 cédigo confuso com otimizagbes sorrateiras, O cédiga impo faz bem apenas uma coisa. Bjame usa a palavra “elegante” — uma palavra e tanto! O diciondrio possui as seguintes definigdes: que se caracteriza pela naturalidade de harmonia, leveza, simplicidade; naturalidade no modo se dispor: requintado, fino, estiloso. Observe a énfase dada a palavra “naturalidade”. Aparentemente, Bjarne acha que um cédigo limpo proporciona uma leitura natural: ¢ lé-lo deve ser belo como ouvir uma misica num radio ou visualizar um carro de design magnifico. Bjarne também menciona duas vezes “eficiéncia”. Talvez isso nao devesse nos surpreender vindo do criador do C++, mas acho que ele quis dizer mais do que um simples desejo por agilidade. A repetigao de ciclos nao € elegante, nao é belo. E repare que Bjame usa a palavra “incitar” para descrever a consequéneia de tal desclegancia. A verdade aqui é que um cédigo ruim incita o crescimento do caos num cédigo. Quando outras pessoas alteram um cédigo ruim, elas tendem a piord-lo Pragmaticos, Dave Thomas ¢ Andy Hunt expressam isso de outra forma, Eles usam a metfora das janelas quebradas.’ Uma construgao com janelas quebradas parece que ninguém cuida dela. Dessa forma, outras pessoas deixam de se preocupar com ela também. Elas permitem que as outras janelas se quebrem também. No final das contas, as proprias pessoas as quebram. Elas estragam a fachada com pichagdes e deixam acumular lixo. Uma tinica janela inicia 0 proceso de degradagao. 5 Sas etna ai easg Capitulo 1: Cédigo Limpo Bjarne também menciona que 0 tratamento de erro deva ser completo. Isso significa prestar atengiio nos detalhes. Um tratamento de erro reduzido € apenas uma das manciras pela qual os programadores deixam de notar os detalhes. Perdas de meméria e condigdes de corrida sao outras. Nomenclaturas inconsistentes so ainda outras. A conclusio é que um cédigo limpo requer bastante atengao aos detalhes. Bjarne conclui com a asseveragdo de que um cédigo limpo faz bem apenas uma coisa. Nao ¢ por acaso que ha intimeros principios de desenvolvimento de software que podem ser resumidos a essa simples afirmagio. Varios escritores j4 tentaram passar essa ideia, Um codigo ruim tenta fazer coisas demais, ele esta cheio de propésitos obscuros e ambiguos. O cédigo limpo é centralizado. Cada fungao, cada classe, cada médulo expe uma tinica tarefa que nunca sofre interferéncia de outros detalhes ou fica rodeada por eles. Grady Booch, autor do livro Object Oriented Analysis and Design with Applications Um cédigo limpo & simples e direto. Ele é tao bem legivel quanto uma prosa bem escrita. Ele jamais torna confuso 0 objetivo do desenvolvedor. em vez disso, ele esué repleto de abstragbes claras ¢ linhas de controle objetivas. Grady fala de alguns dos mesmos pontos que Bjame, voltando-se mais para questo da legibilidade. Eu, particularmente, gosto desse ponto de vista de que ler um cédigo limpo deve ser como ler uma prosa bem escrita. Pense num livro muito bom que voce j4 leu. Lembre-se de como as palavras eram substituidas por imagens! Era como assistir a um filme, nfo era? Melhor ainda, vocé via os personagens. auvia os sons, envolvia-se nas emogdes ¢ no humor. Ler um cédigo limpo jamais ser como ler O senhor dos anéis. Mesmo assim, a analogia com a literatura nao é ruim. Como um bom romance, um cédigo limpo deve expor claramente as questdes do problema a ser solucionado. Ele deve desenvolvé-las até um climax e, entao, dar ao leitor aquele “Aha! Mas é claro!”, como as questdes € 0s suspenses que so solucionados na revelagao de uma solugdo ébvia. ‘Acho que o uso que Grady faz da frase “abstragdes claras” ¢ um paradoxo fascinante! ‘Apesar de tudo, a palavra “clara” € praticamente um sindnimo para “explicit”. Meu dicionario MacBook tem a seguinte definigao para “claro(a)”: direto, decisivo, sem devaneios ou detalhes desnecessérios. Apesar desta justaposicao de significados, as palavras carregam uma mensagem poderosa. Nosso cédige deve ser decisivo, sem especulagdes. Ele deve conter apenas 0 necessirio. Nossos leitores devem assumir que fomos decisivos.© Custo de Ter um Cédigo Confuso 9 O “grande” Dave Thomas, fundador da OTI, o pai da estratégia Eclipse Além de seu eriador, wm desenvolvedor pode ler ¢ melhorar um cédigo limpo. Ele tem testes de unidade e de aceitagao, nomes significativas; ele oferece apenas unia maneira, € nao varias, de se fazer uma tarefa; possui poucas dependéncias, as quais sdo explicitamente declaradas ¢ oferecem um API minimo ¢ claro. O cédigo deve ser inteligivel ja que dependendo da linguagem, nem toda informagiia necessde pode expressa no cédigo em si. Dave compartilha do mesmo desejo de Grady pela legibilidade, mas com uma diferenga relevante. Dave afirma que um cédigo limpo facilita para que outras pessoas o melhorem, Pode parecer ébvio, mas nio se deve enfatizar muito isso. Ha, afinal de contas, uma diferenga entre um cddigo facil de ler e um facil de alterar. Dave associa limpeza a testes! Dez anos atrés, isso levantaria um ar de desconfianga. Mas 0 estudo do Desenvolvimento Dirigido a Testes teve grande impacto em nossa industria € se tornow uma de nossos campos de estudo mais essenciais. Dave esta certo. Um cédigo, sem testes, nio esta limpo. Nao importa 0 quao elegante, legivel ou acessivel esteja que, se ele no possuir testes, ele nao é limpo. Dave usa a palavra minima duas vezes. Aparentemente ele di preferéncia a um cédigo pequeno. De fato, esse tem sido uma citagdio comum na literatura computacional. Quando menor, melhor. Dave também diz que 0 cédigo deve ser inteligivel ~ referéncia esta a programacao inteligivel' (do livro Literate Programming) de Donald Knuth. A conclusao é que o cédigo deve * ser escrito de uma forma que scja inteligivel aos seres humanos. Michael Feathers, autor de Working Effectively with Legacy Code Eu poderia listar todas as qualidades que vejo em um eédigo Jimpo, mas hé uma predominante que leva a todas as outras. Um cédigo limpo sempre parece que foi escrito por alguém que se importava. Ndo hé nada de ébvio no que se pode facer para torné-lo melhor. Tudo foi pensado pelo autor do cédigo, € s@ tentar pensar em algumas meihoras, voee voltard ao inicio, ow seja, apreciando 0 cédigo deixado para voeé por alguém que se importa bastante com essa tarefa One word: care. E esse 0 assunto deste livro. Talvez, um subtitulo apropriado seria Como se importar |\- com o cédigo. a Michael bate na testa: um cédigo limpo é um eédigo que foi cuidado por alguém. Alguém que calmamente 4. [Reuth92],10 Capitulo 1; Cédigo Limpo -manteve simples e organizado; alguém que prestou a atengao necesséria aos detalhes; alguém que se importou. Ron Jeffries, autor de Extreme Programming Installed and Extreme Programming Adventures in C# Ron iniciou sua carreira de programador em Fortran, no Strategic Air Command, ¢ criou cédigos em quase todas as linguagens ¢ maquinas. Vale a pena considerar suas palavras: Nestes anos reconies, comecel, ¢ quase finalizei, com as regras de Beck sobre cadigu simpies. Em ordem de prioridade, sto: + Efete todos os restes + Sem duplicagao de codigo; Expressa todas as ideias do proteto que estio no sistema, + Minimiza 0 mimero de entidades, como classes, métodos. funcdes e outras do tipo. Dessas quatro, foco-me mais na de duplicacdo. Quando a mesma coisa é feita repetidas vezes, é sinal de que ‘uma ideia em sua cabeca néo esté bem representada no cédigo. Tento descobrir o que é ¢, entéo, expressar aquela ideia com mais clareza. Expressividade para mim sdo nomes significatives ¢ costume mudar 0 nome das coisas varias vezes antes de Jfinalizar, Com ferramentas de programagao modernas, como a Eclipse, renomear é bastante facil, ¢ por isso ‘nlio me incomodo em fazer isso. Entretanio, a expressividade vat além de nomes. Também verifico se um métado ‘ou objeto faz mais de uma tarefa. Se for um objeto, provavelmente ele precisard ser dividido em dois ou mais. Se for um método, sempre uso a refatoragiia do Métode de Extracdo nele, resultando em um meétoda que expressa mais claramenie sua fungdo @ em outros mérodos que dizem como ela € feita. Duplicagdo e expressividade me levam ao que considero um cédigo limpo, ¢ methorar um codigo ruim com apenas esses dois conceitas na mente pode fazer uma grande diferenca. Hd, porém, uma outra coisa da qual estou ciente quando programo, que & um pouco mais dificid de explicar. ‘Apés anos de trabalho, parece-me que todos os programadores pensar tudo igual. Um exemplo é “encontrar coisas numa colecdo”. Tenhamos uma base de dados com registras de funciondrias ou wma tabela hash de chaves e valores ou um vetor de itens de algum tipo, geralmente procuramos um item especifico naquela colegdo. Quando percebo isso, costume implementar essa fungao em um método ou classe mats absiraio — 0 que me proporciona algumas vantagens interessantex Posso implemeniar a funcionalidade agora com algo mais simples, digamos uma tabela hash, mas como agora todas as referencias aquela busca estéo na minha classe ou método abstrato, posso alterar a implementagao sempre que desejar Posso ainda prosseguir rapidamente enquanto preservo a capacidade de alteracdo futwra. ‘Além disso, a de colegdes geralmente chama minha atencdo para o que realmente esti acontecendo, e impede que eu implemente funcionalidades arbitrarias em colegdes quando tuclo que eu preciso sao simples maneiras de encontrar o que desejo. Reducio de duplicacdo de codigo, alta expressividade ¢ eriagdo no inicio de abstracdes simples, E isso que torna para mim um cédigo limpo. Aqui, em alguns breves pardgrafos, Ron resumiu o conteiido deste livro. Sem duplicag4o, uma iarefa, expressividade, pequenas abstragBes. Tudo foi mencionado.O Custo de Ter um Cédigo Confuso ul Ward Cunningham, criador do conceito de “WikiWiki”, criador do Fit, co-criador da Programagao Extrema (eXtreme Programming). Incentivador dos Padrées de Projeto. Lider da Smalltalk e da OO. Pai de todos aqueles que se importam com 0 cédigo. Focé sabe que esté criando um cédigo limpo quando cada rotina que voe® leia se mostra como 0 que vocé esperava. Vacé pode chamar de cédigo belo quando ele também faz parecer que a g Iinguagem fot feita para o problema, DeclaragGes como essa sao caracteristicas de Ward. Vocé a 1g, coloca na sua cabeca e segue para a proxima. Parece tio racional, tio ébvio que raramente é memorizada como algo profundo, Vocé acha que basicamente ja pensava assim. Mas observemos mais atentamente. *.. 0 que voce esperava”. Qual foi a ltima vez que vocé viu um médulo como vocé o esperava que fosse? Nao é mais comum eles serem complexos, complicados, emaranhados? Interpretd-lo erroneamente nao é a regra? Vocé nao esta acostumado a se descontrolar ao tentar entender 0 raciocinio que gerou todo 0 sistema e associd-lo ao médulo que estés lendo? Quando foi a ultima vez que vocé leu um cédigo para o qual vocé assentiu com a cabega da mesma forma que fez com a declaragao de Ward? Este espera que ao ler um eédigo limpo nada Ihe surpreenda. De fato, nao sera nem preciso muito esforgo. Vocé ird lé-lo ¢ ser basicamente 0 que voce j4 esperava. O cédigo é dbvio, simples ¢ convincente. Cada médulo prepara o terreno para 0 seguinte. Cada um the diz como 0 proximo estaré escrito. Os programas que sao tao limpos e claros assim foram tio bem escritos que vocé nem pereebera. O programador o faz parecer super simples, como o é todo projeto extraordinario. E a nogo de beleza do Ward? Todos ja reclamamos do fato de nossas linguagens nao tiverem sido desenvolvidas para os nossos problemas. Mas a declaragio de Ward coloca novamente © peso sobre nds. Ele diz que um codigo belo faz parecer que a linguagem foi feita para o problema! Portanto, ¢ nossa tesponsabilidade fazer a linguagem parecer simples! Ha brigas por causa das linguagens em todo lugar, cuidado! Nao é a linguagem que faz os programas parecerem simples, é o programador!12 Capitulo 1: Cédigo Limpo Escolas de Pensamento E eu (Tio Bob)? © que ¢ um cédigo limpo para mim? E isso 0 que este livro lhe dird em detalhes, o que eu ¢ meus compatriotas consideramos um cédigo limpo. Diremo-lhe o que consideramos como nomes limpos de varidveis, fungdes limpas, classes limpas etc. Apresentaremos nossos conceitos como verdades absolutas, e nao nos desculparemos por nos: austeridade. Para nés, a essa altura de nossa carreira, tais conceitos sdo absolutos. Séo nossa escola de pensamento acerca do que seja um cédigo limpo. Nem todos os mestres de artes marciais concordam com qual seria a melhor arte marcial de todas ou a melho técnica dentro de uma arte marcial especifica. Geralmente, cles criam suas proprias escolas de pensamento ¢ recrutam alunos para serem ensinados. Dessa forma, temos 0 Jiu Jitsu dos Gracie, criado e ensinado pela familia Gracie, no Brasil; 0 Jiu Jitsu de Hakkoryu, criado e ensinado por Okuyama Ryuho, em Téquio; ¢ o Jeet Kune Do, criado ¢ ensinado por Bruce Lee, nos EUA. Os estudantes se dedicam 4 doutrina ensinada por aquela determinada arte, e aprendem 0 que seus mestres ensinam, geralmente ignorando os ensinamentos de outros mestres. Depois, conforme os estudantes progridem, costuma-se mudar o mestre de modo que possam expandit seus conhecimentos e praticas. Alguns, no final, continuam a fim de refinar suas habilidades, descobrem novas téenicas e criam suas préprias escolas. ‘Nenhuma dessas escolas esté 100% ceria. Mesmo assim dentro de uma determinada escola agimos como os ensinamentos ¢ técnicas fossem os certos. Apesar de tudo, hé uma forma correta de praticar o Jiu Jitsu de Hakkoryu, ou Jeet Kune Do. Mas essa retidao dentro de uma escola no invalida as técnicas de outra. Considere este livro como uma descrigdo da Escola de Cédigo Limpo da Object Mentor. As técnicas e ensinamentos sao a mancira pela qual praticamos nossa arte. Estamos dispostos a alegar que se vocé seguir esses ensinamentos, desfrutar dos beneficios que também aproveitamos aprenderd a escrever cédigos limpos e profissionais. Mas nao pense vocé que nés estamos 100% “certos”, Provavelmente ha outras escolas ¢ mestres que tém tanto para oferecer quanto nés. O correto seria que vocé aprendesse com clas também. De fato, muitas das recomendagées neste livro séo contraditorias. Provavelmente vocé nao concordara com todas ¢ podera até mesmo discordar intensivamente com algumas. Tudo bem. No podemos querer ter a palavra final. Por outro lado, pensamos bastante ¢ por muito tempo sobre as recomendagées neste livro. As aprendemos ao longo de décadas de experiéncia e repetidos testes e erros. Portanto, concorde vocé ou nao, seria uma pena se vocé nao conseguisse enxergar nosso ponto de vista.Somos Autores B Somos Autores O campo @author de um Javadoc nos diz quem somos. Nos somos autores, ¢ todo autor tem leitores, com os quais uma boa comunicagao é de responsabilidade dos autores. Na proxima vez em que vocé escrever uma linha de cddigo, lembre-se de que vocé ¢ um autor, escrevendo para eitores que julgarao seus esforcos. Vocé talvez se pergunte: 0 quanto realmente se I¢ de um cédigo? A maioria do trabalho no é escrevé-lo? Vocé ja reproduziu uma sesso de edig&o? Nas décadas de 1980 ¢ 1990, tinhamos editores, como o Emacs, que mantinham um registro de cada tecla pressionada. Vocé podia trabalhar por horas e, entdo, reproduzir toda a sua sessiio de edigao como um filme passando em alta velocidade. Quando fiz isso, os resultados foram fascinantes. ‘A grande maioria da reprodugdo era rolamento de tela e navegacdo para outros médulos! Bob entra no modulo. Ele descia até a fungdo que precisava ser alterada. Ele para e pondera suas opgées. Oh, ele sobe para o inicio do médulo a fim de verificar a inicializagéo da varidvel. Agora ele desce novamente e comeca a digitar. Opa, ele esté: apagando 0 que digitou! Ele digita novamente. Ele apaga novamente. Ele digita a metade de algo eapaga! 4 Ele desce até outra fungdo que chama a que ele esté modificando para ver como ela é, chamada. Ele sobe novamente e digita o mesmo cédigo que acabara de digitar. Ele para. Ele apaga novamente! Ele abre uma outra janela e analisa uma subclasse. A fungao é anulada? Bem, vocé entendeu! Na verdade, a taxa de tempo gasto na leitura v. na escrita é de 10x1. Constantemente lemos um cédigo antigo quando estamos criando um novo. Devido A tamanha diferenga, desejamos que a leitura do cédigo seja facil, mesmo se sua criagao for ardua. E claro que nao ha como escrever um cédigo sem lé-lo, portanto torné-lo de facil leitura realmente facilita a escrita. Nao ha como escapar desta logica. Vocé nao pode eserever um cddigo se nao quiser ler as outras partes dele. O cddigo que vocé tenta eserever hoje sera de dificil ou facil leitura dependendo da facilidade de leitura da outra parte do cdigo. Sc quiser ser rapido. se quiser acabar logo, se quiser que seu codigo seja de facil escrita, tome-o de facil leitura.4 Capitulo 1: Cédigo Limpo A Regra de Escoteiro Nao basta escrever um cédigo bom. Ele precisa ser mantido sempre limpo. Todos jé vimos cédigos estragarem e degradarem com o tempo. Portanto, precisamos assumir um papel ativo na prevengao da degradacao. ‘A Boy Scouts of America (maior organizagao de jovens escoteiros dos EUA) tem uma regra simples que podemos aplicar 4 nossa profissao, Deixe a érea do acampamenio mais limpa do que como vocé a enconirou.* Se todos deixdssemos nosso cédigo mais limpo do que quando 0 comecamos, ele simplesmente nao degradaria. A limpeza ndo precisa ser algo grande, Troque o nome de uma varidivel por um melhor, divida uma fungdo que esteja um pouco grande demais, climine um pouco de repeti¢ao de cédigo, reduza uma instrugo 4 £ aninhada. Consegue se imaginar trabalhando num projeto no qual 0 cédigo simplesmente melhorou com tempo? Vocé acredita que qualquer alternativa seja profissional? Na verdade, 0 aperfeigoamento continuo nao ¢ inerente ao profissionalismo? Prequela e Principios Em muitas maneiras este livro é uma “prequela” de outro que escrevi em 2002, chamado Agile Software Development: Principles. Patterns, and Practices (PPP). Ele fala sobre os prineipios do projeto orientado a objeto ¢ muitas das priticas utilizadas por desenvolvedores profissionais Se vocé ainda nao leu o PPP, talvez ache que € a continuagao deste livro. Se ja 0 leu, entao percebera que ele ¢ bastante parecido a esse em relacao aos codigos. Neste livro ha referencias esporddicas a diversos principios de projeto, dentre os quais esto Principio da Responsabilidade Unica (SRP, sigla em inglés), Principio de Aberto-Fechado (OCP, sigla emMinglés), Principio da Inversdo da Independéncia (DIP, sigla em inglés), dentre outros. Esses principios sao descritos detalhadamente no PPP. Conclusao Livros sobre arte ndo prometem Ihe tornar um artista. Tudo o que podem fazer ¢ Ihe oferecer algumas das ferramentas, técnicas ¢ linhas de pensamento que outros artistas usaram. Portanto, este livro no pode prometer Ihe tornar um bom programador. Ou the dar a “sensibilidade a0 cédigo”. Tudo o que ele pode fazer é Ihe mostrar a linha de pensamento de bons programadores cos truques, técnicas e ferramentas que eles usam. ‘Assim como um livro sobre arte, este esta cheio de detalhes. Ha muitos codigos. Vocé vera cédigos bons ¢ mains; cédigo ruim sendo transformado em bom: listas de heuristicas, orientagdes ¢ técnicas; ¢ também exemplo apds exemplo. Depois disso, ¢ por sua conta. que se perdeu no caminho para a apresentagao em Lembre-se daquela piada sobre o violinis eecceam: ein esacen eee: ronitinnmamtinne then mat wiih acai