A evolução na criação e manutenção de código fonte trouxe novas necessidades, como trabalhar em projetos mais complexos, maior volume de código, mais ferramentas, maiores times, segregação do código e projetos, dentre outros. É preciso ir além do simples controle de versão, é necessário gerenciar o código e também outras necessidades. O tema aborda o controle de versão e destaca como ir além no gerenciamento de projetos com código fonte.

Nas últimas décadas o desenvolvimento de software ganhou grande espaço no mundo profissional, o que antes era uma atividade restrita e totalmente técnica, agora ganhou novas dimensões e tornou necessário a busca por novos conhecimentos e habilidades que vão além da codificação.

Nesse contexto, um projeto com código fonte atualmente é mais do que apenas um diretório com arquivos e subdiretórios.

No passado, desenvolvedores(as) concentravam-se apenas em codificar em arquivos nas suas máquinas ou servidores, compilar, gerar um artefato publicável, verificar manualmente e minimamente se o sistema rodava e entregá-lo. Com o crescimento de times e novas necessidades, foi preciso um controle mais eficiente sobre o código fonte, e o controle de versão ganhou destaque passando a ser essencial. Ferramentas surgiram e evoluíram neste quesíto, e desenvolvedores(as) precisaram aprender a trabalhar com essas ferramentas.

Além do versionamento, o código fonte começou a ser organizado em projetos, cuja composição se tornou complexa, com múltiplos artefatos, muitas vezes com grande quantidade de arquivos e código, com múltiplas dependências, e cada vez mais compartilhado à um número maior de desenvolvedores(as), muitas vezes trabalhando fisicamente separados, estando em qualquer parte do mundo com idiomas e culturas diferentes.

Atualmente é necessário ir além do controle de versão. Desenvolvedores(as) profissionais precisam fazer o gerenciamento de projetos com código fonte!

Tal gerenciamento precisa possibilitar que times sejam ágeis, escaláveis e distribuídos. Desta forma, além de codificar e fazer uso de ferramentas de controle de versão, novas necessidades se fazem necessárias, como:

• Planejamento e controle das tarefas técnicas, incluindo visão de versões e entregas.
• Controle de qualidade de código.
• Controle sobre a geração e publicação dos artefatos gerados pelo projeto.
• Monitoramento do software para identificação e correção rápida de problemas.

Tais necessidades requerem mais conhecimento e disciplina, o tema apresenta na sequência questões relevantes e ferramentas que viabilizam esse gerenciamento, destacando pontos de atenção, boas práticas e outros assuntos relacionados que possuem um tema próprio no guia.

Organização do projeto

O termo projeto no contexto de código fonte ganhou força a partir do uso de IDE’s de desenvolvimento, e posteriormente por outras ferramentas que mantiveram o uso do termo para representar o diretório onde está o código fonte.

Este termo atualmente contempla o código fonte e também as necessidades citadas no tópico anterior, e para gerenciar um projeto o primeiro passo é organizar todos esses aspectos.

☛ Repositório

Sendo o projeto algo mais amplo, o termo repositório se tornou comum para referenciar o diretório com o código fonte e também indicar que o mesmo possui um controle de versão.

O repositório é o primeiro item e o mais importante a ser organizado, tanto que a organização do código, por ser um assunto amplo, é detalhada no guia através do tema Organização de Código Fonte. Já o controle de versão, é detalhado em um tópico na sequência deste tema.

A organização de um repositório influencia diretamente no gerenciamento do projeto, podendo simplificar coisas como:

• Localização de artefatos/código.
• Execução de testes e outras validações de qualidade.
• Geração, distribuição e execução do software.
• Versionamento com menos conflito entre códigos de vários desenvolvedores(as).

☛ Tarefas técnicas

O controle sobre os itens a serem implementados em um software é normalmente realizado através de Histórias, Casos de uso, dentre outros. Há várias abordagens e metodologias que direcionam como fazer tal controle, o qual normalmente é responsabilidade de outros papéis como Team Leader, Tech Leader, PO, PM, dentre outros.

