Lidar com colegas de trabalho durante o desenvolvimento, precisa de conselhos [fechado]

Desenvolvi nossa arquitetura de projeto atual e comecei a desenvolvê-la por conta própria (atingindo algo como, revision 40) .

Estamos desenvolvendo uma estrutura simples de roteamento de metrô e meu design parecia ter sido extremamente bom - vários modelos principais, visões correspondentes, lógica principal e estruturas de dados foram modelados "como deveriam ser" e totalmente separados da renderização, parte algorítmica também foi implementada além dos modelos principais e possuía um número menor de pontos de interseção.

Eu chamaria esse design de escalável, personalizável, fácil de implementar, interagindo principalmente com base na "interação da caixa preta" e, bem, muito bom.

Agora, o que foi feito:

• Comecei algumas implementações das interfaces correspondentes, portou algumas bibliotecas convenientes e escrevi stubs de implementação para algumas partes do aplicativo.
• Eu tinha o documento descrevendo o estilo de codificação e exemplos desse uso de estilo de codificação (meu próprio código escrito).
• Forcei o uso de C++técnicas de desenvolvimento mais ou menos modernas , incluindo no-deletecódigo (envolto por ponteiros inteligentes) e etc.
• Documentei o objetivo das implementações de interface concretas e como elas devem ser usadas.
• Testes de unidade (principalmente testes de integração, porque não havia muito código "real") e um conjunto de zombarias para todas as abstrações principais.

Fiquei ausente por 12 dias .

O que temos agora (o projeto foi desenvolvido por outros 4 membros da equipe):

• 3 estilos de codificação diferentes em todo o projeto (acho que dois deles concordaram em usar o mesmo estilo :) , o mesmo se aplica à nomeação de nossas abstrações (por exemplo CommonPathData.h, SubwaySchemeStructures.h) , que são basicamente cabeçalhos que declaram algumas estruturas de dados.
• Absoluta falta de documentação para as peças recentemente implementadas.
• O que eu poderia chamar recentemente de single-purpose-abstractionagora lida com pelo menos 2 tipos diferentes de eventos, tem forte acoplamento com outras partes e assim por diante.
• Metade das interfaces usadas agora contém variáveis ​​de membro (sic!).
• Uso de ponteiro bruto em quase todos os lugares.
• Testes de unidade desativados porque " (Rev.57) They are unnecessary for this project".
• ... (provavelmente não é tudo) .

O histórico de confirmação mostra que meu design foi interpretado como um exagero e as pessoas começaram a combiná-lo com bicicletas pessoais e rodas reimplementadas e tiveram problemas para integrar os pedaços de código.

Agora - o projeto ainda faz apenas uma pequena quantidade do que precisa fazer, temos sérios problemas de integração, presumo que haja algum vazamento de memória.

Existe alguma coisa possível para fazer neste caso?

Percebo que todos os meus esforços não tiveram nenhum benefício, mas o prazo é muito breve e temos que fazer alguma coisa. Alguém teve uma situação semelhante?

Basicamente, pensei que um bom (bem, eu fiz tudo que pude) iniciar para o projeto provavelmente levaria a algo bom, no entanto, eu entendo que estou errado.

Refatorar impiedosamente para sair da bagunça!

Pegue o estilo de codificação que representa a maior parte do estilo utilizável e use-o para este projeto.

O pior é que você deve reverter para a revisão 40 e seus programadores tiveram uma sessão de treinamento de 12 dias, que lhes deu uma melhor compreensão do assunto.

Se seus programadores têm muito a aprender sobre codificação limpa, os doze dias são os menores atrasos que você terá.

Parafraseando sua pergunta - "Fui embora por algumas semanas e discordo do que minha equipe fez quando fui embora, como faço para fazê-las fazer o que quero quando não estou aqui?"

Afirmei que isso não é um problema técnico, é um problema de gerenciamento. Minha opinião (por favor, me perdoe se eu estiver errado) é que você dita a solução técnica para um exército de lacaios, que por algum motivo não pode ou não concorda ou entende sua solução.

