"O manual não me deixa refatorar meu código legado!" Situação comum? Terrivelmente irritante. A maioria dos desenvolvedores, mais cedo ou mais tarde, se depara com um gerente que não tem nenhum interesse em melhorar o que já está pronto. Eles precisam implementar algo novo, ou apagar o fogo com urgência, ou consertar algum bug ... Em geral, eles sempre encontrarão um motivo para adiar a refatoração da base de código em execução.
E mesmo quando você tenta explicar a eles os benefícios de um código organizado, eles não entendem ou não querem entender. Eles só pensam em custos e tempo, e ninguém se preocupa com a qualidade. E acontece que você é absolutamente impotente para fazer algo com a dívida técnica, que ainda está se acumulando e se acumulando. Os programadores trabalham para prod e prod - para solicitações de usuários impacientes. Ninguém vai pagar pela refatoração. A situação parece desesperadora.
Quando confrontados com tal situação, muitos desenvolvedores inteligentes simplesmente empacotam suas coisas e deixam a empresa. E muito em breve, por causa da rotatividade no departamento, as portas não se fecham mais: uns vão embora, outros vêm ...
Gerentes não são programadores
A solução para o problema é comunicar aos gerentes o impacto da má qualidade do código nos negócios. Em última análise, as atividades da empresa visam ganhar dinheiro. Chegou. Conseqüentemente, a administração está procurando as melhores maneiras de cortar custos e aumentar as receitas. Isso significa que, para reabilitar a refatoração aos olhos deles, eles terão que falar sua língua.
Acontece que eu trabalhei tanto como líder técnico quanto consultor, então tenho muita experiência neste negócio. Vamos compartilhar com vocês alguns modelos.
Cinco argumentos que você pode dar
1) “A refatoração ajudará a reduzir a volatilidade dos custos marginais por unidade de funcionalidade do software”
Esta é uma citação precisa da excelente palestra de JB Reinsberg na conferência “Economics in Software Development”. Espere, não vá! Tudo o que é dito aqui, você sabe perfeitamente, é simplesmente formulado em um espírito abstrato e obscuro.
Vamos em ordem:
- "Refatorar ajudará a reduzir ..." - até agora, está tudo bem
- "... volatilidade ..." - em outras palavras, imprevisibilidade
- "... custo marginal ..." - isto é, quanto recurso será necessário para produzir mais uma unidade adicional
- “… Por unidade de funcionalidade do software” é um recurso que tem valor para os negócios. Hooray! O valor comercial é exatamente o que precisamos.
Todos os cinco argumentos baseiam-se na mesma ideia geral de tradução de um idioma para outro, que muitas vezes negligenciamos ao lidar com pessoas distantes da esfera de TI. Não use gírias, apóie-se em conceitos de economia e negócios - esse é todo o ingrediente secreto. Isso estabelecerá uma conexão entre você e a gerência mais rapidamente.
2) "No mês passado, 63% do recurso de desenvolvimento foi gasto em consertar problemas de qualidade do produto"
Bem, substitua seus números aqui. O objetivo é fazer backup da mensagem com dados quantitativos. A dívida de tecnologia não pode ajudar, mas afeta seus processos de trabalho do dia a dia. Você pode provar isso? Claro!
Aqui estão algumas métricas que você pode observar:
- . ? ?
- -, , . , ? ?
- , . ? ?
Mostre ao gerenciamento exatamente o que a má qualidade do código representa para eles. Melhor ainda, encontre uma maneira de traduzir esses números em valor monetário.
Certa vez, participei de um bug post-mortem que poderia ter sido evitado se a verificação do tipo de dados tivesse sido realizada. O código foi escrito em JavaScript. Naquela época, houve um debate na empresa sobre a mudança para o TypeScript.
Os desenvolvedores que entenderam o que aconteceu não tiveram preguiça de levantar os dados e foram capazes de avaliar os danos que o bug causou ao negócio. Descobriu-se que, em poucos meses de existência, o bug sugou um milhão de dólares canadenses da empresa. Milhão! Isso por si só teria sido suficiente para compensar o custo de mudança para o TypeScript.
Com base nisso, foi decidido que os novos serviços serão implementados em TypeScript e, para os mais importantes, os tipos de dados devem ser verificados retroativamente.
3) “Do ponto de vista técnico, trabalhamos a crédito para lançar o produto com mais rapidez. Agora precisamos pagar parte da dívida para que o time to market não aumente. ”
Novamente: falamos a língua do interlocutor. As metáforas podem ser muito eficazes quando você precisa transmitir uma mensagem: elas conectam conceitos desconhecidos com outros familiares para o ouvinte e, assim, ajudam a entendê-los. O conceito de "crédito" é bem conhecido de qualquer gerente. E a própria "dívida técnica" também é uma metáfora que tem recebido ampla circulação.
Ou, digamos, imagine uma empresa como um restaurante e uma base de código como sua área de cozinha. À medida que a louça suja se acumula, servir um número cada vez maior de visitantes torna-se cada vez mais difícil. Os funcionários precisam de tempo para lavar os pratos entre as preparações.
4) "Se você investir 10% do seu tempo na qualidade do código, sua rotatividade cairá significativamente."
Até agora, falamos sobre as consequências óbvias da baixa qualidade do código. Mas há uma coisa insidiosa que é fácil de ignorar: a rotatividade.
Atualmente, as empresas estão tendo dificuldade em manter os desenvolvedores, especialmente os talentosos, trabalhando nelas. Se tal pessoa deixar de gostar do trabalho, não será difícil para ela conseguir outra oferta e simplesmente ir aonde quer que olhe, longe do caos eterno. Ora, talvez você já esteja procurando algo melhor ...
E agora vamos nos perguntar: quanto custa a empresa para substituir um desenvolvedor resignado? Um novo especialista precisa ser encontrado, acompanhado pelo processo de contratação e atualizado. É preciso investimento, tempo e coloca toda a equipe em espera. A gerência definitivamente prefere não fazer esse tipo de remodelação todos os anos. Portanto, reduzir a fluidez pode ser um argumento sério. E o próprio fato de ter um plano para eliminar o déficit técnico já dará +100 à motivação de toda a equipe.
5) "Se você investir 20% do recurso em refatoração, o FRT será reduzido pela metade e o ROI será positivo para a produtividade do desenvolvedor"
FRT é o tempo de resposta, uma métrica importante para o suporte ao usuário. A empresa se esforça para garantir que os clientes estejam satisfeitos com tudo.
Aqui fazemos o seguinte:
- Escolher métricas que tenham muito peso no suporte técnico;
- Encontramos alguns problemas que surgem regularmente e requerem intervenção do desenvolvedor;
- Oferecemos um plano para reduzir o número de chamadas para o suporte técnico, eliminando a causa raiz.
- Se esses tipos de problemas forem resolvidos, os desenvolvedores terão menos probabilidade de se envolver nas tarefas de suporte ao cliente. Ou seja, eles vão liberar mais tempo do que foi gasto na refatoração, o que significa que o investimento valerá a pena - aquele ROI muito positivo.
Em última análise, eles decidem
Ninguém pode argumentar contra isso. Apresentei cinco argumentos para convencer as pessoas da importância de eliminar o débito técnico, mas agora acho que há mais um conselho que precisa ser dado antes de você trabalhar com um gerente.
Refatore conforme você avança
A refatoração não deve ser vista como uma fase separada de trabalho na funcionalidade. Afinal, você ainda não pode prever com antecedência quais recursos serão implementados no futuro. Isso significa que você precisa ajustar a base de código para novas realidades à medida que se tornam disponíveis. Isso também faz parte do trabalho necessário para criar esse valor material - qualquer desenvolvedor profissional irá confirmar isso.
A regra funciona mesmo para bancos de dados com código legado. Bem, ok, você definitivamente não a trará em uma forma divina amanhã. E tentar refatorar em grande escala no meio também é um assunto morto. Mas com essa abordagem, pelo menos a situação não vai piorar. E ao trabalhar com o código lrgacy, você não deve focar em "bom", mas em "melhor".
Você está corrigindo um bug? Passe uma hora extra escrevendo um teste automatizado. Você está se preparando para lançar um novo recurso? Tire um dia extra para limpar o código. Tente fazer a mudança sem dor dia após dia. Depois de alguns meses, você perceberá que esse hábito teve um grande impacto em sua produtividade. Você sabe por quê? Porque a refatoração ajuda a reduzir a volatilidade dos custos marginais por unidade de funcionalidade do software.