Porém é comum que elas não foquem no detalhe técnico de como será implementado, o que pode tornar necessário a criação de tarefas técnicas. Uma história ou caso de uso pode inclusive gerar várias tarefas técnicas, as quais normalmente possuem 3 status: em aberto, em desenvolvimento, concluído.

Uma lista de tarefas com seus status é relevante para o gerenciamento do projeto. Quanto maior o projeto e os times que atuam sobre ele, mais necessário se torna este controle, e desenvolvedores(as) são responsáveis por manter a consistência deste controle.

Gerenciar tarefas técnicas contribui para:

• Tornar claro todas as implementações necessárias e planejadas.
• Definição de estratégias para a implementação do código.
• Registro e controle de dívidas técnicas e bugs.

Além das tarefas técnicas, é importante que exista uma visão das versões e entregas já realizadas e planejadas, o que auxilia na forma como o time se organiza para as futuras implementações assim como no rastreamento do que já foi concluído.

☛ Qualidade do código

Gerenciar o projeto inclui a atenção com a qualidade do código, o que inclui validar se as implementações realizadas atendem as necessidades de negócio, o uso de boas práticas de engenharia e se o código está bem escrito.

Há várias formas de validar qualidade, abaixo algumas boas práticas:

• Possuir testes automatizados que possam ser executados a cada implementação de código.
• Realizar de forma automatizada a análise estática do código.
• Realizar revisão de código, para que questões lógicas e de negócio possam ser validadas por mais pessoas do time.
• Realizar de forma controlada o merge de ramificações do código junto à linha principal de desenvolvimento.
• Realizar de forma automatizada verificações de vulnerabilidades de segurança e bugs.

☛ Geração e publicação do software

Há muitas formas para disponibilizar um software ao cliente, podendo ser através de:

• Execução em um servidor, no cliente ou em cloud.
• Execução no dispositivo do cliente, seja um computador ou celular.
• Disponibilização de uma biblioteca.

Independente da forma, é importante haver controle sobre esse processo. Ao gerenciar um projeto, deve-se poder controlar:

• Versionamento dos artefatos gerados.
• Publicação dos artefatos.
• Disponibilização de artefatos em versões anteriores.

☛ Monitoramento do software

Monitorar o software após implantação também faz parte do gerenciamento do projeto, afinal é código em execução e independente do ambiente, deve-se:

• Acompanhar o desempenho do software durante a execução.
• Identificar erros de execução do software, possibilitando visualizar o ponto exato e estado do software no momento do erro.
• Acompanhar o uso de novas funcionalidades ou melhorias.

---

Os aspectos apresentados fazem parte da rotina de times modernos de desenvolvimento. Desenvolvedores(as) profissionais precisam estar comprometidos com a organização do projeto.

Controle de versão

O controle de versão ainda é a principal necessidade de gerenciamento atribuída a desenvolvedores(as). Os sistemas de controle de versão, conhecido pela sigla VCS (Version Control System) ou ainda SCM (Source Code Management) permitiram um controle total sobre o histórico do código implementado e quais partes destes códigos podem ser entregues. Tais sistemas viabilizaram também à times de desenvolvimento a atuação de forma paralela na implementação de um mesmo software.

Muitas ferramentas de VCS surgiram no mercado, mas poucas ganharam status de dominante. A primeira ferramenta a dominar o mercado foi o CVS, sendo sucedida brevemente pelo SVN até a chegada do GIT.

Sendo um assunto bastante conhecido, o tema não o detalha por completo, recomendando se necessário materiais como:

• Tutorial sobre Controle de versão publicado pela Atlassian
• Capítulo sobre Controle de versão publicado junto a documentação oficial do GIT.
• Artigo sobre Controle de versão publicado na Wikipedia.

Em uma visão simplificada, um VCS permite:

• Controle e visão do histórico de modificações no repositório.
• Marcação e resgate de versões estáveis.
• Criação de ramificações do repositório.
• Controle de acesso sobre o repositório.
• Modificações paralelas de desenvolvedores(as) sobre o repositório.
• Armazenamento em repositório centralizado.
• Comparação de diferenças nas modificações.
• Merge de versões diferentes.

