Quero assegurar, mais uma vez, que o descrito nesse artigo ou em qualquer outro neste blog, expressa apenas a minha opinião, não a do meu empregador ou clientes.
Antes, vou reforçar, com um exemplo, o que foi escrito no último post.
Assumi uma aplicação em Delphi que é relativamente simples, mas foi programada com uma complexidade desnecessária. Na última melhoria solicitada, relativamente complexa, resolvi criar algumas classes para a área da aplicação que seria impactada.
Comecei a colher os benefícios da OO ainda neste chamado, já que esta modificação gerou outras necessidades do cliente. Com o código antigo, eu levaria cerca de uma hora para resolver cada necessidade. Com a OO, consegui resolver em cerca de 15 minutos cada uma. Um quarto do tempo. Também é digno de nota que a alteração em uma classe resolveu cerca de um terço das necessidades.
Eu deveria ter colocado o início do parágrafo anterior no plural, pois todos os envolvidos foram beneficiados:
- Cliente - Para este, o ganho é claro, pois pagou cerca de 25% do valor que pagaria antes das alterações. Teve os seus problemas corrigidos de forma mais ágil e o impacto no negócio foi mínimo. Mesmo assim, é difícil mostrar para o cliente os benefícios de um código limpo e bem estruturado;
- Consultoria - Mesmo parecendo que deixou de ganhar com o tempo das correções, a equipe que antes estaria perdendo muito tempo com estas correções, pode estar dando atenção a outros assuntos. Já atuei em consultorias pequenas, médias e grandes e posso garantir que até as pequenas, normalmente, tem mais problema que braço;
- Desenvolvedor - A fila de to-do de um desenvolvedor, normalmente, não é pequena. Perda de meta sempre estoura no colo do analista. Com códigos mais eficientes, as correções irão durar menos tempo e é mais provável que as metas sejam cumpridas.
Agora que já coloquei, mais uma vez, a minha visão de como um código bem estruturado beneficia a todos, vamos as perguntas:
Quando fazer as alterações não contempladas em um chamado?
A resposta a essa pergunta é complicada, porque, normalmente depende de vontade do Analista. Eu, como bom psicopata e vislumbrando uma vida melhor no futuro, faço essas alterações fora do horário do expediente. Cobro do chamado o tempo que eu levaria para atender sem a refatoração. Alguém diria: "Mas nem relógio trabalha de graça". Nesses casos, eu trabalho.
Onde fazer essas alterações?
Esta pergunta não estava inicialmente programada, mas achei pertinente. A melhoria de código deve ser executada nos módulos ou artefatos impactados pela mudança solicitada no chamado. Dessa forma, outras áreas não serão impctadas e as alterações serão exaustivamente testadas pelas equipes de teste.
Como fazer de forma segura?
Em primeiro lugar, mexendo só na área impactada pela solicitação do cliente. Dessa forma, asseguramos que as alterações estarão no escopo das equipes de testes. Em segundo lugar, fazendo o que venho marretando em alguns fóruns ao longo do tempo, coberto por testes. Refatorar sem uma suite de testes bem feita é suicídio.
Como ser eficiente para não afetar as metas?
Respondi a essa pergunta na primeira resposta. Para um futuro melhor, até enfiar na cabeça de cliente e consultoria que melhoria de código é bom para todo mundo, faço isso de graça, fora do expediente.
Para finalizar, como considero isso um assunto polêmico, volto a dizer que isso reflete a minha opinião e não as dos meus colegas analistas, gerentes, consultoria, cliente ou qualquer outra pessoa que venha a se sentir ofendido com as minhas palavras.
Nota: Trabalhar de graça, não me motiva, não me deixa mais feliz. É lamentável a visão que ainda temos hoje do "está funcionando, não mexe". O que me deixa feliz é ver o código novo na próxima manutenção. Isso torna o trabalho prazeiroso.
Nota 02: Não refatoro apenas código legado de outras pessoas. Vivo tentando aperfeiçoar o meu trabalho. E fazer isso de graça no meu código, devo confessar, é um prazer.
Nenhum comentário:
Postar um comentário