Código Limpo — Código ruim

Recentemente li o prefácio do livro Implementations Patterns de Kent Beck, no qual ele diz “… este livro baseia-se numa premissa frágil de que um bom código importa…”. Uma premissa frágil? Não concordo! Acho que essa pressa é uma das mais robustas, apoiadas e plenas do que todas as outras em nossa área (e 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 extraordinário que se tornou muito popular e muitos profissionais o compraram e usaram. Mas, então, o intervalo entre os lançamentos das novas distribuições começou a aumentar. Os bugs não eram consertados na distribuição seguinte. E o tempo de carregamento do aplicativo e o número de travamentos aumentaram. Lembro-me do dia em que frustrado, fechei o programa e nunca mais o usei. A empresa saiu do mercado logo depois.

Duas décadas depois encontrei um dos funcionários de tal empresa na época e o perguntei o que havia acontecido, e o que eu temia fora confirmado Eles tiveram de apressar o lançamento do produto e, devido a isso, o código ficou uma zona. Então, conforme foram adicionando mais e mais recursos, o código piorava cada vez mais até que simplesmente não era mais possível gerenciá-lo. Foi o código ruim que acabou com a empresa.

Alguma vez um código ruim já lhe atrasou consideravelmente? Se você for um programador, independente de sua experiência, então já se deparou várias vezes com esse obstáculo. Aliás, é como se caminhássemos penosamente por um lamaçal de arbustos emaranhados com armadilhas ocultas. Isso é o que fazemos num código ruim. Pelejamos para encontrar nosso caminho, esperando avistar alguma dica, alguma indicação do que esta acontecendo; mas tudo o que vemos é um código cada vez mais sem sentido.

É claro que um código ruim já lhe atrasou. Mas, então, por que você o escreveu dessa forma?

Estava tentando ser rápido? Estava com pressa? Provavelmente. Talvez você pensou que não 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 e queria terminá-lo logo. Ou verificou a lista de coisas que havia prometido fazer e percebeu que precisava finalizar este módulo de uma vez, de modo que pudesse passar para o próximo.

Todos já fizemos isso, já vimos a bagunça que fizemos e, então, optamos por arrumá-las outro dia. Todos já sentimos aliviados ao ver nosso programa confuso funcionar e decidimos que uma bagunça que funciona é melhor do que nada. Todos nós já dissemos que reviraríamos e limparíamos o código depois. É claro que naquela época não conhecíamos a lei de LeBlanc: Mais tarde é igual a nunca.

“…”

Atitude

Você já teve de trabalhar penosamente por uma confusão tão grave que levou semanas o que deveria ter levado horas? Você já presenciou o que deveria ser uma alteração única e direta, mas que em vez disso foi feita em diversos módulos distintos? Todos esses sintomas são bastante comuns.

Por que isso ocorre em um código? Por que um código bom se decompõe tão rápido em um ruim? Temos diversas explicações para isso. Reclamamos que os requisitos mudaram de tal forma que estragaram o projeto original. Criticamos os prazos por serem curtos demais para fazemos as coisas certas. Resmungamos sobre gerentes tolos e cliente intolerantes e tipos de marketing inúteis e técnicos de telefone. Mas o padrão, querido Dilbert, não esta em nossas estrelas, mas sim em nós mesmos. Somos profissionais.

Isso pode ser algo difícil de engolir. Mas como poderia essa zona ser nossa culpa? E os requisitos? E o prazo? E os tolos gerentes e tipo de marketing inúteis? Eles não carregam alguma parcela da culpa?

Não. Os gerentes e marketeiros buscam em nós as informações que precisam para fazer promessas e firmarem compromissos; e mesmo quando não nos procuram, não devemos dar uma de tímidos ao dizer-lhes nossa opinião. Os usuários esperam que validemos as maneiras pelas quais os requisitos se encaixarão no sistema. Os gerentes esperam que os ajudemos a cumprir o prazo. Nossa cumplicidade no planejamento do projeto é tamanha que compartilhamos de uma grande parcela da responsabilidade em caso de falhas; especialmente se estas forem um relação a um código ruim.

“Mas, espere!”, você diz. “E se eu não fizer o que meu gerente quer, serei demitido”. É provável que não. A maioria dos gerentes quer a verdade, mesmo que demonstrem o contrário. A maioria deles quer um código bom, mesmo estourando o prazo. Eles podem proteger com paixão o prazo e os requisitos, mas essa é a função deles. A sua é proteger o código com as mesma paixão.

Para finalizar essa questão, e se você fosse médico e um paciente exigisse que você parasse com toda aquela lavação das mãos na preparação para a cirurgia só porque isso leva muito tempo? É óbvio que o chefe neste caso é o paciente; mas, mesmo assim, o médico deverá totalmente se recusar obedecê-lo. Por que? Porque o médico sabe mais do que o paciente sobre os riscos de doenças e infecções. Não seria profissional (sem mencionar criminoso) que o médico obedecesse ao paciente neste cenário.

Da mesma forma que não é profissional que programadores cedam á vontade dos gerentes que não entendem os riscos de se gerar códigos confusos.

Escrito por Robert C. Martin em seu livro “Código Limpo: habilidades práticas do Agile Software”, publicado pela Alta Books Editora — 2011