Como posso tornar a refatoração uma prioridade para minha equipe?

A base de código com a qual trabalho diariamente não possui testes automatizados, nomes inconsistentes e muitos comentários como "Por que isso está aqui?", "Não tenho certeza se isso é necessário" ou "Este método não está nomeado corretamente" e o código está cheio de "Changelogs", apesar de usarmos o controle de origem. Basta dizer que nossa base de código pode usar refatoração.

Sempre temos tarefas para corrigir bugs ou adicionar novos recursos; portanto, não é tempo de refatorar o código para ser melhor e mais modular, e isso não parece ser uma alta prioridade.

Como posso demonstrar o valor da refatoração de forma que ela seja adicionada às nossas listas de tarefas? Vale a pena apenas refatorar o caminho, pedindo mais perdão do que permissão?

"É melhor pedir perdão do que permissão" é verdade.

Por que se preocupar com isso? Apenas refatorar as partes mais horríveis.

Você já sabe quais são os erros mais caros , certo?

Caso contrário, a etapa 1 é definir positiva e inequivocamente o código do problema mais caro, complexo, repleto de erros e infestado de erros.

Identifique o número de tickets de problemas, horas de depuração e outros custos muito específicos e muito mensuráveis .

Em seguida, corrija algo nessa lista de problemas de alto custo .

Quando você precisa pedir perdão, pode apontar para reduções de custo.

Caso você não saiba, a refatoração exige testes de unidade para provar que os comportamentos de antes e depois são iguais. Idealmente, esse deve ser um teste automatizado e codificado, por exemplo, um teste de unidade.

Isso significa escolher uma coisa. Escreva um teste de unidade. Conserte isso. Você fez duas melhorias. (1) escreveu um teste e (2) corrigiu o código.

Iterar.

Siga a regra dos escoteiros: deixe o acampamento (código) um pouco melhor do que você o encontrou. Eu nunca ouvi falar de alguém sendo redigido por fazer pequenos aprimoramentos de código "enquanto eles estavam lá".

Vou adotar um ponto de vista talvez excessivamente cínico.

A refatoração é uma pílula tão difícil de engolir. Você assume a responsabilidade e a culpa, e os frutos do seu trabalho muitas vezes vão para alguém que se baseia em sua base de código limpa.

Eu diria que, se essas práticas de engenharia se tornaram a cultura da sua empresa, talvez você precise lutar em um nível superior. Você não está realmente lutando pela refatoração, está lutando pela excelência em engenharia, e esse é o tipo de mudança que só ocorre na gerência quando ela bate na cara dela. Nesse cenário, eles provavelmente procurarão um czar de práticas recomendadas, e todas as suas grandes idéias serão incluídas de qualquer maneira.

Considere ingressar em uma empresa diferente, onde eles levam as práticas de engenharia mais a sério.

Percebo que muitos dos pôsteres aqui parecem convencidos de que o problema na administração - enquanto a pergunta não menciona isso.

Eu iria além disso: na minha opinião, uma péssima base de código quase nunca é diretamente culpa do gerenciamento. Os gerentes não escreveram esse código, os desenvolvedores fizeram (existem algumas exceções na minha empresa em que alguns de nossos gerentes atuais escreveram a base de código inicial). Portanto, o problema da cultura reside nos desenvolvedores - se eles querem que a cultura mude, eles mesmos terão que mudar.

Tento trazer essa percepção e mudança de atitude aos "meus" desenvolvedores também. Sempre que me perguntam "quando teremos tempo para refatorar?", Fico surpreso e respondo "você já deveria estar refatorando o tempo todo!". A única maneira que acredito que você pode manter uma base de código íntegra é três vezes:

1. Adicione sempre apenas um código íntegro.
2. Sempre corrija o código não tão íntegro assim que o vir.
3. Se, por motivos de prazo, você não puder executar 1 ou 2, sempre tenha uma lista de problemas "corrigir imediatamente após o prazo" e não aceite desculpas por não trabalhar nessa lista após o prazo.

Invariavelmente, a próxima observação dos desenvolvedores é "mas como conseguimos tempo para fazer isso - não temos tempo agora?". A única resposta correta (novamente IMHO) é "você não tem tempo para NÃO fazer isso". Se você não mantiver a base de código em funcionamento, o tempo de resposta será cada vez maior, os agendamentos cada vez mais imprevisíveis, os erros cada vez mais desagradáveis ​​e o valor cada vez menor.

