achei um método de 4.200 linhas no sistema do banco. o nome dele é processaTudo()
Caio Nascimento@caio_backend
Contents
tô alocado num projeto de banco faz 4 meses (não vou dizer qual, meu contrato tem cláusula até pra respirar kkkk). semana passada fui corrigir um bug de tarifa e o stack trace apontou pra linha 3.847 de uma classe. linha 3.847. de UM método.
senhoras e senhores, apresento processaTudo(Map<String, Object> params):
- 4.200 linhas
- 37 "parâmetros", todos dentro de um Map de String pra Object. boa sorte adivinhando o tipo
- SQL montado com concatenação de string. sim. SQL injection esperando o momento certo
catch (Exception e) {}vazio. 11 vezes. eu contei- um comentário
// NAO MEXER - R. 2009e, 200 linhas depois,// mexi - F. 2014. o F. é herói ou vilão, ainda não decidi - e meu favorito:
Thread.sleep(3000); // espera o mainframe
a primeira reação do time foi "vamos reescrever". a minha foi "vamos não". porque esse método, por mais feio que seja, calcula tarifa de milhões de contas há 15 anos. tem 15 anos de regra de negócio que ninguém documentou. reescrever do zero é jogar fora 15 anos de bug corrigido.
o que a gente fez
- golden master. pegamos 2 semanas de entradas reais dos logs (mascaradas, óbvio), rodamos no método e salvamos as saídas. isso virou nossa suíte de teste: qualquer mudança que altere uma saída quebra o teste
- extract method, devagar. com os testes no lugar, fomos extraindo pedaços com o refactoring da IDE. hoje o processaTudo tem 600 linhas e chama 14 métodos com nome de gente
- o SQL concatenado virou PreparedStatement, um por um. esse foi prioridade, nem esperou o resto
- o Thread.sleep. achamos que era besteira, tiramos, e quebrou. o mainframe realmente leva uns segundos pra gravar um arquivo que esse código lê logo depois. trocamos por polling com timeout. continua feio, mas agora é feio com log
o que eu aprendi (de novo)
- código feio que funciona há 15 anos merece respeito antes do bisturi
- teste primeiro, opinião depois
- o comentário "NAO MEXER" quase sempre tem um motivo. o motivo quase nunca tá escrito
- esse método paga meu salário. criei carinho por ele. é tipo um cachorro velho que morde
alguém aí tem um processaTudo pra chamar de seu? conta aí kkkkk
Get the best of #legacy-code-archaeology weekly
One email each Monday with the most useful posts. No spam; unsubscribe in one click.
Comments
Sign in to join the conversation.
Sign in to commentAna Clara Ribeiro@anaclara_r
Boa noite, Caio. Aqui no serviço público temos um chamado executaRotina() com 6 mil linhas e um comentário 'conforme reunião de 2007'. Ninguém sabe que reunião foi essa. Solidariedade.
Caio Nascimento@caio_backend
'conforme reunião de 2007' kkkkkkkk Ana Clara isso é patrimônio histórico, tem que tombar
Walt Hendricks@walt_mainframe
Translated. The Thread.sleep 'to wait for the mainframe' made me laugh out loud. I was probably the mainframe. Golden master testing is exactly right, we did the same with COBOL batch outputs in 1998 for Y2K.
Caio Nascimento@caio_backend
haha Walt you are a legend. the mainframe is still there, and still faster than our microservices
Javier Montero@javi_montero
En mi banco tenemos uno parecido, se llama procesarOperacion y tiene 3.000 líneas. Lo de 'NO TOCAR 2009' es universal, por lo visto. Y lo de no reescribir, 100% de acuerdo: el que propone reescribir siempre es el que llegó hace 3 meses.
S. Ramanathan@ramanathan_retd
Dear Caio, In our bank we had a COBOL paragraph called PROCESS-ALL. It was 9,000 lines. The man who wrote it retired in 2004 and we used to call him at home. He always picked up. Kindly write tests before touching, as you have done. With regards.
Frank Ostrowski@frank_cpp98
4200 lines is a medium sized function where i come from. try a 12k line switch statement in a 1997 billing system written in C. kids these days
Omkar Joshi@omkar_java
Translated it. Exactly what we do on bank projects in Pune. We found a 'sleep for the mainframe' also, 5 seconds, we call it 'the prayer'.