Como assumo a responsabilidade pelo meu código quando um colega faz melhorias desnecessárias sem aviso prévio?

71

Um dos meus colegas de equipe é especialista em toda a loja de TI e eu respeito sua visão.

No entanto, às vezes ele analisa meu código (ele é o segundo em comando do líder da nossa equipe, então isso é esperado) sem aviso prévio. Então, às vezes, ele revisa minhas alterações antes que elas concluam o objetivo final e faça alterações imediatamente ... e até interrompeu meu trabalho uma vez.

Outras vezes, ele fez melhorias desnecessárias em alguns dos meus códigos com mais de 3 meses de idade.

Isso me irrita por alguns motivos:

  1. Nem sempre tenho a chance de corrigir meus erros
  2. Ele não teve tempo para me perguntar o que eu estava tentando realizar quando estava confuso, o que poderia afetar seus testes ou alterações.
  3. Eu nem sempre acho que o código dele é legível
  4. Os prazos não são um problema e sua carga de trabalho atual não exige nenhum trabalho em meus projetos além de revisar minhas alterações de código.

De qualquer forma, eu disse a ele no passado para me manter informado se ele vê algo no meu trabalho que ele quer mudar para que eu possa tomar posse do meu código (talvez eu devesse ter dito "deficiências") e ele não tenha respondido bem. .

Temo que possa parecer agressivo quando lhe pedir que me explique suas mudanças.

Ele é apenas uma pessoa quieta que se mantém calada, mas suas ações continuam. Não quero bani-lo de fazer alterações no código (não como eu poderia), porque somos uma equipe - mas quero fazer minha parte para ajudar nossa equipe.

Esclarecimentos adicionados:

  • Compartilhamos 1 ramo de desenvolvimento. Não espero até que todas as minhas alterações concluam uma única tarefa, pois correrei o risco de perder um trabalho significativo - por isso, garanto que minhas alterações sejam construídas e que não quebrem nada.
  • Minha preocupação é que meu colega de equipe não explique a razão ou o objetivo por trás de suas alterações. Eu não acho que ele precise da minha bênção, mas se discordarmos de uma abordagem, achei melhor discutir os prós e contras e tomar uma decisão depois que ambos entendermos o que está acontecendo.
  • Ainda não discuti isso com o líder da nossa equipe, pois preferiria resolver desacordos pessoais sem envolver a gerência, a menos que seja necessário. Como minha preocupação parecia mais um problema pessoal do que uma ameaça ao nosso trabalho, optei por não incomodar o líder da equipe. Estou trabalhando nas idéias do processo de revisão de código - para ajudar a promover os benefícios de revisões de código mais organizadas, sem expor tudo sobre minhas irritações.
Jesslyn
fonte
20
Você usa git, CVS ou TFS para seu repositório de código? Basta reverter seus commits. Ele vai ter que, eventualmente :)
6
Na minha organização, todas as alterações de código devem passar por uma revisão de algum tipo, e é considerado ruim verificar uma alteração sem observar na descrição da lista de alterações quem foi o revisor. A introdução desse princípio em sua organização pode ser uma solução de longo prazo para o problema dos colegas de trabalho verificando alterações no código que você escreveu sem revisão.
Carolyn
13
Por que você tem alterações não concluídas em uma ramificação compartilhada? Essa é uma péssima idéia, e não apenas pelo motivo que você encontrou.
Hyde
15
Claro que isso depende do VCS que você usa, mas isso pode ser algo a se investigar, começando a usar mais os ramos. Com ramificação pessoal, é ótimo para IMO quando você pode confirmar (e enviar com DVCS) sempre que quiser, sem se preocupar, e mesclar apenas quando concluído com uma peça ou mesclar apenas parcialmente quando necessário (um bom DVCS torna isso muito fácil). Também funciona muito bem com a revisão de código, podendo fazê-lo naturalmente e corrigir problemas antes da mesclagem.
Hyde
4
@Jesslyn - O líder da sua equipe está preocupado com o fato de seu colega estar gastando tempo fazendo melhorias desnecessárias no código antigo? No mínimo, parece ineficiente para seu colega de equipe gastar tempo fazendo alterações desnecessárias, em vez de trabalhar em tarefas de prioridade mais alta. Além disso, se seu colega de equipe prefere gastar tempo "consertando" seu código para você, em vez de capacitá-lo a fazer isso sozinho, isso também parece bastante ineficiente. Você já discutiu alguma dessas preocupações com o líder da sua equipe?
Cliff