A maior mudança de atitude que você precisa realizar na equipe de desenvolvimento é que "qualidade" não é algo que você faz em um momento específico ("quando temos tempo para refatorar") - é algo que você deve fazer o tempo todo.

Finalmente, uma história de aviso. Se pressionado, negarei que isso tenha acontecido. Em uma empresa em que trabalhei, havia um aplicativo de longa data com uma grande base de código herdada originada há mais de 10 anos. Muitos desenvolvedores, inclusive eu, acreditavam que essa base de código herdada era ruim ou pelo menos desatualizada, e não de última geração. Por isso, fizemos lobby para um grande projeto de refatoração com sucesso e iniciamos o projeto de reescrita, após o qual acreditávamos que tudo seria melhor.
Trabalhamos muito e implementamos quase tudo de uma maneira nova e moderna, usando novas bibliotecas, novos recursos de linguagem. Perto do fim, realizamos um grande esforço para reunir tudo para permitir uma nova versão do aplicativo de longa data com a nova e aprimorada base de código.
Como esperado, o novo lançamento teve alguns problemas iniciais, por causa das novas bibliotecas com as quais ainda não estávamos tão familiarizados e de algumas interações em nosso código que não tínhamos previsto. No entanto, finalmente conseguimos obter o lançamento com o mesmo padrão dos lançamentos anteriores e sair do mercado. Soltamos um suspiro de alívio pelo nosso "sucesso". Então, um subgrupo de desenvolvedores voltou ao gerenciamento, solicitando um novo projeto de refatoração, porque nosso novo código não era exatamente a bala de prata que eles esperavam, e eles viram algumas oportunidades para reescrever completamente algumas coisas ...

Moral da história: muitas vezes as coisas não são tão ruins quanto parecem, e "recomeçar" geralmente significa que você trocará um conjunto conhecido de problemas com um conjunto desconhecido de pelo menos cabeludo. Refatorar uma parte de cada vez!

Alguém me disse uma vez que, quando vou a uma entrevista, não devo esquecer que também estou entrevistando a empresa. É um lugar que eu quero trabalhar? Eles fazem revisões de código? Eles têm testes de integração automatizados? Testes unitários? O que eles acham da programação em pares? Pessoalmente, eu encontraria outro emprego e não se esqueça de fazer algumas perguntas também neste momento.

Encontre outra empresa, honestamente. Tais melhorias no processo de desenvolvimento exigem grandes saltos culturais que levarão um tempo significativo até que todos cheguem à mesma página e, a essa altura, você não se importará tanto.

Se você sente que ainda tem alguma briga em você e ainda não caiu, faça um empurrão final. Tente obter o máximo apoio de membros da equipe que pensam da mesma forma, divulgue sua exaustão a superiores que se preocupam com seu bem-estar, evite e distancie qualquer pessoa que possa se opor às suas crenças e tente levar algumas horas obrigatórias de refatoração para planejar novos projetos / recursos.

Se você é apaixonado pelo que faz e se preocupa com a sua empresa, isso seria um esforço louvável do seu lado. Se não for apreciado, respeite-se e saia antes de se tornar um programador vazio.

Se eu tivesse que introduzir uma prática para melhorar as coisas nesse tipo de contexto, seriam revisões de código. Revisões de código são

• geralmente aceito intuitivamente pelos desenvolvedores como um fator para um melhor código, menos erros, etc.
• colaborativo e democrático
• não consome muito tempo se você os timebox corretamente
• um bom lugar para refatorar se você não tiver tempo para fazê-lo durante o desenvolvimento "normal"
• um cavalo de Troia bastante eficaz para introduzir gradualmente todos os tipos de práticas recomendadas em termos de design de código, teste de unidade ...

Você não precisa fazer revisões de código sistematicamente, apenas ao confirmar partes de código grandes / complexas primeiro.

Obviamente, se você sente que precisa de aprovação oficial antes de introduzir revisões de código, convém primeiro convencer seu chefe de que a base de código provavelmente entrará em colapso se as coisas continuarem como estão.

Aqui está o que eu faço nessas situações (nos 15 anos da minha carreira como desenvolvedor, encontrei esse código quase todos os dias)

1. Lidere o exemplo - certifique-se de re-fatorar o código que toquei. Excluo implacavelmente o código antigo comentado e grandes parágrafos de comentários.
2. Peça re-fatoração toda vez que me for solicitado revisar uma alteração de código, sem a qual não aprovo a revisão.
3. Lentamente, as pessoas veem a mudança, quando o código se torna mais enxuto, mais legível e, portanto, menos problemático. Leva tempo, mas lentamente toda a equipe aprecia e adota a prática.