Conhecer e utilizar tais recursos e ferramentas é uma premissa para desenvolvedores(as) de software. Para quem não possui conhecimento neste assunto, os links citados acima são essenciais.

Mesmo o controle de versão sendo comum a maioria de desenvolvedores(as), há algumas dicas relacionadas a maus hábitos:

• Criar sempre uma ramificação para implementar o código, evitando modificações diretamente a linha principal de código.
• Sincronizar constantemente a ramificação com os novos códigos adicionados à linha principal, no mínimo diariamente.
• Enviar constantemente a ramificação para o repositório centralizado, perder código por problemas com o computador é amador.
• Quando houver conflitos na mesclagem de código, é preciso ter atenção para não descartar código que deveria continuar. Deve-se dialogar com as pessoas que implementaram o código envolvido no conflito.
• Modificar ramificações de outros desenvolvedores(as) sem envolvê-los não é algo legal. A forma certa de dialogar sobre melhorias ou outras formas de implementar é através da revisão de código.
• Todos são responsáveis pela linha principal de desenvolvimento, se ela estiver quebrada o time precisa priorizar a correção e depois analisar os motivos.

Tais dicas são aplicáveis a desenvolvedores(as) com qualquer nível de conhecimento e experiência, independente de liderança ou tempo de atuação no projeto. Fazer uso delas está acima do controle de versão e representa ter profissionalismo.

CVS e SVN

O CVS (Concurrent Versions System) se tornou a ferramenta de controle de versão dominante no mercado na década de 80, e ainda é utilizada por muitos times de desenvolvimento, embora não seja mais a ferramenta dominante.

Ela utiliza um modelo cliente-servidor, onde o servidor possui todas as versões e histórico das revisões e no cliente há uma cópia do projeto na versão ou ramificação desejada.

É uma ferramenta madura, com suporte na maioria dos editores e IDE’s. Sua arquitetura apresenta algumas limitações, como:

• Não rastreabilidade de ações como renomear e mover arquivos e diretórios executados na máquina cliente.
• Dependência do servidor para qualquer operação relacionada a consulta de histórico ou comparação de versões.
• Não possui suporte a operação atômica, o que possibilita problemas de conflito entre versões de código.

Mesmo sendo conhecida e estável, durante a década de 2000 ela passou a ser substituída em muitos projetos pela ferramenta SVN, que foi criada justamente focando em resolver as limitações existentes no CVS.

O SVN (SubVersion), criado pela Apache, teve sua versão inicial publicada em 2004, e trouxe algumas evoluções com relação ao CVS, destacando-se:

• Operações atômicas, que garante que dois processos concorrentes de merge não resultem em perda ou inconsistência de dados.
• Maior facilidade para trabalhar com ramificações.
• Operações para renomear e mover arquivos com histórico para rastreamento.

Além disso, SVN ganhou rapidamente um conjunto de plugins e ferramentas auxiliares, dentre elas uma forma mais fácil de visualização dos repositórios a partir da web.

Mesmo trazendo evoluções, o SVN seguiu uma arquitetura centralizada, o que em muitos casos se tornou um limitador para a escala no uso com grandes times. O SVN dominou brevemente, sendo sucedido pelo GIT.

GIT

O GIT, criado por Linus Torvalds no ano de 2005, nasceu em decorrência dos problemas que o time do Kernel do Linux teve com relação ao uso e acesso da ferramenta BitKeeper, que na época deixou de ter acesso gratuito. Para manter o controle de versão do Kernel, Torvalds desejava continuar a fazer uso de uma ferramenta gratuita, mas que também fosse similar ao BitKeeper com relação a ser distribuída e performática, algo que o CVS e SVN não eram.

Desta forma Torvalds decidiu criar uma ferramenta própria, gratuita e de código aberto. Logo ela foi adotada por diversos times no mundo e rapidamente caminhou para ser a ferramenta dominante no mercado.

Um destaque do GIT foi sua arquitetura distribuída que possibilitou maior escalabilidade para o uso por grandes times de desenvolvimento e seu modelo de ramificações que simplificou muito a forma como desenvolvedores(as) as utilizam.