Respostas:

81

Acho que a maioria dos desenvolvedores se encontra nessa posição em algum momento, e espero que todo desenvolvedor que se sentiu vitimado perceba o quão frustrante será quando ele ou ela se tornar o mais velho e se sentir compelido a limpar o código escrito pelos juniores.

Para mim, evitar conflitos nessa situação se resume a duas coisas:

  1. Cortesia . Conversar com alguém sobre seu código permite que um desenvolvedor saiba que você está interessado e pode discuti-lo como profissionais adultos.

  2. Esqueça a "propriedade do código" - a equipe é proprietária do código . Outras pessoas que desejam fazer as alterações são boas. Se um desenvolvedor sênior fizer alterações "ilegíveis" ou piores, faça o backup. Você não precisa ser agressivo, deixe um editor saber que suas alterações não funcionaram e você fica feliz em discutir sua reversão.

Lembre-se de que a propriedade do código pela equipe é excelente e funciona nos dois sentidos. Se você vir algo que não faz sentido no código de outra pessoa, corrija-o. Ser excessivamente possessivo e inadequadamente comunicativo é uma maneira infalível de criar um ambiente de desenvolvimento venenoso.

Michael
fonte
4
Eu acho que isso se resume ao ponto 1 - converse com ele. Contar o fato de que o código é alterado em relação ao desenvolvedor original é um gerenciamento terrível (não estou dizendo que isso não aconteça) e eu argumentaria que você precisa solicitar melhores métricas. Atravesse a ponte se e quando isso acontecer.
Michael
2
Eu acho que é nisso que todos devemos nos concentrar - em geral, seus colegas de equipe não querem fazer você parecer mal - não gaste tempo analisando, apenas se torne melhor e um membro mais valioso da equipe (eu sei que é mais fácil dizer que feito embora!) #
Michael
7
@ Jessica, se ele está fazendo isso com você, as chances são de que ele está fazendo isso com todos. Duvido que alguém esteja contando isso contra você. (Se ele não está fazendo isso para todo mundo, você pode ter um problema diferente)
user606723
3
@tgkprog: (1) Obviamente, obter feedback de outras pessoas é muito importante e aprendi algumas coisas ao analisar o código de outras pessoas, mas (2) se você quiser aprender uma com a outra, sugerir uma mudança e discuti-la juntas. . Apenas mudar coisas aleatórias porque você acha que o código é melhor após a alteração não é a abordagem correta. Existem abordagens melhores, como revisões de código, usando ferramentas de revisão.
Giorgio
2
Sim, eu estava pensando em momentos em que eu tenho fixo código outros antes de uma linha de mortos em 11pm mas mesmo assim iria enviar um e-mail para a equipe para que eles possam verificar-lo também, incluindo o nosso QA ....
tgkprog
86

Você e a maioria dos respondentes abordam isso como um problema de comunicação entre dois colegas, mas eu realmente não acho que seja. O que você descreve parece mais um processo de revisão de código horrivelmente quebrado do que qualquer outra coisa.

Primeiro, você menciona que seu colega é o segundo em comando e espera-se que ele revise seu código. Isso está errado. Por definição, as revisões de código por pares não são hierárquicas e, certamente, não são apenas para encontrar defeitos. Eles também podem fornecer experiências de aprendizado (para todos os envolvidos), uma oportunidade de interação social e provar uma ferramenta valiosa para a criação de propriedade coletiva do código. Você também deve revisar o código dele de tempos em tempos, aprender com ele e corrigi-lo quando ele estiver errado (ninguém faz o certo toda vez).