Se 12 dias forem suficientes para causar tanto dano ao seu projeto, deve haver uma razão. O design é frágil? é sobre engenharia? ou a equipe fez isso por despeito? Como são seus prazos e entregas? Justa? eles estavam apenas tentando encontrar um?

Em um caso que eu vi, o líder técnico estava tão à frente do jogo que o desenvolvedor médio (eu) não conseguiu acompanhar. O líder técnico falhou ao projetar código comercialmente viável, pois ele era o único que poderia mantê-lo. Se um desenvolvedor de graduação não pode mantê-lo, é muito complexo para o mundo comercial. Em todos os outros casos, foi simplesmente a falta de habilidades de gerenciamento de pessoas por parte do gerenciamento.

A dinâmica da equipe está quebrada. Você pode (como sugerido por outros) gastar tempo refatorando a bagunça e precisar fazer tudo novamente na próxima vez que sair. Pode ser necessário aprimorar os membros de sua equipe, mas acredito que você precisa corrigir a dinâmica da equipe primeiro, pois eles parecem ter habilidades suficientes para realizar o trabalho, não importa o quão feio você acredite.

Par.

O que você está descrevendo é muita coisa certa, tecnicamente, solo . Sim, você tentou documentar, tentou impor padrões - mas (aparentemente) não conseguiu se comunicar.

Bem, sua equipe acabou de se comunicar com você, de forma bastante retumbante. Eles disseram: "Ei, Yippie - você não está se comunicando!" A forma mais poderosa de comunicação que conheço é o emparelhamento. Par. Até que eles entendam, ou até que persuadam você a fazer diferente.

Como Brooks nos disse nos últimos 30 anos, a integridade conceitual é a parte mais importante de qualquer projeto. Para qualquer subsistema não trivial e completo, deve haver exatamente uma pessoa, responsável por seu design e ter autoridade para direcionar sua implementação. Ocorreu um erro nesta parte do seu projeto. Fosse o que fosse, a única solução é reverter para o código no repositório que existia antes que isso acontecesse. Uma perda de 12 dias não é nada comparada com as despesas de manutenção de design quebrado. Eu também pensaria nas maneiras de remover as pessoas envolvidas nessa busca de mais trabalhos no projeto, uma vez que se mostraram incompetentes.

Uma coisa que eu faria para iniciantes é obter uma boa ferramenta de revisão de código, usando-a para marcar o código incorreto e documentar por que ele é ruim e (conceitualmente) como deve ser feito. Agora, pelo que entendi, muitas coisas ruins foram feitas e, portanto, seria muito trabalho revisar; supondo que você é o único que vê algo errado com o código, pode não ser possível revisar tudo sozinho. Mas você pode marcar as piores ofensas e transformá-las em entradas no sistema de rastreamento de problemas, atribuídas à pessoa que escreveu o código correspondente.

O melhor incentivo para escrever código de qualidade é saber que, se não o fizer, ele o assombrará no futuro. Seus colegas de trabalho não parecem se importar com isso, então o melhor remédio é fazê-los refatorar as partes erradas e aprender.

Com o tempo, você pode revisitar outras partes do código que são problemáticas e reatribuir ao autor (incorreto) original. Depois de um tempo, eles perceberão os benefícios de fazer um bom trabalho pela primeira vez.

Suponho que você não considere uma reversão para sua versão original uma opção - em outras palavras, apesar do código incorreto que seus colegas de trabalho escreveram, eles adicionaram alguma funcionalidade e o valor líquido da versão atual é maior que o original. Também estou assumindo que, mesmo que não seja esse o caso, você não tem capital político para fazer essa reversão e faz com que reescrevam o código (como poucas pessoas no planeta têm esse capital). Essas e muitas outras são as complexidades de julgar uma situação em que não estou passando por mim, mas espero que meus dois centavos tenham ajudado.

Uma coisa que não vi mencionada, mas que surgiu recentemente onde trabalho são os problemas de "silos de desenvolvedor" e "buy in".