A gerência nunca reserva tempo para refazer o código (eles nunca têm recursos suficientes!), Portanto, fazê-lo lenta e firmemente é uma abordagem correta.

Faça com que a gerência faça alguma pesquisa sobre "dívida técnica". Também os encaminhe à "Teoria da janela quebrada", ambos os efeitos têm impacto direto na eficiência, qualidade e moral.

"Um local de trabalho limpo é um local de trabalho seguro e produtivo", e toda contribuição para uma bagunça compõe a bagunça de maneira exponencial, não linear.

Se a situação não for resolvida, eventualmente você atravessará um ponto sem retorno, onde se torna economicamente inviável, lidando com ela de forma incremental antes que isso aconteça, os benefícios se recuperam, dando a você mais combustível para lidar com o problema à medida que avança.

Parece que seus problemas são mais gerais.
A questão da refatoração é um sintoma e um alívio potencial de parte do problema.

O líder de software e a equipe alocam o tempo da equipe

Pela minha experiência, acho que você pode estar enfrentando um problema que chamo de "todo mundo é gerente de software". Gerentes de produto, gerentes de projeto e, às vezes, engenheiros e testadores de sistemas podem ser notórios por tentarem gerenciar microdesenvolvedores que provavelmente já possuem um gerente de software experiente. Você pode até ter alguns membros de sua equipe que acreditam que o papel deles é gerenciar.

Se você é o gerente de software, faça atribuições para a refatoração que você deseja, ou melhor ainda, peça à sua equipe que proponha a refatoração para sua aprovação. Para não microgerenciar, você pode ter diretrizes sobre idade / autor / tamanho / contexto do código a ser refatorado que pode ser refatorado livremente versus necessitar de aprovação. Se um membro de sua equipe deseja refatorar massivamente quatro grandes classes de códigos antigos complexos que ele não escreveu e que não fazem parte do recurso, o desvio de duas semanas é o seu problema, então você precisa ter a chance de dizer não.

Você pode se esgueirar, mas acho que é melhor criar suas estimativas cuidadosamente com tempo para análise, design, codificação, várias formas de teste (pelo menos unidade e integração), refatoração e risco, como julgado historicamente e pela falta de experiência ou clareza associadas à tarefa. Se você foi muito aberto sobre o funcionamento de sua equipe (ou possui membros de sua equipe), pode ser aconselhável restringir os canais de comunicação para que eles passem por você e discutam recursos e resultados, não métodos.

Escolhas iniciais do projeto criam um ciclo vicioso para refatoração

A manutenção do software é difícil. É duplamente difícil se outras pessoas na organização estão fazendo escolhas às suas custas. Isso está errado, mas não é novo. Foi abordado por Barry Boehm, um dos nossos grandes escritores de software que apresenta um modelo de gerenciamento que ele descreve como Teoria W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Muitas vezes, os desenvolvedores de software são martelados na produção sob a abordagem de gerenciamento Theory-X, que diz que os trabalhadores são basicamente preguiçosos e não terão desempenho a menos que sejam submetidos à submissão. Boehm resume e contrasta seu modelo proposto da seguinte maneira:

"Em vez de caracterizar um gerente como um autocrata (Teoria X), um treinador (Teoria Y) ou um facilitador (Teoria Z), a Teoria W caracteriza o papel principal de um gerente como um negociador entre seus vários eleitores e um empacotador de soluções de projetos Além disso, o gerente também é um determinador de objetivos, um monitor do progresso em direção a objetivos e um ativista na busca de conflitos diários de projeto com perda ou perda, enfrentando-os, e transformá-los em situações em que todos ganham. "

Rápido e sujo é frequentemente apenas sujo

Boehm continua apontando a razão pela qual as coisas são tão infelizes para os desenvolvedores da equipe de manutenção.

"Criar um produto rápido e desleixado pode ser uma" vitória "de baixo custo e de curto prazo para o desenvolvedor e o cliente do software, mas será uma 'perda' para o usuário e o mantenedor." Observe que, no modelo da Boehm, o cliente é mais um administrador de contratos, em vez de um usuário final. Na maioria das empresas, pense no gerente de produto como um substituto do cliente, ou talvez a pessoa que compra o produto para sua lista de recursos.

Minha solução seria não liberar a equipe de desenvolvimento original (ou pelo menos o lead original) até que o código seja refatorado para, pelo menos, atender aos padrões de codificação.