Além disso, você menciona que seu colega faz alterações imediatamente. Isso também está errado, mas é claro que você já sabe; você não teria feito essa pergunta se a abordagem dele não fosse um problema. No entanto, acho que você está procurando uma solução no lugar errado. Para ser perfeitamente honesto, seu colega me lembra um pouco de ... eu, e o que funcionou para mim em situações semelhantes foi um processo de revisão sólido e bem definido e um conjunto de ferramentas impressionantes. Você realmente não quer impedir seu colega de revisar seu código e pedir que ele pare e fale com você antes que todas as pequenas mudanças não funcionem. Pode demorar um pouco, mas em breve ele chegará a um ponto em que tudo ficará muito irritante e você voltará aonde começou, ou pior: ele simplesmente deixará de revisar seu código.

Uma chave para uma resolução aqui pode ser uma ferramenta de revisão de código por pares. Normalmente evito recomendações de produtos, mas para revisões de código Crisol de Atlassiané realmente um salva-vidas. O que ele faz pode parecer muito simples, e é, mas isso não significa que não é incrivelmente incrível. Ele se conecta ao seu repositório e oferece a oportunidade de revisar conjuntos de alterações individuais, arquivos ou grupo de arquivos. Você não pode alterar nenhum código, mas comentar sobre tudo que não parece certo. E se você absolutamente precisar alterar o código de outra pessoa, basta deixar um comentário com o conjunto de alterações explicando suas alterações. Vale a pena assistir ao vídeo introdutório na página do produto do Crisol, se você quiser mais detalhes. Os preços do Crisol não são para todos, mas existem inúmeras ferramentas de revisão por pares disponíveis gratuitamente. Com quem trabalhei e gostei foi o Painel de Revisão e tenho certeza de que você encontrará muitos outros com uma simples pesquisa no Google.

Qualquer que seja a ferramenta que você escolher, ela mudará completamente seu processo. Não há necessidade de parar, levantar da cadeira, interromper a outra pessoa e discutir as mudanças; tudo o que você precisa fazer é dar um tempo toda semana e passar pelos comentários (uma vez por semana é apenas uma sugestão. Você conhece melhor sua programação e rotina diária do que eu). Mais importante, as análises principais são armazenadas em um banco de dados em algum lugar e você pode recuperá-las a qualquer momento. Eles não são discussões efêmeras em torno do bebedouro. Meu caso de uso favorito para revisões antigas é ao apresentar um novo membro da equipe à nossa base de código. É sempre bom quando eu posso orientar alguém novo na base de código, apontando onde exatamente estávamos presos, onde tínhamos opiniões diferentes etc.

Seguindo em frente, você menciona que nem sempre acha o código desse colega legível. Isso me permite saber que você não possui um conjunto comum de padrões de codificação, e isso é uma coisa ruim. Novamente, você pode abordar isso como um problema de pessoas ou como um problema de processo e, novamente, sugiro fortemente o último. Reúna sua equipe e adote um estilo comum de codificação e um conjunto de padrões o mais rápido possível. Realmente não importa se você escolheu um conjunto de padrões comuns no seu ecossistema de desenvolvimento ou se criou o seu próprio. O que realmente importa é que seus padrões sejam consistentes e que você os cumpra. Muitas e muitas ferramentas por aí podem ajudá-lo, mas essa é uma discussão totalmente diferente. Apenas para você começar, uma coisa muito simples de fazer é ter um gancho de pré-confirmação executando algum tipo de formatador de estilo no seu código. Você pode continuar escrevendo seu código da maneira que desejar e deixar a ferramenta "corrigi-lo" automaticamente, antes que alguém o veja.

Por fim, você menciona em um comentário que a gerência não acredita que sejam necessários ramos de desenvolvimento individuais. Bem, há uma razão para chamá-los de "ramificações de desenvolvimento" e não "ramificações de gerenciamento". Vou parar por aqui, pois não há razão para o discurso retórico que está se formando em minha cabeça sair.

Tudo isso dito, saiba que não duvido que seu colega esteja (um pouco) culpado aqui. Esse não é o meu ponto, meu argumento é que todo o seu processo de desenvolvimento também está errado, e isso é algo mais fácil de corrigir. Arme-se com as ferramentas adequadas, explore os inúmeros processos formais e informais e escolha aqueles que se encaixam na sua equipe. Em breve você chegará a um ponto em que perceberá que a maioria dos seus "problemas com as pessoas" não existe mais. E, por favor, não ouça ninguém (inclusive você) que traga a desculpa de "somos uma equipe pequena, não precisamos de tudo isso". Uma equipe de desenvolvedores competentes pode configurar as ferramentas necessárias em menos de uma semana, automatizar tudo o que pode ser automatizado e nunca olhar para trás novamente.

