Como você gerencia a refatoração com uma grande base de código e muitos desenvolvedores?

Gostaria de evitar uma situação em que dois desenvolvedores refatore o mesmo código simultaneamente sem falar primeiro sobre ele, provavelmente usando algum tipo de ferramenta, talvez um plug-in do Eclipse. Você pode ajudar?

Temos 4,5 milhões de linhas de código e mais de 20 equipes de desenvolvedores em quatro continentes.

Idealmente, eu gostaria que o segundo dos desenvolvedores mencionado anteriormente notasse que alguém está trabalhando no mesmo trecho de código e conversasse com o primeiro antes de modificar qualquer coisa.

Você conhece uma solução?

Muitos sistemas de controle de origem de segunda geração funcionam usando um "checkout" conectado que informa o servidor que você pretende modificar um arquivo. Exemplos incluem TFS, SourceGear Vault e muitos outros. Dessa forma, você pode cumprir tecnicamente seus requisitos. Como apontou Adam Butler, esses tipos de ferramentas vêm com seus próprios problemas (sem entrar em um longo debate - suporte limitado ao trabalho offline e geralmente fluxo de trabalho de desenvolvimento contraproducente).

Definitivamente, eu sugeriria algum tipo de abordagem hierárquica para alocar o trabalho de refatoração. Os desenvolvedores podem ser agrupados logicamente em sub-equipes, cada uma responsável por áreas específicas do código. Dependendo de como você deseja estruturar as equipes, cada uma delas pode ter um papel de "líder", responsável pelo design de alto nível da área da equipe. Essa estrutura deve ser bem conhecida pelos desenvolvedores e deve simplificar a comunicação para refatoração. Estou certo de que essa abordagem parece muito formal e atrasada para alguns, mas acho que é preferível que mais de 20 desenvolvedores usem uma abordagem "livre para todos" para refatorar um sistema grande. Algumas refatorações ocorrerão em alto nível (por exemplo, como o módulo X se comunicará com o módulo Y), nesse caso, você precisará de pessoas que possam fazer chamadas no nível apropriado. Nem todo desenvolvedor da equipe deve tomar decisões arquitetônicas; portanto, uma hierarquia é quase imposta em qualquer caso, mesmo que alguém escolha ignorá-la.

Então, basicamente, existem ferramentas para atender aos requisitos básicos que você apresenta, mas nenhuma ferramenta substitui as comunicações adequadas e tem um pequeno número de pessoas dirigindo a arquitetura geral do seu projeto.

1. Verifique se os desenvolvedores recebem módulos específicos.
2. Tenha um sistema de rastreamento de tarefas / erros que rastreie todas as alterações de refatoração. Atribua cada problema a apenas um desenvolvedor
3. Alguns sistemas de controle de versão têm a capacidade de bloquear um arquivo para que apenas um desenvolvedor possa ter direitos de atualização sobre o arquivo. Eu nunca usei esse recurso, mas se os desenvolvedores estão constantemente se esquecendo, isso é algo que você pode querer considerar.
4. Faça testes de unidade para que, mesmo que os desenvolvedores trabalhem no mesmo arquivo, você saiba que as alterações deles não quebram o aplicativo de forma alguma.
5. Todas as opções acima ajudariam se sua refatoração estiver contida nos módulos. No entanto, se alguém refatorar uma preocupação transversal, como log ou segurança, isso afetará muitos arquivos por definição. Eles precisam ser manuseados com cuidado, especialmente se você ainda não se aproveitou das abordagens de AOP.

Existem / existem sistemas de controle de versão que fazem com que os desenvolvedores façam o checkout do código antes que eles possam editar, mas eles têm um conjunto de problemas próprios. A melhor prática é fazer com que os desenvolvedores se comprometam e atualizem com frequência. Um desenvolvedor pode marcar uma classe como depreciada e confirmar, se o outro desenvolvedor atualizar antes de iniciar o refator, verá a intenção.

A tecnologia não pode resolver problemas sociais. Você precisa que seus desenvolvedores conversem entre si e coordenem o trabalho deles. Com 20 equipes, alguma estrutura e regras serão essenciais. Você deseja apoiá-los com soluções tecnológicas, mas as pessoas vêm primeiro.

Se você sair notice that someone else is working on the same piece of code and talk to the first one before modifying anything, conforme o que disse, precisará de um sistema de controle de versão (CVS / SVN / GIT). Não tenho certeza, mas se você quiser incluir isso também, precisará de algumas coisas avançadas (algum tipo de mecanismo de acionamento / talvez algo personalizado).

Os desenvolvedores que bloqueiam arquivos no controle de origem devem resolver seu problema facilmente, mas acho que você pode ter problemas maiores.

4,5 milhões de LOC's são uma grande caixa de areia para se jogar, portanto, em uma solução bem arquitetada e projetada, você raramente deve se deparar com uma situação em que várias equipes de desenvolvedores estão pisando nos dedos uns dos outros. O fato de isso acontecer mais do que coincidentemente está revelando algumas falhas sérias de design em potencial que devem ser analisadas.

Algumas coisas:

1. Módulos separados para trabalhar
2. Falando sobre mudanças antes que elas sejam feitas [com todos os desenvolvedores]
3. Teste de unidade [para verificação e prevenção por quebra de itens relacionados]
4. Como os outros mencionaram um VCS