Para o cliente, acho razoável considerar o gerente de produto como um substituto do cliente, e o grupo de pessoas recompensadas por fornecer algo rápido e sujo pode certamente ser expandido, de modo que há um grande número de membros para fazer as coisas da maneira errada.

A refatoração não é negociável

Por favor, não desista de sua função como gerente de software. Você deve ter autoridade e discrição para usar o tempo de sua equipe nas melhorias de processos e produtos. Nessa função, pode ser necessário negociar suas escolhas para tornar sua equipe mais profissional. No entanto, no que diz respeito ao processo, não negocie com marketing, porque, na minha experiência, esse é um jogo perdedor. Negocie com o gerenciamento de engenharia. Isso mostra que você tem visão. A formação de uma equipe profissional de software é uma extensão de seu papel e é muito mais provável que seja vista como ganha-ganha.

Você sempre pode esperar. Eventualmente, a equipe perderá prazos suficientes e produzirá software com erros suficientes, para que a gerência levante as mãos e diga que, por Deus, algo teve uma mudança melhor!

Ok, isso é uma proposta arriscada. Mas, na verdade, foi o que aconteceu em nossa loja há vários anos (parte da dificuldade foi se comunicar com a gerência sobre prazos, mas isso é outra história), e é o motivo pelo qual agora temos dezenas de milhares de testes automatizados, propriedade de código compartilhado, a liberdade de refatorar, a vontade de excluir código morto e os lançamentos da mais alta qualidade que já tivemos.

Talvez o mais surpreendente seja que ninguém tenha perdido o emprego no processo - algo que eu atribuo ao nosso chefe que vem nos atacar e a um consultor que defendeu a refatoração e a integração contínua em nosso nome. Sempre soa mais convincente quando alguém de fora está dizendo isso.

Acho que a resposta para encontrar tempo depende de por que você deseja refatorar o código.

Se funcionar, não há necessidade de refatorar especial e você poderá fazê-lo quando tocar nessa parte do código. Portanto, você não precisa de um tempo especial para isso.

Se isso atrasa o desenvolvimento da equipe, você precisa conversar com o líder da equipe sobre isso e criar uma tarefa especial para refatoração, e assim você terá tempo.

O mesmo para velocidade de execução e outros casos, se o refator puder melhorar algo e não apenas "boa aparência de código" ou sua opinião sobre como a aparência do código e fornecer benefícios reais, criar tarefas ou conversar com alguém responsável por isso.

Eu ri um pouco da maneira como você descreveu as coisas, pois soa muito semelhante à base de código em que trabalho, então acho que nossas situações são bem parecidas. Felizmente, na minha situação, tenho um gerente de visão de futuro que decidiu que a melhor maneira de melhorar a base de código é através da modularização usando uma estrutura de desenvolvimento da Web moderna, em vez de apenas refatorar toda a base de código. Dessa forma, os pontos problemáticos do aplicativo principal podem ser reescritos como módulos separados e, em seguida, integrados ao aplicativo principal (mas ainda assim essencialmente independentes). Essa pode ser uma abordagem que você deseja apresentar, pois não exigiria a refatoração de toda a base de código (presumivelmente grande?) Com a qual você está trabalhando.

É claro que posso estar um pouco distante do que você está dizendo, pois talvez sua base de código não seja tão ruim quanto a que trabalho, nesse caso, eu diria por que não fazer pequenas otimizações ao longo do processo? Os desenvolvedores da minha equipe não têm problemas para remover comentários estúpidos ou desatualizados e coisas dessa natureza, e eu não acho que isso exija alguma contribuição da gerência, já que geralmente os desenvolvedores recebem algum poder para otimizar as coisas conforme necessário.

Se a base de código é realmente frágil, é preciso ter cuidado e pode ser por isso que eles podem não querer realizar uma refatoração maior, pois isso pode acabar se transformando em um projeto de meses e provavelmente exigiria ramificação de um projeto e colocação de desenvolvedores nesse processo. projeto e retirando-se de outras tarefas de desenvolvimento, como correções imediatas de erros que podem causar perda de clientes etc.

Todas as coisas consideradas, tanto quanto as outras pessoas dizendo que você deve parar, etc, acho que depende de como a gerência vê as coisas, se elas entendem a situação e percebem por que algumas coisas podem demorar mais do que deveriam, então as coisas podem ficar bem. no que diz respeito ao ambiente de trabalho, mas se eles estão constantemente informando sobre um acúmulo de trabalho, isso pode se tornar prejudicial ao longo do tempo. Tenho a sorte de ter um gerenciamento que basicamente percebe que o aplicativo é uma porcaria, mas ele tem muitos clientes e gera dinheiro, por isso ainda é valioso e vale a pena corrigir bugs, mesmo que a curto prazo .