Por ser distribuído, cada diretório Git é um repositório completo com todo histórico e revisões, não dependendo assim de um servidor central para obter tais informações. Além disso o GIT foi desenhado para facilitar que outros times pudessem criar outras interfaces sobre ele, o que se mostrou um dos diferenciais da ferramenta e alavancou seu uso no mundo, sendo hoje utilizado por diversas ferramentas como: GitHub, GitLab, BitBucket, dentre outras.

Os principais recursos do GIT podem ser vistos na sua página oficial, ou no site da Atlassian, o qual disponibiliza uma excelente documentação. O site oficial do GIT também disponibiliza uma documentação completa, oferecendo manual de referência, livros, vídeos e outros conteúdos. A qualidade da documentação também é um diferencial do GIT, e por este motivo o guia não apresenta maiores detalhes e sugere a leitura dos links apresentados.

GIT atualmente é a ferramenta referência para controle de versão, a ponto inclusive de ser utilizada não só para controle de versão de código fonte, mas também vários outros formatos de arquivos, incluindo binários.

Grande parte dos times modernos e ágeis de desenvolvimento utilizam o GIT, tanto pelos recursos já citados como também por ele facilitar a construção de fluxos de trabalho a partir de suas ramificações, os quais podem ser organizados para diferentes realidades e processos de times.

O guia recomenda fortemente o uso de GIT. Para times que utilizam outras ferramentas, há orientações para migração na documentação oficial.

Ferramentas de Gerenciamento

O GIT se tornou a ferramenta dominante no mercado para controle de versão, e um dos grandes acertos da ferramenta foi a forma como a mesma foi construída para facilitar a criação de outras ferramentas e interfaces integradas a ela.

Isso possibilitou o surgimento de ferramentas que foram além do controle de versão, viabilizando um amplo gerenciamento de projetos com código fonte, atendendo a todas as necessidades citadas nos tópicos iniciais com relação a organização e gerenciamento de um projeto.

Estas ferramentas dão grande poder para desenvolvedores(as) e são essenciais para que times possam, como já citado, ser ágeis, escaláveis e distribuídos.

Dentre as existentes, há várias propostas com relação a onde, como criar e manter projetos e repositórios. Algumas atuam em execução na máquina do cliente, outras em servidores na infraestrutura própria dos clientes (on-premisses). Já outras atuam como plataforma de hospedagem de projetos e repositórios na Cloud.

O guia detalha na sequência este último grupo, apresentando uma visão de seus recursos e como elas possibilitam o gerenciamento de projetos com código fonte.

GitHub

O GitHub, criado em 2008, foi um dos pioneiros com relação a esse tipo de ferramenta, embora em época já houvesse plataformas para hospedagem de repositórios como o SourceForge.

Inicialmente vista como uma ferramenta para projetos com código aberto, o GitHub cresceu rapidamente, agregando também recursos para projetos privados e construindo uma plataforma preparada para integrações com as mais diversas ferramentas relacionadas ao desenvolvimento de software.

O GitHub se tornou referência para hospedagem e gerenciamento de projetos, agregando através de seu marketplace a capacidade de ser a ferramenta central para os processos de CI/CD (Integração e Entrega Contínua). Em 2018 foi adquirida pela Microsoft, e hoje ostenta números como 35+ milhões de usuários e 100+ milhões de projetos.

Na sequência um resumo dos recursos que o GitHub oferece. É possível também ver todas as funcionalidades no site oficial.

☛ Planejamento e controle de tarefas

O GitHub foi uma das primeiras ferramentas a unir junto ao código fonte a visão de tarefas. A ferramenta oferece através da estrutura de Issues, Milestones e Projects todas as condições para viabilizar o controle de tarefas.

A funcionalidade de Pull Requests, também proporciona uma forma de organizar e entender quem está trabalhando sobre cada atividade e código, podendo estar integrada à visão de Issues.

Além dos recursos nativos na solução, o marketplace do GitHub oferece a possibilidade de integrar diversas ferramentas que oferecem recursos para planejamento e controle de tarefas, através das categorias: Project management, Utilities, dentre outras.

☛ Controle de qualidade de código

