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

43

Ao trabalhar com código, enfrento muitos dos mesmos desafios que meus colegas de equipe e escrevi algumas funções e classes úteis, e assim também eles. Se houver uma boa comunicação, ouvirei falar de uma grande coisa que alguém reuniu e, seis meses depois, quando eu precisar, posso lembrar e chamar essa função, economizando tempo. Se eu não me lembrar disso, ou nunca soube disso, provavelmente reinventarei a roda.

Existe uma prática específica de documentar esse tipo de coisa? Como você facilita a localização?

Se a sua equipe não tiver essa documentação, como descobrir se a sua roda já existe?

EDITAR:

Todas as respostas, exceto uma, até agora tratam de uma situação ideal, portanto, deixe-me resumir essas soluções: documentation & comunicação; wikis, reuniões de stand-up, etc. Essas são todas grandes coisas, mas elas dependem que os programadores tenham tempo (e habilidades) para redigir a documentação e participar das reuniões, tomar notas e lembrar de tudo.

A resposta mais popular até agora (a de Caleb) é a única que pode ser usada por um programador incapaz de documentação e reuniões, e faz apenas uma coisa: programar. Programação é o que um programador faz, e sim, um ótimo programador pode escrever documentação, testes de unidade, etc., mas vamos encarar - a maioria de nós prefere programar para documentar. Sua solução é aquela em que o programador reconhece o código reutilizável e o puxa para sua própria classe ou repositório ou o que quer que seja, e pelo fato de estar isolado, torna-se localizável e facilita o aprendizado curva para usá-lo .... e isso foi realizado por programação.

De certa forma eu vejo assim: Acabei de escrever três funções, e me ocorre que alguém deveria saber sobre elas. Eu poderia documentá-los, escrevê-los, anunciá-los em uma reunião, etc. - o que eu posso fazer, mas não é minha força - ou ... posso extraí-los para uma classe, nomeá-los bem, fazê-los funcionar como uma caixa preta e cole-a onde vão os outros arquivos de classe. Então, um pequeno e-mail anunciando é fácil. Outros desenvolvedores podem escanear o código e entendê-lo melhor do que poderiam usar uma função isolada usada em código que não entendem completamente - esse contexto é removido.

Eu gosto disso porque significa ter um conjunto de arquivos de classe bem nomeados, com métodos bem nomeados, é uma boa solução que é realizada por uma boa programação. Não requer reuniões e suaviza a necessidade de documentação detalhada.

Existe mais alguma idéia nesse sentido ... para desenvolvedores isolados e pressionados pelo tempo?

    
por changokun 30.04.2013 / 16:37
fonte

7 respostas

29

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.

    
por 30.04.2013 / 17:12
fonte
13

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.

    
por 30.04.2013 / 16:51
fonte
7

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>     

por 30.04.2013 / 17:21
fonte
6

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:)

    
por 30.04.2013 / 17:13
fonte
4

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.

    
por 30.04.2013 / 17:07
fonte
2

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.

    
por 30.04.2013 / 17:17
fonte
0

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.

    
por 30.04.2013 / 22:09
fonte