Para quais edições é correto editar o código escrito por um colega de trabalho? Para quais problemas está errado?
Quando a edição melhora a funcionalidade do programa ou torna o próprio código mais legível / sustentável.
Quando a edição prejudica a funcionalidade do programa ou não serve para nada além de fornecer ao editor trabalho intenso.
Quem é o proprietário do código? A empresa ou o desenvolvedor?
Se o proprietário for (como sempre) a empresa, não deverá haver diferença no código de edição escrito por você ou por um colega de trabalho (a menos que haja uma política de manutenção de código específica).
A edição do código de uma outra pessoa deve estar acontecendo à medida que o código evolui e deve ser incentivada como uma prática para que você tenha a propriedade de código coletivo.
O código deve pertencer a toda a equipe; ter um código que é apenas editado por (e, portanto, apenas realmente compreendido por) um desenvolvedor é uma má ideia. Se você não está no código fazendo alterações, provavelmente não o entende. Esperar até que o outro desenvolvedor deixe a empresa ou fique doente é o momento errado para aprender o código.
Ter testes de unidade detalhados no local e usar o controle de origem deve significar que essa prática é de baixo risco.
Encorajar toda a equipe a seguir a "regra do escoteiro" do Tio Bob e sempre tentar verificar o código um pouco mais limpo do que você conferiu é uma boa maneira de garantir que o código permaneça limpo com o tempo e não devolve em uma bagunça ilegível e inamovível.
A única desvantagem disso é se essa prática se transformar em guerras de edição, onde os desenvolvedores estão constantemente revertendo as alterações uns dos outros. Este é provavelmente um sinal de que você não decidiu sobre um padrão de codificação para o que está causando a guerra de edição, então essa seria uma boa oportunidade para criar um.
Eu diria que é certo quando o que você está trabalhando requer a mudança. Está certo quando você foi designado para consertar um bug e o bug está nesse código.
Se o código não tem nada a ver com o que você está trabalhando, mas precisa ser corrigido, traga-o para o líder da equipe e deixe-o atribuir uma prioridade para consertá-lo e designar uma pessoa (pode não ser você ) para fixar isso. Se ele disser para não gastar seu tempo com isso, então não se preocupe em corrigi-lo. Você está sendo pago para trabalhar naquilo para o qual foi designado para trabalhar e não no que deseja trabalhar. Evidentemente, é preciso mudar isso, mas a definição de prioridades é o trabalho do gerente, não o seu.
É errado alterar o código de trabalho apenas por causa de uma preferência pessoal.
Está errado quando você não entende qual problema o código foi criado para corrigir ou até mesmo entender o código. Só porque não funciona para as suas necessidades não significa que você não vai quebrar alguma coisa se você se meter com isso. Se você precisar mudá-lo para fazer o que você está fazendo funcionar, então fale com o programador ori- ginal sobre por que ele fez o que fez e o que pode ser afetado se você o mudar para atender às suas necessidades. NUNCA altere o código que você não entende, a menos que não esteja funcionando. Isso não significa que você nunca conserte o código, apenas significa que até você ter tempo para entendê-lo completamente, você não o altera, especialmente se já estiver em produção.
When is it right to edit the code written by a co-worker?
Isso depende da fase em que o produto está. Se o produto já está estável e já foi lançado, eu não faria nenhuma alteração que não fosse necessária, a menos que houvesse uma grande mudança necessária para um código realmente feio.
For which issues is it right to edit the code written by a co-worker?
Eu não hesitaria em codificar a formatação. Você deve refatorar quando o código é excessivamente complexo e precisa ser alterado de qualquer maneira ou está causando problemas e nunca parece funcionar corretamente.
Assim como o stackexchange ou wikis, você deve estar pronto para compartilhar seu código e permitir que qualquer um o modifique, desde que as alterações se ajustem ao design e objetivos globais. Mas pergunte a si mesmo: por que alguém deveria modificar o código de outra pessoa se não fosse por depuração? Você claramente cortou seu projeto em pedaços o suficiente para permitir a paralelização da codificação através de múltiplos programadores ao mesmo tempo?
Se, ao mesmo tempo, para diferentes funcionalidades, você for forçado a modificar o mesmo código que seu colega de trabalho, haverá um emaranhamento de código e uma "separação de interesses" incorreta. Você deve revisar seu projeto para permitir que cada programador trabalhe em diferentes partes da base de código do software.