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

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

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

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

Se você não o fizer, o passo 1 é definir de forma positiva e inequívoca o código de problema mais dispendioso, complexo, cheio de erros e infestado de bugs.

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

Depois, corrija alguma coisa nessa lista de problemas alto custo .

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

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

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

Iterar.

Siga a regra do escoteiro: deixe o acampamento (código) um pouco melhor do que você encontrou. Eu nunca ouvi falar de alguém sendo escrito para fazer pequenas melhorias de código "enquanto eles estavam lá".

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

Eu diria que, se essas práticas de engenharia se tornarem a cultura da sua empresa, talvez você precise lutar em um nível mais alto. Você não está realmente lutando por refatoração, você está lutando por excelência em engenharia, e esse é o tipo de mudança que só ocorre na administração quando dá um tapa na cara deles. Nesse cenário, eles provavelmente procurarão fora do czar das melhores práticas, e todas as suas grandes ideias serão incluídas de qualquer maneira.

Considere aderir a uma empresa diferente, levando as práticas de engenharia mais a sério.

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

Eu ia além disso: na minha opinião, uma péssima base de código quase nunca é diretamente culpa da gerência. A gerência não escreveu esse código, o que os desenvolvedores fizeram (há algumas exceções na minha empresa, onde alguns de nossos gerentes atuais realmente 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.

Eu tento trazer essa percepção e mudança de atitude para os "meus" desenvolvedores também. Sempre que me perguntam "quando é que vamos ter tempo para refatorar?", Eu me surpreendo e respondo "você já deveria estar refatorando o tempo todo!". A única maneira que eu acredito que você pode manter uma base de código saudável é três vezes:

1. adicione apenas códigos saudáveis.
2. Sempre corrija códigos não tão saudáveis assim que você os vir.
3. Se, por motivos de prazo, você não puder fazer 1 ou 2, sempre terá uma lista de problemas "corrigir imediatamente após o prazo" e não aceitará desculpas para não trabalhar com essa lista após o prazo.

Invariavelmente, a próxima observação dos desenvolvedores é "mas como temos 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 saudável, vai encontrar tempo de resposta cada vez maior, agendas ficando mais imprevisíveis, erros ficando cada vez mais desagradáveis e valor ficando cada vez menor.

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

Finalmente, uma história de aviso. Se pressionado, negarei que isso tenha acontecido. Em uma empresa em que trabalhei, havia uma aplicação de longa data com uma grande base de código herdada com mais de 10 anos atrás. Muitos desenvolvedores, inclusive eu, acreditavam que essa base de código legada 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 acreditamos que tudo seria melhor.
Trabalhamos longa e duramente implementando quase tudo de uma maneira nova e moderna, usando novas bibliotecas, novos recursos de linguagem. Perto do fim, fizemos um enorme esforço para reunir tudo para permitir uma nova versão da aplicação de longa data com a nova e melhorada base de código. Como esperado, a nova versão teve alguns problemas iniciais, por causa das novas bibliotecas com as quais nós ainda não estávamos tão familiarizados, e algumas interações em nosso código que não havíamos previsto. No entanto, finalmente conseguimos fazer com que o lançamento fosse o mesmo padrão dos nossos lançamentos anteriores e sair pela porta. Nós demos um suspiro de alívio pelo nosso "sucesso". Em seguida, um subgrupo de desenvolvedores voltou ao gerenciamento, pedindo um novo projeto de refatoração, porque nosso novo código não era exatamente o que esperavam que fosse, e eles viram algumas oportunidades de reescrever completamente algumas coisas ...

Moral da história: muitas vezes as coisas não estão tão quebradas quanto parecem, e "começar de novo" geralmente significa que você vai trocar um conjunto conhecido de problemas por um conjunto de problemas desconhecido pelo menos tão peludo. Refatore 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 desta vez.

Encontre outra empresa, honestamente. Essas melhorias no processo de desenvolvimento exigem enormes saltos culturais que levará um tempo significativo antes que todos fiquem na mesma página e até então 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 de apoio de membros da equipe que pensam da mesma forma, divulgue sua exaustão aos superiores que se importam com o seu bem-estar, contorne e distancie qualquer um que possa se opor a suas crenças e tente empurrar algumas horas obrigatórias de refatoração para o planejamento de novas 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 resgate antes de se transformar em um programador oco.

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 de maneira intuitiva pelos desenvolvedores como um fator para um código melhor, menos bugs, etc.
• colaborativo e democrático
• não é muito demorado se você usar o timebox corretamente
• um bom lugar para refatorar se você não tiver tempo para fazer isso durante o desenvolvimento "normal"
• um cavalo de Tróia 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, somente ao confirmar partes de código grandes / complexas no início.

É claro que se você sentir que precisa de apoio oficial antes de apresentar revisões de código, talvez seja necessário convencer seu chefe primeiro de que a base de código provavelmente entrará em colapso se as coisas ficarem como estão.

Aqui está o que eu faço em tais situações (nos 15 anos de minha carreira como desenvolvedor, eu já vi esse código quase todos os dias)

1. Liderar pelo exemplo - refazer o código que toco. Eu implacavelmente excluo código antigo comentado e grandes parágrafos de comentários.
2. Peça para refatorar toda vez que me pedem para revisar uma mudança de código, sem a qual eu não aprovo a revisão do código.
3. Lentamente as pessoas vêem a mudança, quando o código se torna mais enxuto, mais legível e, portanto, com menos bugs. Leva tempo, mas lentamente toda a equipe aprecia e adota a prática.

O gerenciamento nunca separa tempo para refazer o código (eles nunca têm recursos suficientes!), portanto, fazer isso de forma lenta e constante é uma abordagem correta.

A gerência faz algumas pesquisas sobre "dívida técnica". Também os encaminhe para a "Teoria das Janelas Partidas", 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 confusão agrava a bagunça de uma forma exponencial, não linear.

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

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

Da minha experiência, acho que você pode estar encontrando um problema que eu chamo, "todo mundo é um gerente de software." Gerentes de produto, gerentes de projeto e, às vezes, engenheiros e testadores de sistemas podem ser notórios por tentar microgerenciar desenvolvedores que provavelmente já possuem um gerente de software experiente. Você pode até ter alguns membros em sua equipe que acreditam que seu papel é gerenciar.

Se você for o gerente de software, faça as atribuições para a refatoração desejada 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 de código a ser refatorado que podem ser livremente refatoradas versus precisar de aprovação. Se um membro da sua equipe quiser refatorar maciçamente quatro grandes classes de código antigo complexo que ele não escreveu e que não fazem parte do seu recurso, seu desvio de duas semanas é problema seu, então você precisa de uma chance para dizer não.

Você pode se esgueirar, mas acho que é melhor apenas construir 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, conforme julgado historicamente e por a falta de experiência ou clareza associada à tarefa. Se você tem sido muito aberto sobre o trabalho de sua equipe (ou tem membros em sua equipe que são), pode ser sábio restringir canais de comunicação para que eles passem por você e discutam recursos e resultados, não métodos.

As opções iniciais do projeto criam um ciclo vicioso para a refatoração

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

link

"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 negociador entre seus diversos grupos e um empacotador de soluções de projetos com condições de vitória para todas as partes Além disso, o gestor também é um definidor de metas, um monitor de progresso em direção a metas e um ativista na busca de conflitos de projetos diários de perder ou perder, confrontando-os e transformando-os em situações ganha-ganha. "

Rápido e sujo geralmente é apenas sujo

Boehm continua a apontar 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 um" ganho "de curto prazo e baixo custo para o desenvolvedor de software e o cliente, mas será um" desperdício "para o usuário e o mantenedor." Observe que, no modelo de 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 na 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 contar o gerente de produto como um substituto do cliente, e o grupo de pessoas recompensadas por entregar algo rápido e sujo pode certamente ser expandido, então há um grande público para fazer as coisas da maneira errada .

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

Por favor, não recue da sua função como gerente de software. Você deve ter autoridade e discrição para usar o tempo da sua equipe em melhorias de processo e produto. Nesse papel, talvez seja 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, isso é um jogo perdido. Negocie com o gerenciamento de engenharia. Isso mostra que você tem visão. Construir uma equipe de software profissional é uma extensão do seu papel e é muito mais provável que seja vista como uma estratégia ganha-ganha.

Você sempre pode simplesmente esperar. Eventualmente, a equipe perderá prazos suficientes, e produzirá software suficiente para bugs, que a gerência levantará as mãos e dirá que por Deus algo teve melhor mudança!

Ok, essa é uma proposta arriscada. Mas na verdade é o que aconteceu em nossa loja há vários anos (parte da dificuldade estava em se comunicar com os prazos de gerenciamento sobre , mas isso é outra história), e é muito da razão pela qual agora temos dezenas de milhares de testes automatizados, propriedade de código compartilhado, a liberdade de refatorar, a disposição de excluir códigos mortos e os lançamentos de maior qualidade que já tivemos.

Talvez o mais surpreendente é que ninguém perdeu o emprego no processo - algo que eu credito ao nosso chefe que vem atrás de nós e a um consultor que defendeu a refatoração e a integração contínua em nosso nome. Parece sempre mais convincente quando alguém de fora diz isso.

Acho que a resposta a como encontrar o tempo depende, por que você quer refatorar o código.

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

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

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

Eu ri um pouco do jeito que você descreveu as coisas, já que isso soa bem parecido com o código base em que trabalho, então acho que nossas situações são bem parecidas. Felizmente, na minha situação, tenho um gerente com 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 web moderna, em vez de apenas refatorar toda a base de código. Desta forma, os pontos problemáticos da aplicação principal podem ser reescritos como módulos separados e, em seguida, ser integrados no aplicativo principal (mas ainda assim ser essencialmente independentes). Essa pode ser uma abordagem que você queira abordar, já que não seria necessário refatorar toda a base de código (presumivelmente grande?) Com a qual você está trabalhando.

Claro, posso estar um pouco fora do que você está dizendo, pois talvez sua base de código não seja tão ruim quanto a que eu trabalho, nesse caso eu diria por que não fazer pequenas otimizações à medida que você avança? Os desenvolvedores da minha equipe não têm problemas em remover comentários estúpidos ou desatualizados e coisas dessa natureza, e não acho que isso seja algo que deva exigir informações do gerenciamento, já que normalmente os desenvolvedores recebem algum poder para otimizar as coisas conforme necessário.

Se a base de código é realmente frágil, você precisa ser cuidadoso e pode ser por isso que eles podem não querer buscar refatoração importante, pois isso pode acabar se transformando em um projeto longo de meses e provavelmente exigiria ramificação de um projeto e Dev está nesse projeto e se afastando de outras tarefas de desenvolvimento, como correções imediatas de bugs que podem fazer com que eles percam clientes, etc.

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

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

Quando um programador comete uma alteração, Jenkins executa os testes das unidades, executa a ferramenta de análise de código estática e gera um relatório da web que todos podem ver, com status de cor semelhante a um sinal de tráfego.

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 estão lá para ter suas costas ... as pessoas se sentem encorajadas a refatorar.

O código ficou muito lento ao longo de muitas pequenas mudanças. Também será preciso consertar isso.

Você pode fazer isso em primeiro lugar: aumente todas as estimativas em 10% para permitir o aprimoramento de código e a manutenção a longo prazo. Se alguém reclamar, pergunte-lhe se é melhor verificar o óleo no motor de um carro toda semana ou esperar até que o motor seja completamente bloqueado.

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

Introduza regras básicas para usar à medida que você avança:

Sempre que um novo código é introduzido em uma classe, testes automatizados precisam ser escritos para provar que a classe funciona (não apenas o novo código).

Sempre que um bug é corrigido, testes automatizados 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.

A maneira de obter os recursos (tempo) que você precisa é focar no alinhamento de capacidade e desejo. Seu chefe é guiado por alvos (geralmente lucros ou prazos de entrega de novos recursos), e ele vê a refatoração como engenheiros perdendo tempo e comendo esses alvos. Você precisa encontrar uma maneira de convencê-lo de que os alvos serão atingidos e excedidos se você gastar tempo refatorando.

O primeiro passo é descobrir qual dor seu chefe está sentindo. Identifique quais são seus maiores problemas. Em seguida, descubra como o que você deseja fazer se alinha com a correção de seus problemas e apresente um strong argumento comercial para isso. Use sistemas de controle de defeitos e de planejamento de projetos (tempo excedido) para fornecer evidências de onde estão os problemas. Você precisa de fatos, não sentimentos. Sem métricas (contagens de bugs / módulo, custo para consertá-las), a refatoração é apenas um programador que tem uma folga por conta de alguém. Seu chefe só lhe dará os recursos necessários se você puder demonstrar um strong argumento comercial para isso.

Crap code é mais caro do que não consertar. Sem testes de regressão automatizados, o custo do teste de código refatorado é extremamente alto.

Na maioria das vezes eu vi código ruim em necessidade real de refatoração, houve um grande número de recursos não documentados e complexidade nos requisitos que não podem ser compreendidos 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 abstive de ir em frente e fazer isso atrás de vocês, chefes de volta (se não foi quebrado, e você quebrou, como isso parece) - corrija o código que precisa mudar de qualquer maneira, mas se não está quebrado , não conserte.

Estranhamente, ninguém menciona isso:

Para tornar as coisas uma prioridade, torne-as fáceis: obtenha uma boa ferramenta de refatoração.

Existem excelentes ferramentas de refatoração disponíveis (pelo menos para .NET afaik). Ah, e não se esqueça de escrever testes de unidade de antemão (como os outros já apontaram).

Boa sorte!