No início do meu projeto atual, acabei criando uma biblioteca principal basicamente sozinha. (Como você fez até a rev. 40). Então, quando terminei, apresentei ao restante da equipe e disse a todos que eles poderiam começar a usá-lo. O que aconteceu nos meses subseqüentes foi que as pessoas continuaram implementando o mesmo material que já estava nessa biblioteca em outros lugares. O CTO (que codifica ativamente) ressalta que nunca houve um comprometimento do restante da equipe nas interfaces de arquitetura / design / público da biblioteca.

Bem, passamos por uma grande reescrita dessa biblioteca que, sem dúvida, melhorou o design geral para se encaixar melhor no que estamos fazendo atualmente, mas, novamente, um desenvolvedor tomou a biblioteca como seu único projeto, trabalhou por várias semanas e então apenas a apresentei. "Voila! Aqui está! Não é bonito?"

Agora que estou tendo que usar a nova versão e o mesmo problema está aí - eu odeio o jeito que ele fez isso. E ele deixou de fora as coisas necessárias porque não conseguiu colaborar com mais ninguém enquanto trabalhava nisso. Então, novamente, estou começando a implementar o mesmo material em outros lugares e maneiras de trabalhar para o que preciso fazer.

Longa história - Se você deseja que a qualidade do código aumente e seja consistente, sugiro que você junte toda a equipe para estabelecer padrões, estilos etc. Além disso, a qualquer momento, alguém criará uma peça fundamental ou fundamental do seu aplicação, eu sugeriria que o responsável liderasse toda a equipe no design das classes, etc. para que, no final do dia, toda a equipe tenha que comprar a arquitetura geral do aplicativo. Além disso, se eles souberem como o código de outro membro da equipe funciona, será menos provável que o implementem novamente da maneira que funcionar para eles.

Você é o desenvolvedor sênior (ou um dos desenvolvedores sênior) dessa equipe? Nesse caso, parece que você precisa realizar alguns seminários de treinamento sobre as melhores práticas. Provavelmente, você deve reverter grande parte do trabalho realizado, realizar uma reunião com sua equipe e explicar a maneira correta de implementar a funcionalidade necessária de maneira a manter o design existente.

Como você está enfrentando um prazo apertado, pode ser necessário enviar o código como está e refatorar (reescrever?) Após o seu lançamento.

Também parece que você precisa definir e aplicar algumas práticas comuns de código. Você tem um processo de revisão de código em vigor no seu trabalho? Caso contrário, parece que agora é a hora de implementar uma. As revisões de código são, a propósito, uma ótima maneira de ensinar as melhores práticas para desenvolvedores mais recentes.

EDITAR:

Eu tive uma situação semelhante recentemente. A gerência da minha empresa insistiu em que usássemos desenvolvedores contratados para escrever grande parte de nosso aplicativo. O código que eles produziram foi péssimo (por assim dizer), mas fomos forçados a usá-lo. Hoje, reescrevi 80% do código que os contratados escreveram para nós. Estava cheio de bugs e impossível de estender com novos recursos. Em mais alguns meses, minha equipe terá reescrito tudo, tornando efetivamente um desperdício do dinheiro investido no desenvolvimento de contratos.

O código incorreto realmente custa dinheiro, é sobre isso que você pode querer conversar com seus gerentes, pois provavelmente precisará da ajuda deles para implementar e aplicar os padrões de codificação.

Você fez um esforço, mas o fato é que ninguém está no comando . "Mas eu prefiro o meu estilo de codificação", nada. Eu gostaria de trabalhar em meus projetos pessoais o dia todo e ainda ser pago.

Felizmente, você pode apresentar isso aos poderes existentes e mostrar a eles o que poderia ter sido feito em oposição ao Wild West Show, que durou duas semanas. Parece que você precisará obter algo fora da porta, mas continue acompanhando o problema da falta de controle e consistência.

Concentre-se nos poucos que acompanharam seu plano e faça o que puder para obtê-los para ajudar a consertar essa bagunça e colocá-los em sua equipe em projetos futuros. Você pode apenas ter que rejeitar o resto se eles não conseguirem ficar juntos.