O GitHub popularizou o uso do recurso de PR’s (Pull Requests), onde desenvolvedores(as) podem trabalhar diversos aspectos relacionados à qualidade do código, destacando-se a possibilidade de Revisão de Código, com comentários, sugestões de modificações, aprovação ou reprovação.

É possível também junto aos PR’s fazer:

• Execução de testes automatizados.
• Análise estática de código.
• Verificação automática de Bugs.
• Verificação de vulnerabilidades de segurança.
• Verificação de atualizações de bibliotecas.
• Execução de checklists personalizados sobre qualidade do código.

Os resultados normalmente são exibidos de forma integrada ao site do GitHub.

Grande parte destes recursos não são nativos na solução, mas podem ser integrados através do marketplace do GitHub, através das categorias: Code quality, Code review, Code review, dentre outras.

☛ Controle e publicação de artefatos

Com o GitHub é possível:

• Controlar os artefatos gerados a partir de builds do projeto.
• Armazenar e publicar tais artefatos.
• Fazer a implantação do software.

Isso é possível através do uso de funcionalidades associadas ao recurso de Automation and CI/CD do GitHub, ou ainda através de integrações de ferramentas do marketplace do GitHub, através das categorias: Deployment, Publishing, dentre outras.

☛ Monitoramento do software

Por estar hospedado na web, é fácil realizar integrações de ferramentas de monitoramento do software junto ao código fonte do repositório. Isso possibilita que tais ferramentas indiquem e façam um link para o ponto exato do código onde estão ocorrendo problemas.

Alguns tipos de ferramentas possíveis:

• Identificação e rastreabilidade de erros.
• Monitoramento de performance.
• Acompanhamento de acesso.
• Visualização de Logs.

Outras possibilidades podem ser verificadas no marketplace do GitHub, através das categorias: Monitoring.

GitLab

O GitLab, criado em 2011, surgiu como uma alternativa ao GitHub trazendo a possibilidade de o mesmo ser utilizado de forma on-premisses, ou seja, em um servidor do próprio cliente, ou ainda na Cloud oferecendo o uso de projetos privados de forma gratuita.

A opção on-premisses, não atendida pelo GitHub, chamou atenção de um conjunto de clientes os quais desejam ou precisam ter seu código fonte “dentro de casa”, o que contribuiu para o crescimento da ferramenta.

O GitLab direcionou sua plataforma de uma forma diferente ao GitHub, trazendo para a própria solução a implementação de vários recursos associadas ao processo de desenvolvimento de software. Embora oferte um número menor de integrações com outras soluções, criou uma solução que proporciona uma usabilidade unificada entre todos os aspectos do gerenciamento do projeto.

Atualmente a solução se apresenta como uma plataforma completa para DevOps. Seu crescimento e adoção são consistentes nos últimos anos, somando atualmente números como 30+ milhões de usuários e 100+ mil repositórios.

Na sequência um resumo dos recursos que o Gitlab oferece, ou os recursos completos no site oficial.

☛ Planejamento e controle de tarefas

O GitLab oferece através da estrutura de Issues, Milestones e Boards todas as condições para viabilizar o controle de tarefas de um projeto. Atuando de forma mais integrada ao repositório, é possível configurar a ferramenta para trabalhar com metodologias ágeis como Scrum e Kanban.

Assim como o GitHub, o GitLab trabalha com o conceito de Pull Requests, porém a ferramenta dá o nome de Merge Request essa funcionalidade, mas mantendo as mesmas características.

As Issues no GitLab dão o suporte nativamente para criação de Merge Request e Feature Branches, assunto detalhado no tema Fluxos de trabalho.

☛ Controle de qualidade de código

O GitLab possibilita a Revisão de Código através do uso de Merge Requests, com as mesmas características existentes no GitHub. Destaca-se a opção nativa de trabalhar com um número maior de aprovações de código para times que desejam submeter a revisão a mais desenvolvedores(as).

Merges Requests possibilitam as mesmas ações que o GitHub permite como: testes automatizados, Análise estática de código, verificação de bugs, vulnerabilidades de segurança, atualizações de bibliotecas e checklists personalizados, e também exibindo os resultados de forma integrada ao site.

