Como funciona o trabalho em equipe (em um projeto OO)? [fechadas]

Estou programando em Java, no estilo OO, sozinho. Nunca tive a chance de trabalhar com outros programadores (pelo menos ainda não sou profissional).

Por curiosidade, eu queria perguntar: Como funciona o trabalho com uma equipe em um projeto, especialmente quando se trabalha em um projeto OO?

Como as tarefas de divisão funcionam? Como você desenvolve algo que funcionará com êxito com algo que outro programador desenvolveu? Como e quando os programadores se comunicam?

obrigado

Espero que eu possa ajudá-lo um pouco, ou pelo menos apontá-lo na direção certa!

Como um aviso, porém, é um tópico enorme - e realmente acho que é preciso " ser jogado " para se entender profundamente. Dito isto, vou dar uma olhada rápida nos dois principais problemas:

1. O controle de código e fonte
2. Comunicações e algumas dicas.

Em relação aos projetos de OOP especificamente - honestamente, não consigo ver muitos problemas específicos do OOP que não estão presentes em outros lugares.

Na verdade, acho que a programação no estilo OOP é incrivelmente adequada ao desenvolvimento da equipe. Um ethos chave do OOP é que eu não deveria conhecer todos os detalhes sobre todos os objetos com os quais interajo: só preciso saber o que ele pode fazer e como posso fazê-lo.

As abstrações que o OOP pode fornecer são impressionantes em uma equipe.

Fonte de controle

É preciso haver um local central para o projeto ser armazenado e um que permita que vários desenvolvedores acessem a base de código a qualquer momento. É aqui que sistemas como o Git (ou SVN) entram em cena.

Só posso falar especificamente sobre o Git, pois nunca usei o SVN - no entanto, acho que eles são semelhantes, mas com terminologia diferente.

Usando o Git, posso criar um repositório com todo o código-fonte para um determinado projeto e permitir que minha equipe acesse o repositório. Para cada recurso ou correção de bug que é feita, os desenvolvedores individuais podem criar sua própria "ramificação", o que significa que o desenvolvimento pode acontecer em trilhas paralelas.

Depois que um recurso ou correção é concluído, ele pode ser " mesclado " de volta à base de código do projeto principal. Qualquer " conflito " pode ser detectado pelo Git e resolvido no nível da fonte pelo desenvolvedor responsável.

Não tenho certeza se você já usou o Git antes, mas pode parecer bastante complexo no começo - mas graças à sua popularidade recente (em parte ao Github ), há toda uma riqueza de tutoriais e recursos por aí.

Se você ainda não o usou antes, recomendo que você se inscreva no GitHub e experimente dessa maneira! (Como alternativa, o Bitbucket é uma alternativa semelhante, mas permite que você tenha repositórios privados gratuitamente.)

O Git Flow é um excelente fluxo de trabalho baseado em Git, que é incrivelmente útil para as equipes. Como o Git em geral, quando você trabalha com ele por um tempo fica difícil imaginar trabalhar em equipe sem ele!

Comunicações

Depois de superar todas as barreiras técnicas, você realmente se depara com a questão fundamental que assola a maioria dos projetos (técnicos ou não) - e isso é comunicação.

Toda a equipe precisa estar ciente de quem está fazendo o que, quando está fazendo e o que isso afeta.

A responsabilidade precisa ser claramente definida

Isso é óbvio, mas a maioria dos projetos usa alguma forma de sistema de emissão de bilhetes - onde quaisquer solicitações ou bugs de recursos são registrados e, posteriormente, atribuídos a um membro específico da equipe. ( JIRA , Unfuddle , etc.) Geralmente, eles são incorporados ao sistema de controle de origem, o que torna a vida um pouco mais simples. (O BitBucket e o GitHub fornecem rastreamento de problemas para os repositórios Git hospedados com eles.)

Isso interrompe ou ajuda a impedir pelo menos que desenvolvedores trabalhem acidentalmente nos mesmos problemas.

Esta não é uma solução completa; você ainda precisa garantir que os desenvolvedores estejam cientes das responsabilidades de outros desenvolvedores. Sei no passado que corrigi outros problemas que encontrei no decorrer da correção de um bug específico, simplesmente porque faz sentido. (" Bem, eu já estou aqui. Isso poderia ser um refator e talvez eu possa verificar se há outros problemas. ") Então tive que me desculpar com outros desenvolvedores, pois eles estavam trabalhando nesses outros problemas que fixo - desperdiçando nosso tempo.

Em geral, esses problemas podem ser corrigidos por ...

Reuniões regulares

Algumas metodologias de gerenciamento / desenvolvimento de projetos determinam métodos de comunicação específicos ou intervalos de reunião. Em geral, os sistemas mais produtivos que eu vi foram as reuniões da manhã em que todos da equipe analisam rapidamente o que estão fazendo - se você limitar isso apenas aos membros da equipe de desenvolvimento e tiver diretrizes claras sobre o que comunicar, estes podem ser incrivelmente eficazes. Eu sempre tentei me ater a:

Estou trabalhando no X,

Para atingir / corrigir Y,

O que envolve a modificação / alteração de Z.