PS. "Propriedade do código" é um termo nebuloso, constantemente debatido, e significa coisas diferentes para pessoas diferentes. Você pode encontrar uma coleção brilhante da maioria das opiniões diferentes (e às vezes antitéticas) sobre C2 .

yannis
fonte
7
+1 e mais se eu pudesse. Ótima resposta que aborda as melhores maneiras de melhorar esse processo.
precisa
2
Sim, o OP precisa de uma ferramenta de revisão de código, para que você possa revisar o código juntos, não é apenas alguém que altera o código, porque ele deseja. Nós só comecei a usar smartbear.com/products/software-development/code-review no trabalho
Juan Mendes
19

Qual é o processo que faz você querer assumir a responsabilidade por "seu código"? Você tem a responsabilidade exclusiva de manter certos recursos funcionando? O líder disse "Michael, quero que você assuma a responsabilidade por ..."? Ou sua responsabilidade está implícita, na medida em que o líder e o restante da equipe olham para você toda vez que certos recursos são desfeitos?

De qualquer forma, se você tiver a responsabilidade, precisará de autoridade sobre o código. Na próxima vez que o outro sujeito fizer mudanças unilaterais e o líder voltar para você para corrigi-lo, sente-se e peça para alinhar sua autoridade e responsabilidade.

Kevin Cline
fonte
5
+1 Por apontar um fato importante: existe propriedade da equipe e (1) todos são responsáveis ​​(2) todos podem alterar o código ou existe propriedade individual e (1) o proprietário do módulo é responsável (2) todas as alterações devem ser aprovado pelo proprietário do módulo. Muitas vezes, surge confusão quando se espera que um membro da equipe seja responsável por um módulo, mas um membro sênior se sente autorizado a fazer alterações aleatórias no código. Em outras palavras, é preciso evitar a situação de "responsabilidade sem autoridade".
Giorgio
4

Não que isso resolva toda a situação, mas você pode tentar adicionar mais comentários ao seu código-fonte.

  1. Se o código não estiver completo, poderá ser marcado como tal.
  2. Se o objetivo de um bloco de código não for auto-documentado, você deve documentá-lo.

Tudo e todos, tente fazer limonada, em vez de perder tempo chupando limões. Como Michael disse, em geral, os colegas de equipe não querem fazer você parecer mal. Tente aprender com seus erros e aplicá-los a futuras revisões.

Se você acredita que as mudanças dele estão tendo um impacto negativo, exprima isso (diplomaticamente). Se fosse eu, eu simplesmente perguntaria por que alterações específicas foram feitas e verificamos se você pode defender suas alterações originais. Seus colegas de trabalho seniores também são humanos. É bem possível que ele tenha perdido algo e / ou não tenha conhecimento de qualquer impacto negativo que esteja causando.

user606723
fonte
3
Garoto que pode ficar confuso. Imagine - adicionando um comentário dizendo "Este código não está completo" e esquecendo de removê-lo depois de concluir o código.
Rjalk
11
@ Stargazer712, Mais confuso do que ter código incompleto no ramo?
user606723
É para isso que servem as prateleiras. Não verifique o código incompleto.
riwalk
2
Não. Se você verificar o código incompleto que precisa de um comentário para rotulá-lo como tal, então você já está no inferno. Comentários apenas levam você a um canto diferente do inferno.
riwalk
11
Eles são chamados de TODOs, eles são deixados no código de trabalho o tempo todo
Juan Mendes
4

Todos implicitamente 'possuem seu próprio código', independentemente da política, legalismo ou economia - é a 'natureza das coisas' - você naturalmente sente uma conexão pessoal com seu próprio trabalho.

Se o seu colega de trabalho está se engajando no comportamento que você descreveu e permanece indiferente ao pedir um alerta , esse colega de trabalho é descortês, para dizer o mínimo, e pode estar tentando prejudicá-lo (para dizer o pior .. .) - NÃO soa como um jogador da equipe.