☛ Controle e publicação de artefatos

Com o GitLab é possível atuar de forma semelhante ao GitHub, controlando, armazenando e publicando os artefatos gerados, mas destacando-se uma solução própria para registro e armazenamento de artefatos e containers.

Também há suporte para implantação dos artefatos, incluindo a integração nativa com Kubernates.

☛ Monitoramento do software

Possibilita os mesmos recursos que o GitHub, através da integração de ferramentas de monitoramento cobrindo erros, performance, acesso, logs.

Além das integrações, a própria ferramenta possui funcionalidades nativas que atendem aos itens descritos acima.

BitBucket

O BitBucket é uma ferramenta criada pela Atlassian, a qual é o resultado de várias tentativas da empresa de oferecer soluções para gerenciamento de projetos e repositórios.

A ferramenta utilizava inicialmente como solução para controle de versão a ferramenta Mercurial, mas hoje utiliza também o GIT. A ferramenta é disponibilizada no modelo em Cloud e também com a possibilidade de uso em Data Center gerenciado pelo cliente.

A ferramenta se apresenta como uma solução para gestão de projetos que inclui toda a expertise de soluções como Jira e Trello, além de incluir recursos para os processos de CI/CD (Integração e Entrega Contínua). Em geral o BitBucket possui um conjunto de clientes importantes no mercado, mas é um ferramenta com menos recursos que seus concorrentes GitHub e GitLab.

Na sequência um resumo dos recursos que o BitBucket oferece, ou os recursos completos no site oficial.

☛ Planejamento e controle de tarefas

O BitBucket utiliza o Jira ou Trello como solução para controle de tarefas, o que dá um grande poder para gestão de Issues e Milestones através de Boards que possibilitam trabalhar com metodologias ágeis como Scrum e Kanban.

Assim como o GitHub, o BitBucket trabalha com o conceito de Pull Requests, que também proporciona uma forma de organizar e entender quem está trabalhando sobre cada atividade e código, podendo inclusive estar integrado à visão de Issues.

☛ Controle de qualidade de código

O BitBucket possibilita a Revisão de Código através do uso de Pull Requests, semelhante ao GitHub.

Pull Requests possibilitam as ações de testes automatizados, Análise estática de código, verificação de bugs, vulnerabilidades de segurança, atualizações de bibliotecas e checklists personalizados que o GitHub permite, porém não conta com um suporte adequado para exibição dos resultados de cada item descrito acima. É possível fazer a visualização do resultado no site, porém é o resultado da execução via console.

☛ Controle e publicação de artefatos

Com o BitBucket é possível atuar de forma semelhante ao GitHub, controlando, armazenando e publicando os artefatos gerados, porém sempre através do uso de outras ferramentas, e sem integração direta ao Bitbucket. A utilização destes recursos se dá através de ações no processo de Build/CI.

☛ Monitoramento do software

Possibilita os mesmos recursos que o GitHub, através da integração de ferramentas de monitoramento cobrindo erros, performance, acesso, logs.

Visibilidade

Todo bom modelo de gerenciamento, nas mais diversas áreas, possui como virtude a visibilidade. Essa característica é essencial para que os(as) demais integrantes de um projeto ou empresa possam ver, entender e participar da gestão.

Em projetos com código fonte, há muitos detalhes que podem ser visíveis a todos, como:

