Acabei de sair da Universidade e tenho trabalhado nessa empresa há aproximadamente 8 meses, enquanto recebi o título de desenvolvedor, na maioria das vezes que gastei consertando e depurando códigos de outras pessoas.

Eu sempre me pergunto por que não é responsabilidade do desenvolvedor original corrigir o código dele / dela. Entendo que, se o desenvolvedor original não estiver mais presente, os outros desenvolvedores terão que assumir o trabalho, mas e se o desenvolvedor ainda estiver trabalhando como funcionário da empresa?

Alguém pode argumentar que é benéfico para os novos desenvolvedores, pois eles vêem isso como uma oportunidade de aprender, e eu concordo com isso, mas e se a complexidade do problema / questão do código for muito acentuada? No meu caso, a maioria dos códigos que eles me designaram para corrigir não são problemas triviais, e sempre acabo perguntando ao desenvolvedor original perguntas sobre o código. Por que os desenvolvedores que o criaram não podem resolver o problema existente se o entendem muito melhor desde que o codificaram? E o problema ao qual estou me referindo não é um problema trivial em que você pode corrigi-lo em um dia ou dois, mas um problema que requer uma compreensão profunda do código para encontrar uma solução.

Qual é o raciocínio por trás disso e é comum na indústria de software?

Eu acho que a principal razão pela qual você verá justificar esse tipo de coisa no sentido mais amplo é o "fator de barramento" . Se a mesma pessoa escreve e mantém um pedaço de código perpetuamente, ninguém além dessa pessoa terá alguma idéia de como funciona, o que é um problema quando essa pessoa sai. Portanto, ter novos desenvolvedores corrigindo bugs para começar é geralmente justificado com essa lógica.

Pessoalmente, acho que é improvável que a justificativa corresponda ao raciocínio. Eu acho que o motivo real disso acontecer com os desenvolvedores mais recentes é que os departamentos realmente não sabem o que fazer com eles, realmente não têm um programa de treinamento abrangente e estão nervosos em atribuir-lhes os principais recursos. Portanto, seja o que for que lhe digam, é provavelmente uma maneira padrão de provar que você é capaz de lidar com coisas e, com sorte, aprender uma coisa ou duas ao longo do caminho.

Pessoalmente, acho que existem maneiras muito melhores de conseguir isso, mas é uma maneira, e suponho que às vezes funcione, de certa maneira (apesar do risco de entediar novatos em abandonar pastagens mais verdes).

Outros comentaristas já abordaram alguns pontos importantes - estou falando da posição de alguém que trabalhou por um tempo em uma equipe de desenvolvimento especificamente encarregada da manutenção do código enviado. Praticamente todas as suas perguntas surgiram uma e outra vez.

Há muitas coisas que poderiam estar acontecendo. Você apontou um - o desenvolvedor original pode ter deixado a empresa. Outra possibilidade é que, enquanto o desenvolvedor original ainda está na empresa, ele / ela já passou para outras coisas e não possui mais esse material na memória de trabalho (especialmente se o código mudou bastante desde que estavam trabalhando) nele).

O que tivemos que lidar, por exemplo, é que a equipe do produto tinha cronogramas muito agressivos para a entrega das próximas versões do produto. Se eles também tivessem que trabalhar com bugs nas versões existentes, pelo menos para o raciocínio, eles não teriam conseguido cumprir suas agendas. Acho que esse ponto pode ser discutido, mas a realidade do mundo corporativo dos softwares é que divulgar as coisas supera tudo, inclusive observar todas as melhores práticas de engenharia de software o tempo todo. "Trocas" é o termo vago sob o qual caem todos os compromissos desagradáveis ​​que os desenvolvedores, mais cedo ou mais tarde, terão que fazer nesses ambientes.

Por outro lado, no entanto, corrigir bugs não triviais exige que você realmente aprenda muito sobre a base de código. É doloroso, às vezes desmoralizante e muitas vezes avassalador. Mas como exatamente você acha que se tornará um especialista no assunto em um projeto de software? Você pode passar dias lendo o código para sua edificação, mas esse tipo de leitura de código realmente não funciona, além de ter que "batalhar" com o código para corrigir um problema. Pesquisas continuamente superam o lema que aprendemos fazendo. Infelizmente, a menos que você esteja em uma startup ou em uma nova equipe, isso significa que você geralmente está ingressando em um projeto de software que já existe há vários lançamentos e tem clientes reais com reclamações reais que precisam ser abordadas. Isso implica que você irá corrigir os erros primeiro antes de