Seu principal problema é que os códigos não estão recebendo visibilidade suficiente.

Sugiro usar uma ferramenta de integração contínua como Jenkins e uma ferramenta de análise de código estática integrada a ela que mede a complexidade ciclomática, padrões de nomeação, tamanho do código etc.

Quando um programador faz uma alteração, Jenkins executa os testes de unidade, executa a ferramenta de análise de código estático e gera um relatório na web que todos podem ver, com status de cor semelhante a um semáforo.

Quando a qualidade do código é visível para todos (especialmente o líder da equipe e o chefe) e o controle de versão e os testes de unidade existem para ajudar você, as pessoas se sentem incentivadas a refatorar.

O código ficou assim lentamente ao longo de muitas pequenas alterações. Também precisará ser corrigido dessa maneira.

Você pode fazer isso à medida que avança, antes de tudo - aumente todas as estimativas em 10% para permitir aprimoramento do código e manutenção a longo prazo. Se alguém reclamar, pergunte se é melhor verificar o óleo no motor de um carro toda semana ou esperar até que o motor trave completamente.

Faça uma reunião e determine os padrões de codificação consistentes.

Introduzir regras básicas para usar à medida que avança:

Sempre que um novo código é introduzido em uma classe, é necessário escrever testes automatizados para provar que a classe funciona (não apenas o novo código).

Sempre que um bug é corrigido, testes automáticos precisam ser escritos para provar que a classe funciona (não apenas o código fixo).

Sempre que um programador modifica um arquivo, ele precisa corrigir todos os avisos do compilador nesse arquivo e atualizar o código para que ele atenda aos novos padrões de codificação.

Depois de um tempo, o código mais usado estará atualizado e será coberto por testes automatizados. O código mais antigo será atualizado quando for alterado, se nunca for alterado, você nunca precisará se preocupar com isso.

O importante é incorporar esses hábitos nas tarefas de codificação padrão, para que nenhum deles gaste muito tempo longe do trabalho "real", mas todos eles fornecem benefícios reais. Não tente criar um projeto com refatoração de código antigo, pois é uma dor horrível, chata e complicada que parecerá muito tempo desperdiçando para não técnicos!

A maneira de obter os recursos (tempo) necessários é concentrar-se no alinhamento da capacidade e do desejo. Seu chefe é orientado por metas (normalmente lucros ou prazos de entrega para novos recursos) e vê a refatoração como engenheiros perdendo tempo e consumindo essas metas. Você precisa encontrar uma maneira de convencê-lo de que os objetivos serão alcançados e excedidos se você passar algum tempo refatorando.

Então, o primeiro passo é descobrir que dor seu chefe está sentindo. Identifique quais são seus maiores problemas. Depois, elabore como o que você deseja fazer se alinha com a solução dos problemas dele e apresente um forte argumento comercial para isso. Use os sistemas de rastreamento de defeitos e planejamento de projetos (excedentes de tempo) para fornecer evidências de onde estão os problemas. Você precisa de fatos, não sentimentos. Sem métricas (contagem de bugs / módulo, custo para corrigi-las), a refatoração é apenas um programador que está jogando às custas de alguém. Seu chefe apenas fornecerá os recursos necessários se você puder mostrar um forte argumento comercial para fazê-lo.

Código de porcaria é mais frequentemente do que não é muito caro para corrigir. Sem testes de regressão automatizados, o custo do teste de código refatorado é extremamente alto.

Na maioria das vezes eu vi códigos ruins precisando de refatoração, houve um grande número de recursos não documentados e complexidade nos requisitos que não podem ser entendidos desde o início. Não é um empreendimento menor e minha experiência é uma ordem de magnitude mais difícil de estimar o custo de um trabalho de refatoração do que adicionar um novo recurso.

Eu me absteria de seguir em frente e fazê-lo pelas costas de seus chefes (se não estava quebrado e você o quebrou, como isso parece) - conserte o código que precisa ser alterado de qualquer maneira, mas se não estiver quebrado, não Não conserte.

Estranhamente, ninguém menciona isso:

Para tornar as coisas uma prioridade, facilite-as: Obtenha uma boa ferramenta de refatoração.

Existem excelentes ferramentas de refatoração por aí (pelo menos para o .NET afaik). Ah, e não se esqueça de escrever testes de unidade com antecedência (como outros já apontaram).

Boa sorte!