Meu colega não entende as coisas com as quais trabalha. O que fazer? [fechadas]

13

Passei 3 dias depurando um bug muito obscuro em uma biblioteca criada por meu colega, esse bug ocorre com pouca frequência. Afinal, descobri que esse bug ocorre devido ao acesso entre threads a um objeto sem nenhum bloqueio. Na verdade, esse não é o primeiro bug desse tipo; havia erros semelhantes antes. Ele apenas executa seus testes de unidade e, se algo falhar, coloca um bloqueio em algum lugar. E se nada falhar, ughm, então o código dele é perfeito. Parece que ele não tem idéia sobre a segurança da linha. Tenho 100% de certeza de que existem muitos erros semelhantes que ainda não foram descobertos. Parece que o PM também não entende coisas de encadeamento.
O problema é que ele trabalha muito mais tempo na empresa do que eu. De qualquer forma, não posso simplesmente dizer "esse cara é incompetente nessa área", porque isso sempre mostra você como um "mau jogador de equipe" etc.

project-management tika
fonte
Que país é esse?
É uma empresa internacional.
tika
2
Se realmente é um grande problema e você tem 100% de certeza de que seu colega está cometendo um erro, a primeira coisa é apontar educadamente de maneira que ele não seja ameaçado. A segunda coisa é que, se o seu colega não escuta, é apenas apontar os possíveis danos em dinheiro. É isso que todos os gerentes ouvem e com muito cuidado. Ter um problema de segmentação como o que você descreveu é potencialmente muito prejudicial e, a menos que você esteja 100% certo em suas declarações, continue com elas.
NB
Provavelmente pertence ao site do Project Management SE.
23412 Bernard
1
O site do Project Management SE não possui uma marca "Multithreading", que esta pergunta deve ter.
RalphChapin

Respostas:

13

Convença a PM de que, para evitar esses erros, o conhecimento da equipe sobre o encadeamento de itens deve ser aprimorado e diga a eles que você está disposto a organizar algo como um workshop ou uma apresentação sobre o assunto. Não faça disso algo pessoal entre você e seu colega.

Doc Brown
fonte
Receio que isso não seja bem-vindo por esse cara, porque ele pensa que é profissional nessa área (e pode ensinar a todos). Mas eu posso tentar.
tika
Ah, sim, e um grande problema - o inglês não é minha língua nativa, não falo muito bem.
tika
Se o seu colega e o gerente de projetos têm conhecimento limitado de encadeamento e segurança de threads, o treinamento é definitivamente a melhor abordagem. Não é a incompetência de um cara - é a competência da equipe que é o problema.
Boisvert
1
Um workshop é algo em que todos vocês podem usar o conhecimento deles, e todos devem aprender algo com ele. Se o seu colega acha que sabe algo sobre o encadeamento, talvez você possa aprender algumas coisas com ele também.
Doc Brown
8

Escreva um teste de unidade que mostre o erro e peça a ele para corrigi-lo.


fonte
1
Ele já está ciente desse bug. Ele simplesmente não consegue encontrar o motivo.
tika
Você não encontrou o motivo na sessão de depuração de três dias? Ou leio sua pergunta incorretamente?
1
@scarfridge Depende da plataforma. Para Java, você pode usar a instrumentação de código de bytes ou a programação orientada à Aspect para inserir uma espera exatamente onde está o problema (ou usar a JVMTI para controlar a execução). É possível fazer!
1
Não é apenas questão de sequência. Muitos outros fatores estão envolvidos - que núcleos de execução de código, quando GC ocorre e como ele se move objetos, como as alterações são propagadas a partir do cache de um núcleo para outro, etc.
tika
1
Na verdade, é apenas um conjunto de métodos que chama bilhões de vezes repetidos. Mas isso não importa muito. O verdadeiro motivo é o acesso a um objeto de dicionário a partir de 2 threads sem bloqueio (ou seja, sem barreiras de memória). O segmento A cria, o segmento B lê.
21312
4
  • É tarefa de um desenvolvedor sênior revisar seu código e sugerir melhorias.
  • Você não está lá para checar o trabalho dele, eu pessoalmente odiaria se alguém estivesse checando todas as minhas alterações para ver se algo quebrou
  • Se ele não aceitar o seu conselho, o trabalho do PM é corrigir o problema de comunicação.
  • O problema de encadeamento em um teste de unidade me faz pensar se esse teste é realmente um teste de unidade, em vez de teste de integração ou componente.
