Recentemente, fiz a leitura do livro Clean Coder (O codificador limpo) do autor Robert C. Martin, carinhosamente apelidado pela comunidade de TI como uncle Bob, e me surpreendi com o conteúdo apresentado. Nesse livro, uncle Bob comenta sobre hard e soft skills necessárias para um profissional de software competente, compartilhando suas experiências pessoais e lições aprendidas ao longo de seus mais de 50 anos trabalhando como programador.

Diferente de um livro técnico sobre ferramentas e códigos, esse livro apresenta posturas e comportamentos sugeridos para desenvolvedores de software e abaixo irei apresentar algumas que considerei relevantes.

Responsabilizar-se pelos bugs

O programador deve escrever o código garantindo que este funcione, o que significa que o código deve ser testado pelo programador antes de ser mandado para o profissional de teste. Eventuais bugs encontrados serão responsabilidade do programador que deve buscar diminuir cada vez mais sua taxa de erros, conforme amadurece profissionalmente. 

Refatorar códigos legados

Mudanças que ajudam a flexibilizar um código devem ser feitas sempre que o programador ler o código. Quando estamos trabalhando em um sistema, ocorre com frequência, depararmos com códigos legados e o programador deve buscar melhorá-lo, desde que a alteração não tenha um custo alto.

Conhecer o domínio do negócio

Um programador comprometido deve ter um bom entendimento do domínio de negócio do sistema em que está trabalhando. É essencial que ele colabore com especialistas, clientes e usuários para compreender plenamente as regras do sistema que está desenvolvendo. Dessa forma, o código que ele escreve não será baseado em suposições pessoais, mas será fiel às necessidades reais do negócio.

Negociar prazos

A negociação é fundamental para a entrega de um software. Os product owners e demais stakeholders comunicam as especificidades do produto enquanto que cabe aos programadores estimarem o prazo em que será desenvolvido e com isso, negociar um prazo realista. Mesmo que exista momentos desconfortáveis durante a negociação, ela deve ser feita de forma que todas as partes estejam de acordo e que a solução seja mutuamente aceitável.

Não comprometer entregas que existam dependências não resolvidas

Deve ser comprometido apenas o que se tem pleno controle sobre. Entregas que dependem de terceiros são riscos e portanto não devem ser acordadas. Para contornar a situação, é possível que seja comprometido ações para trazer o objetivo final mais próximo de ser alcançado.

Manter a transparência dos prazos

Não é incomum ocorrer atrasos, porém, é importante que a detecção seja rápida e que seja comunicado com transparência aos envolvidos de que o prazo não será cumprido. O progresso do desenvolvimento do código deve ser medido regularmente considerando três datas: uma para o melhor caso, uma para o caso nominal e outra para o pior caso.

Pedir ajuda

O programador não deve se sentir envergonhado ou culpado por pedir ajuda. Sempre que estiver confuso, enfrentando um problema ou sem foco, é importante comunicar-se com os colegas de trabalho. A colaboração é fundamental para um código eficiente.

Criar testes de unidade

Testes de unidade documentam o design, a estrutura e o comportamento do sistema. Todas as linhas de código devem ser testadas. Além disso, ao escrever os testes, fica evidente partes do código que precisam de refatoração, já que esses devem ser fáceis de criar. Se encontrar dificuldade para escrever os testes, isso indica que o código provavelmente precisa ser refatorado.

Recomeçar códigos “lamaçais”

Uncle Bob usa o termo "lamaçal" para descrever situações em que o código se torna tão complexo que o programador acaba identificando uma falha no design durante o desenvolvimento. Nesses casos, é comum pensar que recomeçar seria mais custoso do que seguir em frente. No entanto, é recomendável que, ao se deparar com essa situação, o programador retrabalhe e refaça o código desde o início.

Essas são algumas situações comuns no dia a dia de um profissional de TI, e, muitas delas, foram vivenciadas por uncle Bob durante sua jornada como programador. 

E você, já leu esse livro?! O que achou dos tópicos abordados?! Compartilhe sua opinião!