Como justificar o tempo de refatoração de código?

Tenha um projeto muito grande com mais de 70k LOC.

O projeto definitivamente precisa de alguma refatoração de código no Core Framework e em outras partes também. Não havia tempo definido no início do projeto para refatoração. No entanto, com o tempo e mais de 40 desenvolvedores se uniram e deixaram o projeto. Da minha perspectiva é indispensável.

Quais seriam seus pontos-chave para discutir e defender um princípio adequado de desenvolvimento de software?

Ao trabalhar em aplicativos herdados ou em campo aberto, é tentador fazer uma "limpeza de primavera" na esperança de refatorar tudo de volta à forma. Isso não é de forma alguma justificável o uso de recursos. Afinal, como é possível interromper o desenvolvimento de um software em funcionamento (apenas o código em funcionamento pode ser refatorado)? Você pode garantir que o tempo gasto na Grande Fase de Refatoração pagará mais tarde e não cause degeneração no projeto?

Como você come um elefante? Uma mordida de cada vez. Sempre que você precisar implementar um novo recurso ou corrigir um erro, verá se essa parte precisa ser aprimorada. Como a regra dos escoteiros diz: "Sempre deixe o acampamento mais limpo do que você o encontrou". A refatoração não deve ser uma fase separada, pois faz parte do desenvolvimento diário.

Quando você introduz essa cultura de qualidade na equipe de desenvolvimento, a qualidade melhora. Depois disso, não há nada que justifique a gerência.

Em geral, a refatoração deve ser feita para permitir outra alteração que você precisa fazer no código ou como uma etapa de limpeza natural após uma alteração no código. Nesse caso, não há nada para justificar. A refatoração é simplesmente parte do processo de realização do trabalho no projeto. O tempo é cobrado pela tarefa em que você estava trabalhando quando fez a refatoração.

Se não é feito em pequenos incrementos, não é realmente uma refatoração, não é?

Todas as boas respostas aqui - mas posso adicionar uma dimensão comercial a isso. Deixe-me perguntar por que / e daí? (pense no seu chefe de cabelos pontudos (PHB) :)

PHB: por quê?
Você: Tornará as coisas mais fáceis de corrigir
PHB: E daí?
Você: Aumentará o rendimento - obteremos novas versões mais rapidamente?
PHB: E daí?
Você: Err ... Clientes mais felizes?
PHB: WTF?
Você: quero dizer maiores recomendações, maior satisfação, 
     mais lucro mais cedo devido à baixa rotatividade
PHB: Ah! Parece bom. Mas apenas "soa" legal, posso ver?
Você: WTF?
PHB: Mostre-me o dinheiro! (ou seja, números, por favor)
Você: Oh! Brb ... (vá e coloque alguns números em uma planilha simples para fazer o seu caso)

Basicamente, você deve apresentar um caso de negócios - execute alguns números para esclarecer seu processo de pensamento e faça com que os números reflitam o 'benefício' objetivamente. Você também saberá quanto tempo levará, custos aproximados etc. Deve fazer sentido. Se vale a pena, você receberá o sinal verde e talvez liderará a iniciativa também :)

Se você pensa em como posso medir tudo, tente este livro.

A refatoração, como qualquer outra atividade, deve ter uma meta clara definida para ela. Quando esse objetivo estiver claro, você deve considerar o status atual do projeto e o estágio do ciclo de vida. Para um projeto de desenvolvimento com 80% de conclusão e 30% de atraso, você deve justificar o esforço de refatoração com base na meta definida anteriormente. Neste exemplo, se as partes do código foram testadas em unidade e estão funcionando bem em um ambiente de desenvolvimento, é difícil justificar a refatoração.

O fato de restarem 40 desenvolvedores pode não ser tão dramático quanto parece. Eu esperava que esses desenvolvedores entregassem código de trabalho que foi revisado e testado. Portanto, a menos que haja problemas conhecidos nesse código, eu o deixaria como está. A idéia é que, em um projeto grande como o seu, eu esperaria que houvesse padrões e procedimentos e que o código não fosse uma bagunça completa.

Lembre-se de que a refatoração fará com que muitos, se não todos, os testes que foram feitos sejam repetidos. Além disso, como a refatoração desse tamanho não pode ser feita por um ou dois membros seniores, a refatoração pode apresentar problemas que não existiam. Este é um risco que não deve ser negligenciado.

Dito isto, não é incomum adicionar tarefas a um projeto quando o imprevisto acontece. Portanto, se os desenvolvedores desaparecerem por algum motivo, isso seria considerado um evento de natureza especial e quaisquer ações para remediar a situação devem ser tomadas. Seria tratado como um incêndio ou um terremoto, etc.

Em resumo, eu não refatoraria código de trabalho grande em um projeto grande por nenhuma razão técnica sólida, especialmente porque todos sabemos que a maioria dos projetos geralmente está em status tardio.

Imagine que você está na frente de uma parede longa e enorme. Você precisa ir para o outro lado.

Ou você refatora a parede para construir uma porta, ou você a contorna.

Estime o tempo para ambas as soluções e você obtém sua justificativa para refatoração.

Não se esqueça de multiplicar o tempo na segunda solução pelo número de pessoas que precisam ir para o outro lado do muro.

Enquanto eu lia em uma das outras respostas, coma este elefante uma mordida de cada vez. Estou envolvido na auditoria de um grande projeto internacional, onde os membros da equipe estão geograficamente dispersos. Após criar as duas primeiras versões do software, a equipe concordou que suas abordagens, estilo de codificação e construção de soluções são inconsistentes. Eles concordaram em escrever novas partes do aplicativo seguindo as novas regras e convenções e quando (e somente então) precisam alterar parte do código antigo, primeiro refatam-no para atender à nova convenção. Tudo está funcionando muito bem. O processo de refatoração está quase no seu quinto mês, parte do código é refatorada, outras ainda não. Novos recursos são trazidos no tempo, os clientes estão felizes, os desenvolvedores estão felizes, a equipe de controle de qualidade também está feliz. Uma situação ganha-ganha :)

O principal ponto de refatoração é facilitar as coisas no futuro. Você não pode mostrar lucros da refatoração, a menos que compare vários projetos de longo prazo, poucos concluídos e poucos sem refatoração constante. É geralmente aceito entre os desenvolvedores que a refatoração diminui o custo de manutenção e implementação de alterações, mas é difícil provar isso do ponto de vista comercial. O principal motivo para implementar a refatoração é reduzir a dívida técnica .

Além disso, a refatoração deve ser um processo contínuo e o tempo gasto na refatoração deve ser incluído na própria tarefa de desenvolvimento. Ter uma "tarefa de refatoração" especial não é uma boa ideia.