Outros membros da equipe podem perceber imediatamente que " Fergus está trabalhando para corrigir o bug que foi registrado no outro dia, no entanto, isso significa que ele está trabalhando em algum código que eu preciso examinar - vou verificar com ele antes de fazer alterações. "

Reuniões arquitetônicas

Recentemente, trabalhei com uma grande equipe que tinha um " bate-papo técnico " quinzenal , onde questões maiores / arquiteturais seriam discutidas. Todos os membros da equipe tiveram tempo de entender os problemas maiores enfrentados pelo projeto e puderam discutir possíveis correções.

Pessoalmente, adorei isso, não contribuí muito, pois era bastante novo no projeto - mas ser capaz de ouvir as discussões me deu muitas informações; logo eu pude entender o projeto e os estilos de pensamento individuais.

A comunicação é o único problema que pode derrubar qualquer equipe. Técnico ou não, se as pessoas não estão cientes do quadro geral, há uma chance maior de que elas falhem.

Outros problemas

É bom garantir que todos tenham a mesma configuração ou estilo ao trabalhar em equipe. O que eu quero dizer?

Configuração

Se você estiver trabalhando em um projeto Java - talvez seja uma boa idéia garantir (pelo menos para ambientes de desenvolvimento, certamente não para testes). As versões da JVM são comuns entre a equipe. Então IDEs. Isso ajuda principalmente se toda a equipe estiver usando Eclipse ou NetBeans ou seu IDE de sua escolha.

Em um projeto da Web, pode ser que todos os desenvolvedores precisem de uma pilha específica; com versões específicas do Apache ou PHP .

Pensar em fatores como esse apenas permite à equipe "gelar" um pouco mais rápido em minha mente.

Estilo

Abas vs espaços? CamelCase ou spacing_with_underscores? Por mais pequenas que sejam essas perguntas quando você está trabalhando sozinho, quando está trabalhando com uma equipe maior, realmente quer se esforçar para criar um estilo comum.

De fato, você não deve realmente saber quem escreveu uma seção específica do código - você deve saber apenas que ele pertence .

É por isso que muitos projetos de código aberto publicam abertamente diretrizes / guias de estilo de formato de código-fonte - para ter uma idéia do que eles contêm, dê uma olhada no Google StyleGuides para seus próprios projetos de código-fonte aberto.

Tarefas e testes de unidade

Isso não se limita às equipes, mas vou abordar rapidamente isso por uma razão em particular: facilita a vida da equipe.

Se você possui um fluxo de trabalho complexo com muitas dependências ou um processo de compilação longo - geralmente é útil automatizar isso usando um executor de tarefas. Para projetos web, o GruntJS é incrível, embora vindo do Java, acho que o Apache Ant possa ser bem parecido.

Como indivíduo, uso o GruntJS para criar meu site antes de implantá-lo no meu servidor FTP - basta um comando Grunt para que meu CSS / Sass seja compilado e minificado , que meus recursos sejam compactados e que meus arquivos sejam carregados.

Como membro da equipe, porém, posso usar o GruntJS para verificar se não fiz nenhum teste - e que não introduzi nenhum erro por não estar totalmente ciente de outras partes do projeto. Isso é claro, adicional aos benefícios que isso me proporciona como desenvolvedor individual.

Também posso usá-lo para clonar um projeto usando meu pacote de controle de origem extravagante (Git) - e executar um comando para instalar todas as minhas dependências. Essa é uma grande vantagem, pois o tempo gasto para colocar um novo desenvolvedor na posição em que ele pode realmente começar a desenvolver pode ser bastante grande - sem considerar o tempo necessário para se acostumar a uma base de código desconhecida.

Documentação

Os melhores projetos que eu já vi tiveram documentação (e muitas vezes bastante excessiva) destinada a desenvolvedores. Esse tipo de documento pode explicar coisas como:

1. O ambiente de desenvolvimento:

"No momento, estamos implantando em um servidor executando uma pilha LAMP , pois esses desenvolvedores devem ter como alvo as versões descritas em .."

2. Fluxo de trabalho

"Todos os recursos devem ser desenvolvidos em uma ramificação 'feature / *' e mesclados na ramificação 'testing' antes de serem considerados prontos para o lançamento."

3. Responsabilidades da equipe:

"Para problemas de banco de dados, fale com Steve. Para problemas de plataforma, fale com David."

4. Um " pipeline " para o futuro

"Ao desenvolver um novo código, lembre-se de que, em junho de 2014, desejamos implementar o código legado x talvez precise ser revisado antes que isso ocorra."

Exemplos

Pode valer a pena examinar o fluxo de trabalho de um projeto de código-fonte aberto para ter uma ideia de como ele funciona - seja um projeto estabelecido com seu próprio fluxo de trabalho (geralmente bastante documentado) ou um dos muitos exemplos no GitHub.

Uma palavra final de aviso

Se você se encontra trabalhando em uma equipe que consegue fazer tudo isso direito ... você odiará estar em qualquer outro lugar ..! Acredite em mim, uma vez que você tenha uma boa equipe, de repente problemas em outros lugares podem realmente arrastá-lo para baixo. (Essa é uma história para outro post, no entanto!)