 |
| Bellacosa Mainframe apresenta boy scout rules |
☕ Um Café no Bellacosa Mainframe
Boy Scout Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Não Era Mantida por Heróis… Mas por Pequenas Melhorias Feitas Todos os Dias
"Você não precisa reescrever a Matrix inteira. Basta deixá-la um pouco melhor cada vez que passar por ela."
Prólogo — A Sala Esquecida da Matrix
Após anos atravessando corredores infinitos da Matrix, Neo começou a notar algo estranho.
Algumas partes pareciam modernas.
Outras lembravam sistemas criados décadas antes.
Havia corredores impecáveis.
Outros estavam escuros.
Cabos pendurados.
Portas enferrujadas.
Painéis quebrados.
Neo perguntou ao Arquiteto:
— Quem deixou isso assim?
O Arquiteto respondeu:
— Ninguém.
Neo estranhou.
— Como assim ninguém?
O Oráculo apareceu carregando uma velha lanterna.
Caminhou lentamente por um corredor abandonado.
Pegou um cabo solto.
Prendeu-o corretamente.
Apagou uma mensagem de erro antiga.
Organizou alguns arquivos.
Depois continuou andando.
Neo perguntou:
— Isso resolve o problema da Matrix?
Ela respondeu:
— Não.
Resolve apenas este corredor.
Neo insistiu:
— Então por que perder tempo?
Ela sorriu.
— Porque milhares de pessoas fizeram exatamente isso durante muitos anos.
É por isso que a Matrix ainda funciona.
Naquele instante Neo compreendeu a Boy Scout Rule.
O que é a Boy Scout Rule?
A regra é extremamente simples.
"Always leave the campground cleaner than you found it."
Em português.
"Sempre deixe o acampamento mais limpo do que você encontrou."
Na Engenharia de Software ela foi adaptada para:
"Deixe o código um pouco melhor do que encontrou."
Não significa reescrever tudo.
Significa realizar pequenas melhorias sempre que tocar em um trecho de código.
A origem da regra
A inspiração vem do movimento dos Escoteiros (Boy Scouts of America).
Existe uma orientação tradicional ensinada aos jovens escoteiros:
Quando abandonar um acampamento.
Deixe-o melhor do que estava.
Mesmo que isso signifique apenas:
recolher um papel;
apagar uma fogueira;
organizar algumas pedras.
Na Engenharia de Software, Robert C. Martin (Uncle Bob) popularizou essa ideia como um hábito de desenvolvimento.
Matrix explica perfeitamente
Imagine que milhões de pessoas percorrem diariamente os corredores da Matrix.
Cada uma realiza apenas uma pequena melhoria.
No fim do ano.
Toda a Matrix está melhor.
Agora imagine o contrário.
Todos dizem:
"Não fui eu quem bagunçou."
Resultado.
O sistema envelhece rapidamente.
O COBOL vive exatamente esse cenário
Existem aplicações bancárias com:
trinta;
quarenta;
cinquenta anos.
Nenhuma equipe consegue parar tudo para reescrever esses sistemas.
Mas milhares de pequenas melhorias acumuladas durante décadas fazem enorme diferença.
O efeito da melhoria contínua
Imagine um programa COBOL.
Você entra apenas para alterar uma regra tributária.
Durante a alteração percebe:
variável mal nomeada;
comentário desatualizado;
código morto;
PERFORM desnecessário;
IF duplicado.
Você corrige.
Leva cinco minutos.
O próximo programador agradecerá.
Matrix Reloaded
Neo observa Zion sendo mantida.
Não existem apenas engenheiros brilhantes.
Existem centenas de pessoas realizando pequenas manutenções diariamente.
É isso que mantém a cidade viva.
O efeito psicológico
Existe um pensamento perigoso.
"Isso não é problema meu."
A Boy Scout Rule combate exatamente essa mentalidade.
Ela transforma todos em responsáveis pela qualidade coletiva.
O Programador COBOL Padawan
Você abre um programa.
Encontra:
MOVE ZERO TO WS-X.
MOVE ZERO TO WS-Y.
MOVE ZERO TO WS-Z.
Poderia deixar.
Mas decide organizar.
Talvez usar inicialização mais clara.
Talvez melhorar nomes.
Talvez remover duplicações.
Nenhuma dessas mudanças altera o negócio.
Mas todas melhoram a manutenção.
O Agente Smith adora abandono
Smith não destrói sistemas apenas criando bugs.
Ele espera.
Espera que pequenas sujeiras se acumulem.
Comentários antigos.
Variáveis confusas.
Código morto.
Layouts duplicados.
Depois de alguns anos.
A manutenção torna-se um pesadelo.
Um exemplo inspirado na Matrix
Imagine uma escada.
Cada pessoa deixa uma pequena pedra sobre um degrau.
Nenhuma pedra parece importante.
Anos depois.
A escada torna-se intransitável.
Agora imagine o contrário.
Cada pessoa remove uma pedra.
A escada permanece limpa para sempre.
Pequenas melhorias fazem enorme diferença
Você pode:
alinhar código;
renomear variáveis;
remover comentários incorretos;
apagar código morto;
dividir um PERFORM enorme;
atualizar documentação;
melhorar mensagens de erro.
Nada disso muda o negócio.
Mas muda profundamente a qualidade.
O impacto no Mainframe
No ambiente IBM Z encontramos frequentemente:
programas COBOL escritos por dezenas de equipes ao longo de décadas;
COPYBOOKs antigos;
comentários que não correspondem mais ao código;
JCLs com parâmetros obsoletos;
procedimentos duplicados.
Esperar uma reescrita completa é, muitas vezes, inviável.
A Boy Scout Rule oferece um caminho realista: evoluir continuamente.
Curiosidade
Muitas empresas perceberam que a maior parte da dívida técnica não nasce de grandes erros arquiteturais.
Ela surge de pequenas negligências repetidas diariamente.
Uma variável mal nomeada hoje.
Um comentário errado amanhã.
Uma duplicação na semana seguinte.
Meses depois.
Temos um sistema difícil de manter.
Atenção!
Boy Scout Rule não significa:
Refatorar o sistema inteiro enquanto corrige um pequeno bug.
Esse é um erro bastante comum.
A diferença
Boa prática
Corrigir um pequeno problema relacionado ao trecho alterado.
Exagero
Transformar uma correção simples em um projeto de seis meses.
Matrix e o Oráculo
O Oráculo nunca tenta reconstruir toda a Matrix.
Ela influencia pequenas decisões.
Uma conversa.
Uma escolha.
Uma melhoria.
No final.
Essas pequenas ações mudam toda a história.
Um exemplo COBOL
Antes.
IF WS-A = "S"
MOVE "A" TO WS-X
ELSE
MOVE "B" TO WS-X
END-IF
Você percebe que o comentário acima diz:
Calcula imposto.
Mas o código não calcula imposto algum.
Atualiza o comentário.
Parece pequeno.
Mas evita confusão futura.
Outro exemplo
Você encontra:
WS-TEMP1
WS-TEMP2
WS-TEMP3
Durante a manutenção.
Renomeia para:
WS-SALDO-ATUAL
WS-LIMITE-CREDITO
WS-VALOR-PARCELA
Nenhuma regra mudou.
Mas a legibilidade aumentou enormemente.
Ferramentas ajudam
Hoje possuímos excelentes ferramentas para apoiar pequenas melhorias contínuas.
Entre elas:
IBM ADDI.
SonarQube.
COBOL Check.
IBM Developer for z/OS.
IBM Z Open Editor.
Git.
Pull Requests.
Code Review.
IA Generativa.
Elas ajudam a identificar pontos simples que podem ser aprimorados sem grandes impactos.
O papel da IA
A Inteligência Artificial tornou-se uma excelente parceira da Boy Scout Rule.
Ela consegue sugerir:
nomes melhores;
simplificação de IFs;
remoção de código morto;
reorganização de PERFORMs;
comentários mais claros;
duplicações.
Mas a decisão continua sendo humana.
Nem toda sugestão melhora o sistema.
Os riscos
Ignorar pequenas melhorias produz:
crescimento da dívida técnica;
manutenção lenta;
onboarding difícil;
maior número de bugs;
baixa produtividade.
Erros clássicos
"Depois alguém arruma."
"Sempre foi assim."
"Não vale a pena."
"Não é minha responsabilidade."
"Funciona, então deixa."
Essas frases envelhecem sistemas muito rapidamente.
Boas práticas
Corrigir pequenos problemas ao modificar um módulo.
Atualizar comentários inconsistentes.
Remover código morto.
Melhorar nomes de variáveis.
Eliminar duplicações simples.
Organizar PERFORMs.
Registrar decisões importantes.
Boy Scout Rule conversa com toda esta série
Esse princípio é praticamente um elo entre todos os conceitos estudados até aqui.
Ele ajuda a combater:
Technical Debt, reduzindo o acúmulo de dívida técnica.
Lava Flow, removendo pequenos trechos abandonados.
Spaghetti Code, reorganizando gradualmente o código.
Big Ball of Mud, promovendo pequenas melhorias estruturais.
DRY, eliminando duplicações encontradas durante a manutenção.
KISS, simplificando trechos excessivamente complexos.
YAGNI, removendo funcionalidades desnecessárias.
Murphy's Law, fortalecendo validações e tratamentos de erro.
SOLID, aproximando o código de responsabilidades mais claras.
Em vez de esperar um grande projeto de modernização, a qualidade cresce continuamente.
Aplicabilidade
A Boy Scout Rule pode ser aplicada em praticamente qualquer área da engenharia:
COBOL.
CICS.
Db2.
JCL.
REXX.
Java.
Python.
APIs.
DevOps.
Infraestrutura como Código.
Documentação.
Pipelines CI/CD.
Playbooks Ansible.
Ela não depende de tecnologia.
Depende de cultura.
O ensinamento do Oráculo
O Oráculo leva Neo até um velho jardim dentro da Matrix.
O chão está coberto por folhas.
Ela entrega uma pequena vassoura.
Neo pergunta:
— Vamos limpar tudo?
Ela responde:
— Não.
Limpe apenas o caminho por onde passaremos hoje.
Horas depois.
Outras pessoas fazem o mesmo em outros caminhos.
Dias depois.
O jardim inteiro está limpo.
Sem que ninguém tenha realizado uma grande reforma.
Ela olha para Neo e diz:
"Quem espera pela grande transformação normalmente não muda nada. Quem melhora um pequeno detalhe todos os dias acaba transformando o mundo inteiro."
Lições para um Programador COBOL Padawan
Durante sua carreira você herdará programas escritos por profissionais que talvez nunca conheça.
Alguns serão excelentes.
Outros nem tanto.
Resista à tentação de criticar quem veio antes.
Lembre-se de que aqueles sistemas sobreviveram porque alguém os manteve funcionando.
Sua missão agora é continuar essa história.
Sempre que modificar um programa, pergunte:
Posso melhorar o nome desta variável?
Posso remover este trecho morto?
Este comentário ainda faz sentido?
Posso reduzir esta duplicação?
Posso tornar este IF mais legível?
Posso registrar melhor esta decisão?
Se a resposta for "sim" e o risco for baixo, faça a melhoria.
A próxima pessoa que abrir esse código talvez seja você mesmo daqui a cinco anos.
Curiosidades
A Boy Scout Rule influenciou fortemente práticas modernas como:
Clean Code, de Robert C. Martin.
Refatoração Contínua, popularizada por Martin Fowler.
Trunk-Based Development, incentivando pequenas mudanças frequentes.
Continuous Integration, reduzindo grandes refatorações.
Code Review, estimulando melhorias incrementais.
InnerSource, promovendo responsabilidade coletiva sobre o código.
Todas compartilham uma mesma visão:
qualidade é construída diariamente, não apenas em grandes projetos de modernização.
Conclusão — A Matrix Não Foi Salva em um Único Dia
Neo derrotou Smith em uma batalha decisiva.
Mas a Matrix não permaneceu estável por causa daquele único momento.
Ela continuou existindo porque milhares de pequenas correções, ajustes e melhorias foram realizadas continuamente ao longo do tempo.
Na Engenharia de Software acontece exatamente o mesmo.
A Boy Scout Rule nos ensina que grandes sistemas não envelhecem bem por acaso. Eles envelhecem bem porque cada desenvolvedor deixa uma pequena contribuição positiva sempre que toca no código.
Para um Programador COBOL trabalhando em IBM Z, essa filosofia é especialmente poderosa. Não é necessário esperar um projeto milionário de modernização para melhorar um sistema legado. Pequenas melhorias consistentes, feitas com responsabilidade e baixo risco, acumulam um enorme ganho de qualidade ao longo dos anos.
No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na entrada da oficina de manutenção da Matrix:
"Você talvez não tenha tempo para reconstruir toda a Matrix hoje. Mas sempre terá tempo para deixar um único corredor melhor do que o encontrou. E quando milhares de engenheiros fizerem o mesmo, a própria Matrix parecerá nova sem jamais ter sido reconstruída."
Porque o verdadeiro legado de um engenheiro não é apenas o código que ele escreve.
É o código que ele entrega em condições melhores para a próxima geração de Padawans.