• Versões e entregas: Disponibilizar a lista das planejadas e últimas realizadas.
• Tarefas: Um painel ou lista das tarefas em andamento, últimas finalizadas e próximas a serem realizadas, tornando visível a evolução do projeto e times.
• Pull/Merge Requests: As tarefas indicam a intenção, já o uso de Pull/Merge Requests torna público a dinâmica de implementação de código, as estratégias adotadas, o debate entre desenvolvedores(as), dentre outros.
• Relatório com status e cobertura de testes automatizados: Relevante para que rapidamente possa ser verificado os testes casos estes estejam quebrados, além de explicitar o comprometimento do time com a qualidade do software se este buscar elevados índices de cobertura.
• Relatório de análise estática do código: Torna público se o código fonte está bem escrito. Em casos onde há grande número de problemas, não deve ser considerado demérito, mas sim a explicitação de que desenvolvedores(as) precisam investir mais tempo na melhoria do código.
• Relatório de vulnerabilidades de segurança: Permite a atenção aos aspectos de segurança o mais rápido possível, e não apenas quando problemas ocorrem.
• Geração e Publicação de artefatos: Contribui para organização, acompanhamento e execução do processo de implantação. Quando o código fonte é referente a bibliotecas, essa informação se torna mais valiosa ainda.
• Implantação: Relevante para informar se o software foi atualizado e está liberado para uso. Isso pode incluir data/hora da atualização, status e informações com relação aos ambientes atualizados e como acessá-los.
• Monitoramento: Acompanhar a execução do software em tempo real se tornou algo essencial em um cenário profissional de desenvolvimento, logo é relevante disponibilizar dados referentes aos recursos utilizados pelo software e também métricas de negócio que indiquem que as funcionalidades do software estão operando corretamente.

Manter, organizar e tornar visível tais informações só é possível quando desenvolvedores(as) vão além da codificação e controle de versão, e mesmo que existam papéis focados em gerenciar todos estes aspectos, é responsabilidade de todos compreenderem e contribuírem para tal.

Em muitos casos a “cobrança” por estas informações é vista como uma forma de microgerenciamento, ou ainda como burocracia. Porém no contexto profissional, é este gerenciamento e informações que possibilitam o entendimento da saúde do projeto, do repositório e também do time.

Deve-se também tornar visível os próprios projetos existentes, ou seja, possibilitar que todos integrantes da empresa possam ver os projetos com código fonte. Isso não implica em liberar o acesso total para qualquer ação, mas apenas tornar os projetos visíveis, e configurar permissões através de mecanismos de controle de acesso e segurança.

A forma para apresentar tais informações pode variar bastante de acordo com as ferramentas utilizadas, mas há algumas boas práticas:

• Disponibilizar tais informações na web, seja em ambiente público ou privado. O importante é que sempre exista um link para que tais informações possam ser acessadas.
• Centralizar o máximo de informações possíveis. Podendo ser através das ferramentas já citadas ou ainda outras complementares como:
  • Source Level
  • Code Climate
  • Sonar Qube
  • Codacy
• Utilizar o README do projeto como porta de acesso fazendo o link a todas essas informações.

Dar visibilidade da organização do projeto é o que consolida um bom gerenciamento, além de estimular demais desenvolvedores(as) a seguirem o mesmo caminho.

Rotatividade de Devs

Atualmente a rotatividade de desenvolvedores(as) em times é alta, seja por movimentações internas em uma empresa, ou a saída e chegada novos(as). Isso reforça a importância do gerenciamento de projeto com código fonte.

Em times e projetos profissionais, desenvolvedores(as) que estão chegando dificilmente irão chegar e já iniciar modificando o código fonte. É necessário que estes recebam orientações e informações sobre o que é código, onde está e como proceder para começar a “botar a mão na massa”.

Em projetos onde não há uma preocupação em gerenciar o código fonte, normalmente esse período inicial será conturbado, lento e obscuro. É comum que muitas perguntas sejam feitas, muitas sem resposta, e que o tempo de várias pessoas seja utilizado para viabilizar que novos(as) integrantes possam trabalhar.

Um projeto bem gerenciado irá ajudar em todo este processo, tornando claro todas as informações para quem está chegando. Para isso é indicado:

• Ter no README do projeto todas informações relacionadas ao mesmo, conforme apresentado no tema Documentação Técnica. A nova pessoa poderá a partir do README entender o máximo possível sem utilizar tempo de outras pessoas.
• Dar acesso aos projetos e facilitar que as novas pessoas naveguem por eles.
• Estimular para que caso algo não esteja bem organizado, documentado ou visível, as novas pessoas sinalizem isto e inclusive contribuam para melhorias se possível.

A rotatividade é inevitável, já o tempo gasto em cada saída ou chegada de pessoas no projeto, pode ser minimizado a partir do gerenciamento do projeto com código fonte. Quanto mais projetos existirem, mais este gerenciamento pode contribuir.