Um bom colega de trabalho iria tocar na base com você e apontar o problema com o seu código para você - e deixou fixar / alterá-lo ou responder apropriadamente. Sou muito grata por, mesmo quando eu era recém-nascida, meus mentores sempre apontarem para mim o que eu estava fazendo de errado, explicar o porquê e me deixar (ou me fazer ) consertá-lo. Isso me fez um programador melhor e todos se beneficiaram. E é isso que sempre fiz ao revisar o trabalho realizado por outras pessoas. Então você (ou quem quer que seja) aprende alguma coisa com o seu 'pau para toda obra', e o código e a equipe ficam melhores, incluindo o professor: o ensino ajuda a entender.

Se for possível, eu discutirei o assunto em particular com o líder da equipe. Com base na sua descrição da situação, um bom líder de equipe vai ficar do seu lado - um ruim não. ... Obviamente, isso requer cautela - você terá que julgar por si mesmo.

Vetor
fonte
11
Além da declaração inicial (existem equipes que adotam a propriedade da equipe e outras que adotam a propriedade individual), acho as observações nesta resposta corretas (+1 para isso): Também observei a propriedade do código compartilhado sendo usada para minar uma equipe posição do membro dentro da equipe modificando arbitrariamente seu código. Então, eu não entendo os votos negativos. Seria bom se os desonestos quisessem explicar.
Giorgio
11
Acho que a resposta de Mikey é uma boa explicação sobre como permanecer como jogador de equipe. Talvez isso seja muito focado nas pessoas? Como Yannis sugeriu, o processo de desenvolvimento da minha equipe parece ser o verdadeiro problema. Independentemente disso, estou curioso para saber por que isso foi rebaixado.
Jesslyn
11
@ Jessica - eu suponho que fui votado por causa da minha declaração "Todo mundo implicitamente 'possui seu próprio código'". Esta é uma questão filosófica, não uma questão de política. :-)
Vector
11
@ Mikey: "Todos implicitamente 'possuem seu próprio código'" Isso pode ser uma questão de debate, é claro. Programadores que não trabalham por conta própria normalmente assinam um contrato que diz que não possui o código-fonte. Além disso, acho que o autor do código é quem entende melhor o código e, se alguém o altera, nem o autor nem o segundo desenvolvedor realmente entendem o código 100%.
Giorgio
11
@ Mikey: A propriedade compartilhada do código tenta garantir que membros da equipe compreendam o código suficientemente bem (enquanto ninguém realmente o entende muito bem). Isso é preferível à propriedade do código individual, onde cada módulo é (pelo menos em princípio) totalmente compreendido por um programador, mas existe o risco de que esse conhecimento se perca se o programador for encerrado.
Giorgio4
1

Se você escrever um código, eu devo revisá-lo.

Se eu alterar o seu código durante a revisão, o código não será mais o código que eu revisei, mas o código que eu alterei. Portanto, ele precisa ser revisto. Provavelmente por você.

Se eu confirmar seu novo código com minhas alterações sem que alguém as revise, cometi (1) uma alteração não revisada e (2) o pior pecado possível se as revisões de código forem levadas a sério.

gnasher729
fonte
0

Eu acho que você está lidando com isso da maneira certa por enquanto - mas em breve haverá um ponto de inflexão em que isso o distrai a ponto de você não ser feliz em codificar dessa maneira.

Se eu fosse você, solicitaria um rápido contato individual com essa pessoa e explicaria meu ponto de vista com calma e firmeza. A propriedade do código da equipe etc. é boa, mas, a menos que você ofereça espaço suficiente a todos os desenvolvedores para realizar seu trabalho, cometer erros e melhorar, você nunca criará um bom código. Esta pode ser uma área de atrito mais cedo ou mais tarde.

(Existe uma resposta totalmente diferente se isso ocorreu no local de trabalho. Troca de pilha. Descobrir a maneira correta de fazer revisões de código é a parte mais fácil. Convencer seu colega de trabalho a cumprir isso é muito mais difícil).

Sandeep
fonte