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 so um complemento perfeito para nosso clima timido e, geralmente, frio. Parte do charme do Ga-lol, para nés dinamarqueses, sao 0s dizeres sébios impressos em cada caixa. Comprei dois pacotes dessa iguaria essa manha e nela veio este antigo ditado dinamarqués: ZErlighed i smé ting er ikke nogen lille ting. “Honestidade em pequenas coisas no é€ uma coisa pequena”. Era um bom pressagio para com o que eu ja desejava dizer aqui. Pequenas coisas sao importantes. Este é um livro sobre preocupagdes modestas cujos valores esto longe de ser pequenos. Deus esta nos detalhes, disse o arquiteto Ludwig Mics van der Rohe. Essa citagdo retoma, argumentos com contemporancos sobre 0 papel da arquitetura no desenvolvimento de software, especialmente no mundo Agile. Bob e eu, as vezes, acabavamos engajados entusiasmadamente debatendo sobre este assunto. E sim, Mies van der Rohe atentava para os utilitarios e as formas imemoriais de construgdo que fundamentam uma étima arquitetura. Por outro lado, ele também selecionava pessoalmente cada maganeta para cada casa que ele projetava, Por qué? Por que pequenas coisas so 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 difereneas sao relativamente irrelevantes contudo, pois podemos admitir que profissionais responsdveis dedicam algum tempo para pensar e planejar o inicio de um projeto. As nogdes de desenvolvimento dirigido apenas por testes e por cédigos do final da década de 1990 jAndo existem mais. Mesmo assim, a atengdo 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 dircito ou o azulejo levemente torto do cho, 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 metdfora para o desenvolvimento de software, especialmente para a parte que entrega 0 produto inicial no mesmo sentido que um arquiteto entrega uma construgdo imaculada. Nessa época do Scrum e do Agile, 0 foco esta em colocar 0produto rapidamente no mercado. Desejamos que a indistria funcione em velocidade maxima na producdo de software. Essas faibricas humanas: programadores que pensam e sentem que trabalham a partir das pendéncias de um produto ou do user story para criar o produto. A metéfoora da fabricago esta mais forte do que nunca no pensamento. Os aspectos da producao da manufatura japonesa de automéveis, de um mundo voltado para a linha de montagem, inspiraram grande parte do Scrum, Ainda assim, mesmo na indiistria automobilistica, a maior parte do trabalho nao esta na fabricagao, mas na manutengdo — ou na prevengdo. Em software, 80% ou mais do que fazemos & chamado de “manutengao”: 0 ato de reparar, Em vez de abracar o upico foco ocidental sobre a produg&o de bons softwares, deverfamos pensar mais como um pedreiro que conserta casas na industria de construg&o, ou um mecdnico de automdveis 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 cra na manutencdo em vez da produ¢ao. 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 jargio no cenario ocidental, e cada vez mais conhecida no mundo dos softwares. Esses principios nao so uma opedio. Assim como Uncle Bob diz em suas preliminares, a pratica de um bom software requer tal disciplina: foco, presenga de espirito ¢ 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 préximos capitulos. Seiton, ou arrumacao (pense em “sistematizar”). Ha um antigo ditado americano que diz: “Um lugar para tudo, ¢ tudo em seu lugar”. Um pedago de cédigo deve estar onde vocé espera encontré-lo — caso nao esteja, refatore e o coloque 1a. Seiso, ou limpeza (pensem em “polir”); manter 0 local de trabalho livre de fios pendurados, gordura, migalhas e 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 padronizacao: a equipe concorda em manter o local de trabalho limpo. Vocé acha que este livro fala algo sobre ter um estilo de programacaio consistente e uma série de priticas dentro da equipe? De onde vém tais padrées? Continue a leitura. Shutsuke, ou disciplina (autodisciplina). Isso significa ter disciplina para seguir as priticas refletir frequentememt isso no trabalho e estar disposto a mudar. Se aceitar o desafio — isso, 0 desafio — de ler e aplicar o que ¢ aconselhado neste livro, yocé entendera e apreciara o ultimo item. Aqui estamos finalmente indo em dire¢do as raizes do profissionalismo responsavel numa profissio que deve se preocupar com o ciclo de vida de um produto. Conforme facamos a manutengao de automéveis ¢ outras maquinas na TPM, a manutencao 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 dleo para testar o desgaste. No cédigo, a refatoracdo é impiedosa. Vocé ainda pode melhorar um nivel a mais com 0 advento do movimento da TPM ha 50 anos; construa maquinas que sejam passiveis de manutengao. Tornar seu cédigo legivel ¢ tio importante quanto tornd-lo executavel. A ultima pratica, adicionada a TPM em tomo de 1960, ¢ focar na incluso de maquinas inteiramente novas ou substituir as antigas. Como nos adverte Fred Brooks, provavelmente devemos refazer partes