O que é realmente importante é se comunicar regularmente com seu gerente e expressar o que você deseja sair do trabalho e ver se a empresa pode realmente se adequar às suas metas no momento. Felizmente, a resposta será sim. Fique por um tempo e junte toda a experiência possível da sua equipe atual. Se a resposta for negativa, e você for um bom desenvolvedor, terá muitas opções. Mas não descarte a experiência que você ganha com a correção de bugs - agora estou no meu terceiro trabalho de software e preciso escrever muito código. Felizmente, muito disso funciona desde o início, porque passei muito tempo identificando, corrigindo e tentando evitar bugs.

Temos que admitir que os desenvolvedores de software passam muito mais tempo lendo / entendendo o código do que criá-lo. E, pela minha experiência pessoal, melhor é a empresa em que você trabalha e mais código lê. Portanto, o fato de você ter que lidar tanto com o código de outras pessoas não deve surpreendê-lo ou confundi-lo.

E isso parece bastante natural. Para aprender algo, você precisa ver como é feito. Não há muitas empresas onde a programação de pares é praticada e os novatos são ensinados dessa maneira. Na maioria das vezes, você aprende novas técnicas, padrões, estilo de codificação da empresa, etc., lendo o código de outras pessoas.

E a maneira mais eficiente de entender o código é trabalhar com ele: depuração, refatoração, correção de bugs. Essa é uma prática comum se você for o proprietário do código.

As possíveis razões pelas quais o desenvolvedor original não corrige seus erros podem ser

• o bug tem pouca prioridade e a tarefa atual do desenvolvedor é mais importante ou urgente.
• o desenvolvedor não trabalha com esse código há muito tempo e levaria algum tempo para recuperar o código antigo.
• o desenvolvedor está muito ocupado com algo complicado e não precisa ser interrompido.

PS: Acho que você tem sorte que o desenvolvedor original esteja lá para responder às suas perguntas.

Existem razões pedagógicas e fatores de risco, mas principalmente é apenas matemática. A maior parte do trabalho de programação é manutenção, e aqueles que estão há mais tempo em uma empresa geram o maior número de códigos que precisam ser mantidos.

Considere uma empresa de software de um homem. Após 10 anos, ele contrata alguém para ajudá-lo. Se 90% do trabalho disponível é de manutenção, em que o novo funcionário trabalhará se ele não puder tocar no código do idoso? Em uma equipe maior, o efeito é mais difícil de quantificar, mas isso não significa que não esteja lá.

Portanto, tente não se prender a quem é responsável por qual código. As pessoas se apegam ao código "deles" e não o abandonam. Em alguns anos, haverá um código pelo qual você deseja preservar sua responsabilidade, mas você simplesmente não terá tempo.

Erik está no local.

Além disso, a gerência deseja proteger suas apostas, familiarizando todos os desenvolvedores com certos aspectos do código. Só porque uma pessoa escreveu algum código não os responsabiliza automaticamente enquanto eles estão trabalhando lá. Muito pelo contrário, quanto mais desenvolvedores o mantiverem, maior a chance de erros serem detectados e melhorias nas redes. Todo mundo gosta de deixar sua marca;) se você entende o que quero dizer. Outra visão é que o código pertence à empresa e não ao desenvolvedor. Isso torna a vida dos gerentes de projeto um pouco mais fácil se eles tiverem mais desenvolvedores para escolher para uma determinada tarefa. Eles provavelmente estão apenas facilitando o acesso às suas bibliotecas de códigos e, ao mesmo tempo, testando sua capacidade. Eles ficariam loucos deixando um novo funcionário perto de qualquer coisa que pudesse custar dinheiro à empresa, certamente pelos primeiros 6 meses.

boas respostas, tudo; aqui está outro ângulo -

pode ser simples economia

pode levar cinco vezes mais tempo para encontrar e corrigir um problema do que o desenvolvedor original, mas o trabalho que o desenvolvedor original está fazendo nesse meio tempo fornece muito mais receita para a empresa