Como você rastreia quais classes e funções sua equipe escreveu?

Bibliotecas. Frameworks. Controle de versão.

Se você tiver um código reutilizável, a última coisa que deseja é que os diferentes membros da equipe copiem o código-fonte em seu projeto. Se eles fizerem isso, é provável que eles mudem um pouco aqui e ajustem um pouco lá, e em breve você terá dezenas de funções ou métodos que têm o mesmo nome, mas que funcionam um pouco de forma diferente. Ou, talvez mais provavelmente, o autor original continuará a refinar o código para corrigir bugs, torná-lo mais eficiente ou adicionar recursos, mas o código copiado nunca será atualizado. O nome técnico para isso é uma grande bagunça .

A solução certa é extrair esse material reutilizável de qualquer projeto para o qual você o construiu e colocá-lo em uma biblioteca ou estrutura em seu próprio repositório de controle de versão. Isso facilita a localização, mas também desestimula a realização de alterações sem considerar todos os outros projetos que possam estar sendo usados. Você pode considerar ter várias bibliotecas diferentes: uma para código bem testado que não é mais provável de mudar, uma para coisas que parecem estáveis, mas que não foram completamente testadas e revisadas, uma para adições propostas.

Uma abordagem para isso é a criação de um Wiki para essa finalidade e escrever alguns documentos de alto nível sobre quais componentes reutilizáveis você tem, como você resolveu um problema, etc.

A parte difícil é fazer com que todos em sua equipe mantenham esse Wiki constantemente. Mas qualquer outro tipo de documentação sofre do mesmo problema.

Alguns dos seus códigos também podem ser bons o suficiente para serem colocados em uma biblioteca reutilizável. Isso também torna mais fácil encontrar o código novamente mais tarde.

Estar em uma empresa com 700 funcionários, com equipes que variam entre 2 e 20 pessoas, eis a minha experiência.

No nível da equipe

Temos "reuniões em pé" todos os dias por cerca de 15 a 20 minutos. Podemos compartilhar rapidamente conhecimentos comuns como "Eu fiz essa função ontem, é tão difícil".

Também temos um wiki por projeto. O que significa que podemos compartilhar informações (técnicas) sobre o que é feito no projeto, incluindo classes / funções personalizadas que foram incorporadas.

No nível da agência

No nível de agência, temos quatro ferramentas:

• Outro wiki. Ele está principalmente lá para nos fornecer informações sobre hardware e outras coisas, mas às vezes usamos isso para compartilhar informações técnicas a serem analisadas antes de colocá-las no nível da empresa.
• Reuniões semanais. Eles são principalmente para conhecer o progresso de cada equipe / projeto, mas já que somos principalmente entusiastas de tecnologia, podemos trazer coisas legais.
• Mailing list. Temos uma correspondência com todos na agência. Muita coisa legal / coisas divertidas / coisas úteis passam por lá.
• repositório VCS. Cada agência tem seu repositório pessoal, onde temos pequenos projetos, principalmente módulos que usamos em diferentes projetos.

No nível da empresa

No nível da empresa, é mais organizado.

O wiki "agency level" é, na verdade, parte do wiki da empresa.

E o wiki é dividido com base em tecnologias. Assim, qualquer um pode melhorá-lo, pesquisá-lo e basicamente dar uma vida ao wiki.

Também há listas de discussão disponíveis para as quais podemos nos inscrever. Qualquer pessoa na agência pode se inscrever, e a maioria das pessoas segue pelo menos uma ou duas tecnologias, na verdade, a maioria das pessoas segue de 5 a 10 delas.

E o VCS é, obviamente, o melhor sistema de compartilhamento de código.

Conclusão

Para resumir, não há solução clara. O compartilhamento de conhecimento sempre foi um grande problema e provavelmente permanecerá. Existem muitas soluções para criar bases de conhecimento , e provavelmente uma delas poderia se encaixar na sua conta. No entanto, algumas pessoas estão tentando melhorar ainda mais a KB, já que as soluções atuais nem sempre são muito inteligentes.

/ p>     

Bem, tudo se resume à comunicação.

Os Wiki's são ótimos e você deve definitivamente instalar e usar um. Uma boa intranet de programadores internos é boa se as pessoas a lerem e atualizarem, então você está realmente falando sobre um problema de pessoas lá. Você poderia sugerir reuniões semanais de "atualização de equipe", onde todos se reúnem e dá uma visão geral do trabalho que está sendo realizado. Os líderes da tecnologia (pelo menos!) Devem estar se reunindo e conversando sobre o que cada equipe está fazendo. As sessões informais "Brown Bag" são ótimas, agende-as na hora do almoço e faça as pessoas conversarem.

Você também precisa compartilhar um código, empacotá-lo, versioná-lo e distribuí-lo. As coisas seriam mais fáceis se você tivesse um repositório de código-fonte bem gerenciado, bem organizado em pastas "comuns" e de projetos.

Se nada como isso está sendo feito, traga isso para o seu chefe, explique como ele irá beneficiar a empresa e sugira um caminho a seguir:)

As sessões de revisão de código podem ajudar. Se sua equipe se reúne regularmente para discutir o que foi desenvolvido, a pessoa que apresentou uma solução pode mostrar aos outros como usá-la. Se alguém menciona um ponto em que está se mantendo, outros membros da equipe podem propor uma abordagem que aumente a reutilização dos componentes existentes.

A melhor maneira de lidar com algo assim é ter uma estrutura de repositório que tenha algumas convenções simples para que eu saiba, como programador, se existe uma função doXYZ , aproximadamente onde devo procurar essa função. Independentemente de você estar usando namespaces, diretórios, módulos, plug-ins, pacotes, seja o que for, seu código deve ser modular para que as funções que fazem a mesma coisa ou acessem as mesmas origens de dados estejam no mesmo ponto.

Idealmente, deve haver pelo menos uma outra pessoa além do autor fazendo uma revisão de código em cada check-in. O processo de revisão de código pode ajudar a reduzir o problema de muitos métodos duplicados sendo verificados. É claro que você está limitado pelo conhecimento dos revisores.

TL; DR: revisões de código para cada check-in.