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