CodeART
fonte
Eu entendi sua ideia. Obedeça seu comando.
tika
2
O que importa se um teste que mostra um problema é chamado de "teste de unidade" ou "teste de integração"? Toda a situação permanece a mesma.
Doc Brown)
1
Minha preocupação é que seu colega possa não saber a diferença entre o teste de unidade e componente; portanto, talvez seja necessário treinamento adicional para resolver esse problema.
CodeART
@ CodeRush - Presumo que você não acredita em revisão por pares? O que seria necessário para você realmente apreciar que outra pessoa estava revisando seu código (em vez de apenas travar na produção)?
Entendi a idéia, mas não a vi funcionando efetivamente em meus trabalhos anteriores. Penso que as análises de um desenvolvedor sênior são um mecanismo de feedback melhor.
código é o seguinte
-5

Acho que sua empresa não deve usar multithreading.

Depois de fazer um projeto massivamente multithread, achei duas técnicas essenciais para fazer as coisas funcionarem. Primeiro , o código teve que ser escrito corretamente. Todos os campos precisavam ser verificados manualmente para garantir que fossem declarados de maneira adequada e sincronizada onde quer que fosse. (Aviso: estou simplificando um pouco as coisas aqui para manter minha resposta curta - ou pelo menos menor). Segundo , o código teve que ser testado, executando-o em máquinas simples e com vários núcleos - muitos minutos usando 100% de cada núcleo. (E se ele usa apenas 2% de cada núcleo, como costumava fazer para mim, isso também é um bug).

Você pode gerenciar isso, mas sua organização não pode. Mesmo se eles entenderam o problema, o que eles não entendem, eles não têm o conhecimento.

A maioria dos idiomas fornece maneiras de evitar isso. Se você possui um leitor de soquete, que geralmente possui seu próprio encadeamento, solicite que ele encaminhe as informações para o encadeamento principal o mais rápido e simples possível. Melhor ainda, procure classes / funções do sistema que manipularão a parte da discussão da leitura para você. Use uma fila que execute "eventos" um após o outro, como a maioria das APIs da GUI. (Use a própria fila de eventos da API da GUI, se for necessário.) Se você precisar de processamento paralelo, provavelmente poderá encontrar algum tipo de "thread de trabalho" que permitirá manter os dados / campos em um único thread, manipulando todas as transferências para você.

Enfatize todos os perigos do multithreading. (Histórias assustadoras: meu bug favorito envolveu algumas linhas como int i = 5; i = i * i;:, que resultaram em ium valor de 35. Um que eu vi muito foi: if (thing != null) thing.reset();lançar uma exceção de ponteiro nulo.) Acho que sua única esperança é fazê-los entender que são entrando em um mundo novo e estranho e que talvez eles devessem dar um grande passo para trás.

Não tenho muita certeza de como o multithreading deve ser tratado. Se o trabalho puder ser dado a uma pessoa e tudo o que eles fizerem fora, se falharem, tudo bem. Mas uma equipe só será tão forte quanto seu membro mais fraco e até um bom programador terá problemas com o multithreading completo. Espero que o pessoal do idioma encontre uma maneira de torná-lo seguro. Eu vi alguns softwares úteis por aí. Mas acho melhor evitar multithreading, a menos que o tempo de execução seja crítico e um bom programador ou uma equipe comprovada esteja disponível.

RalphChapin
fonte
2
Você não tem idéia de qual empresa é ou o que está fazendo; portanto, o comentário "Você pode gerenciar isso, mas sua organização não pode" é um pouco infundado - pelo que você sabe, tika poderia trabalhar na Microsoft . Quem quer que seja, o multithreading pode muito bem ser a melhor maneira de resolver seu problema; existem muitas situações em que ele se encaixa. E colocando tudo isso de lado, a questão não é sobre multithreading, é sobre como lidar com um colega que está causando problemas devido à falta de conhecimento.
Anaximander
@anaximander: Multithreading produz bugs que são muito difíceis de reproduzir e muito difíceis de rastrear. Para produzir um software MT utilizável e corrigível, você precisará, no mínimo, de programadores e gerenciamento que estejam cientes dos perigos. A organização de Tika claramente não conseguiu lidar com isso. Vi pessoas de teste / controle de qualidade forçarem os programadores a escrever código de som testando muito e exigindo correções para cada bug. Isso não funciona com o MT. Se o colega não tiver habilidade, interesse e motivação, lide com ele, mantendo-o afastado do MT.
precisa saber é o seguinte
@anaximander: Você deve ter tido melhores experiências com a Microsoft do que eu. Embora seja justo, nunca vi nada que parecesse um bug de leitura de códigos deles. ....E obrigado pelo comentário.
precisa saber é o seguinte
1
Independentemente disso, quando a pergunta é "como faço para lidar com um colega que não possui experiência?", Não acho que "sua empresa está criando software errado" é uma resposta válida. Em qualquer organização, não importa o quão vasto e experiente, sempre haverá pessoas com lacunas em seus conhecimentos. Sem saber quem é a organização ou o que o software está fazendo, acho que você não pode julgar com segurança que a empresa não sabe o que está fazendo ou que o problema pode ser resolvido sem multithreading.
Anaximander