👨🏽💻 Metodologia
A padronização de processos é um processo com uma função importantíssima para a Dump. Ela tem como objetivo normatizar e organizar fluxos de trabalho a fim de aumentar a produtividade e melhorar a interação entre projetos.
Isso se dá porque, quando não há um padrão, a tendência é que as equipes atuem de formas distintas, sem uma organização aparente. Desta forma, com o tempo, projetos comecem a ficar confusos, a troca de projetos e manutenção também são afetados pois acabamos levando mais tempo para localizar e intender certos fluxos.
Conforme você avançar por essa wiki, verá em vários momentos hiperlinks que vão apontar para leitura adicional do conteúdo falado, ou artigos relacionados. É importante ter em mente que esses conteúdos são complementares a essa documentação, logo, a leitura deles se torna imprescindível para entendimento completo do que esta sendo abordado. Um exemplo claro é o começo dessa introdução, que no caso contem um artigo sobre gestão de processos, texto do qual este foi baseado.
Usamos uma variação do Scrum para planejamento, organização e execução das tarefas. Nosso ciclo de desenvolvimento tem duração de uma semana, começando sempre após uma Sprint Planning onde organizamos e delegamos issues para cada colaborador. Planning essa que geralmente ocorre as segundas-feiras, dessa maneira conseguimos ter uma visão e planejamento do que é esperado ser entregue nos próximos sete dias.
As issues são categorizadas por tipo(feature, bug, debit) e priorizadas com o Negocio toda semana, issues que não entraram na sprint são mantidas no nosso Product Backlog onde serão reavaliadas para entrada na próxima sprint.
Hoje usamos o Jira como ferramenta para gerenciar nosso fluxo, para se aprofundar e entender mais nessas questões leia a nossa documentação sobre o 🔷 Jira, nela você vai conhecer e se familiarizar com os itens de trabalho, tipos e status das tarefas desenvolvidas.
A Dump tem dois repositórios principais de código, o Dump Tecnologia /dumptecnologia onde deixamos os projetos principais da empresa e dos clientes, e o The Dump Components /dump-components que usamos para pequenos pacotes de código a ser usados nos projetos principais. Essa divisão foi feita para não poluir o repositório principal com pequenos pacotes de apoio ou código de builds.
Hoje usamos o Github como serviço principal para armazenar nossos projetos.
Seguimos uma filosofia de Software Livre, pois utilizamos e ganhamos dinheiro com eles, logo, nada mais justo que nossos projetos de apoio ou imagens docker, por exemplo, possam ser usados e compartilhados com a comunidade. Projetos de clientes DEVE ser por padrão privado, exceções podem ocorrer caso a caso, mais tenha em mente que na criação de um projeto para algum cliente, o mesmo DEVE estar como privado nas configurações do repositório. Projetos de apoio, repositório de compartilhamento de pacotes ou imagens docker, DEVE estar como publico, incentivamos a qualquer um mandar seu PR e contribuir com melhorias, documentação e sugestão.
A ideia central por trás do Fluxo de trabalho de ramificação de recursos é que todo desenvolvimento de recursos deve ocorrer em uma ramificação dedicada em vez de na ramificação homolog. Esse encapsulamento facilita para vários desenvolvedores trabalharem em um recurso particular sem perturbar a base de código.
Encapsular o desenvolvimento de recursos também permite aproveitar solicitações pull, que são uma maneira de iniciar discussões em torno de uma branch. Eles dão a outros desenvolvedores a oportunidade de aprovar um recurso antes que ele seja integrado ao projeto oficial. Ou, se você ficar preso no meio de um recurso, vai poder abrir uma solicitação de recebimento pedindo sugestões de seus colegas. O ponto é que as solicitações pull tornam muito fácil para a equipe comentar sobre o trabalho um do outro.
Veja mais sobre esse assunto em github
O fluxo de trabalho da ramificação de recursos pressupõe um repositório central, e a ramificação homolog representa o histórico oficial do projeto. Em vez de fazer o commit direto na ramificação homolog local, os desenvolvedores criam uma nova ramificação sempre que começam a trabalhar em um novo recurso. As ramificações dos recursos serão sempre os mesmos nomes das issues criadas no jira, inclusive, na descrição de cada issue do jira contem um local chamado Criar branch, que permite copiar o comando completo git checkout -b FIPO-282-ambiente-de-homolog-nao-pode-fazer-as-tarefas-de-fato, você poderá usar isso diretamente no seu terminal do projeto. A ideia é dar um objetivo claro e bastante focado a cada ramificação. O Git não faz distinção técnica entre a ramificação homolog e as de recursos, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em uma ramificação de recurso.
Além disso, as ramificações de recursos podem (e devem) ser enviadas para o repositório central. Assim é possível compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial. Uma vez que a principal é a única ramificação “especial”, o armazenamento de várias ramificações de recursos no repositório central não apresenta problemas. Com certeza, essa também é uma maneira conveniente de fazer backup das commits locais de todos. A seguir, é apresentado um passo a passo do ciclo de vida de uma ramificação de recursos.
Todas as ramificações de recursos são criadas a partir do último estado de código de um projeto. Este guia pressupõe que a manutenção e a atualização disso sejam feitas na ramificação principal.
git checkout main git fetch origin git reset --hard origin/main
Essa ação muda o repositório para a ramificação principal, obtém os commits mais recentes e redefine a cópia local do repositório principal para corresponder à versão mais recente.
Use um branch separado para cada recurso ou problema em que você trabalha. Depois de criar um branch, verifique-o no local para que todas as alterações que você fizer sejam nesse branch.
git checkout -b new-feature
Essa ação verifica uma ramificação chamada new-feature com base na principal, e a marcação -b indica para o Git criar a ramificação, se ainda não existir.
Nesse branch, edite, prepare e faça os commits das alterações da maneira usual, construindo o recurso com o número de commits necessários. Trabalhe no recurso e faça commits como faria sempre que usa o Git. Quando estiver pronto, envie os commits, atualizando o branch de recursos no Bitbucket.
git status git add <some-file> git commit
É uma boa ideia enviar o branch do recurso para o repositório central. Isso serve como um backup conveniente, ao colaborar com outros desenvolvedores, e lhes daria acesso para visualizar commits para o novo branch.
git push -u origin new-feature
Esse comando envia a new-feature ao repositório central (origem) e a marcação -u o adiciona como uma ramificação de rastreamento remoto. Depois de configurar a ramificação de rastreamento, o git push pode ser solicitado sem nenhum parâmetro para enviar direto a ramificação new-feature ao repositório central. Para obter feedback sobre a ramificação de novo recurso, crie uma solicitação pull em uma solução de gerenciamento de repositório, como o Bitbucket Cloud ou o Bitbucket Data Center. A partir daí, você pode adicionar revisores e garantir que tudo esteja correto antes de fazer o merge.
Agora, os colegas de equipe comentam e aprovam os commits enviados. Esclareça seus comentários no local, faça o commit e envie as alterações sugeridas ao Bitbucket. As atualizações aparecem na solicitação pull.
Antes de fazer o merge, talvez seja necessário resolver conflitos de merge se outras pessoas fizerem alterações no repositório. Quando a solicitação pull é aprovada e não tem conflitos, você pode adicionar código à ramificação principal. Faça o merge a partir da solicitação pull no Bitbucket.
Além de isolar o desenvolvimento de recursos, as ramificações possibilitam discutir alterações por meio de solicitações pull. Quando alguém conclui um recurso, o merge na principal não é imediato. Em vez disso, a pessoa envia a ramificação de recursos ao servidor central e registra uma solicitação pull para fazer o merge das adições na principal. Assim os outros desenvolvedores têm a oportunidade de revisar as alterações antes que elas se tornem parte da base de código principal.
A revisão de código é um grande benefício das solicitações pull, mas elas foram projetadas para ser uma maneira genérica de falar sobre código. Você pode pensar em solicitações pull como uma discussão dedicada a um branch específico. Isso significa que eles também podem ser usados muito antes no processo de desenvolvimento. Por exemplo, se um desenvolvedor precisar de ajuda com um recurso específico, tudo o que precisa fazer é registrar uma solicitação pull. As partes interessadas vão ser notificadas direto e podem ver a pergunta ao lado dos commits relevantes.
Depois que uma solicitação pull é aceita, o ato real de publicar um recurso é quase o mesmo que no Fluxo de trabalho centralizado. Primeiro, você precisa garantir que a principal local esteja sincronizada com a principal upstream. Em seguida, você faz o merge da ramificação do recurso na principal e envia a principal atualizada de volta ao repositório central.
Solicitações pull podem ser facilitadas por soluções de gerenciamento de repositório de produtos, como o Bitbucket Cloud ou Bitbucket Server. Veja a documentação de solicitações pull do Bitbucket Server para ter um exemplo.
A seguir, é apresentado um exemplo do tipo de cenário no qual um fluxo de trabalho de branch de recurso é usado. O cenário é o de uma equipe fazendo uma revisão de código em uma solicitação pull de novo recurso. Este é um exemplo das muitas finalidades em que este modelo pode ser usado.
Antes de começar a desenvolver um recurso, Mary precisa de um branch isolado para trabalhar. Ela pode solicitar um novo branch com o seguinte comando:
git checkout -b marys-feature main
Essa ação verifica uma ramificação chamada marys-feature com base na principal, e a marcação -b diz ao Git para criar a ramificação, se ainda não existir. Nessa ramificação, Mary edita, prepara e faz commit das alterações da maneira normal, desenvolvendo seu recurso com o número de commits necessários:
git status git add <some-file> git commit
.svg?cdnVersion=549)
Mary adiciona algumas confirmações ao recurso ao longo da manhã. Antes de sair para almoçar, é uma boa ideia enviar o branch de recursos ao repositório central. É como um backup conveniente, mas se Mary estivesse colaborando com outros desenvolvedores, também possibilitaria o acesso deles a commits iniciais feitos por ela.
git push -u origin marys-feature
Este comando envia o marys-feature para o repositório central (origem), e a marcação -u o adiciona como uma ramificação de rastreamento remoto. Depois de configurar a ramificação de rastreamento, Mary pode solicitar o git push sem nenhum parâmetro para enviar seu recurso.
Quando Mary volta do almoço, ela conclui o recurso. Antes de fazer o merge na principal, ela precisa registrar uma solicitação pull informando o restante da equipe que ela terminou. Mas primeiro ela deve garantir que o repositório central tenha os commits mais recentes:
Git push
Em seguida, ela registra a solicitação pull na GUI do Git, solicitando o merge da marys-feature na principal, e os membros da equipe vão ser notificados direto. O melhor das solicitações pull é que elas mostram comentários ao lado dos commits relacionados, então é fácil fazer perguntas sobre conjuntos de alterações específicos.
.svg?cdnVersion=549)
Bill recebe a pull request e analisa o marys-feature. Ele decide se tem interesse em fazer algumas alterações antes de integrá-lo ao projeto oficial, e ele e Mary conversam sobre alterações por meio da da pull request.
.svg?cdnVersion=549)
Para fazer as alterações, Mary usa sempre o mesmo processo que usou para criar a primeira iteração de recurso. Ela edita, organiza, faz o commit e envia atualizações para o repositório central. Toda a atividade dela aparece na solicitação pull, e Bill ainda pode fazer comentários.
Se ele quisesse, Bill poderia enviar o marys-feature no repositório local e trabalhar sozinho. Quaisquer commits adicionados também apareceriam na pull request.
Quando Bill estiver pronto para aceitar a solicitação pull, alguém vai mesclar o recurso no projeto estável (isso pode ser feito por Bill ou Mary):
git checkout main git pull git pull origin marys-feature git push
Esse processo em geral resulta em um commit de merge. Alguns desenvolvedores gostam disso porque é como uma união simbólica do recurso com o restante da base do código. Mas, se você prefere um histórico linear, é possível fazer o rebase do recurso na extremidade da principal antes de executar o merge, resultando em um merge de avanço rápido.
Algumas GUIs automatizam o processo de aceitação de solicitação pull executando todos esses comandos apenas clicando no botão "Aceitar". Se não for o caso, ela deve pelo menos conseguir fechar direto a solicitação pull quando o merge da ramificação de recursos na principal for feito.
Enquanto isso, John está fazendo a mesma coisa
Enquanto Mary e Bill estão trabalhando no marys-feature e discutindo isso na solicitação pull, John está fazendo a mesma coisa com seu próprio branch de recursos. Ao isolar os recursos em branches separados, todos podem trabalhar com independência, mas ainda é essencial compartilhar alterações com outros desenvolvedores quando necessário.
Neste documento, discutimos o fluxo de trabalho do branch de recurso do Git. Esse fluxo de trabalho ajuda a organizar e rastrear branches focados nos conjuntos de recursos do domínio comercial. Outros fluxos de trabalho do Git, como o Git Forking Workflow e o Gitflow Workflow, são focados em repositórios e podem aproveitar o fluxo de trabalho do branch de recurso do Git para gerenciar modelos de branch. Este documento demonstrou um exemplo de código de alto nível e um exemplo fictício para implementar o fluxo de trabalho do branch de recurso no Git. Algumas associações importantes a serem feitas com o fluxo de trabalho do branch de recurso do Git são:
- focados nos padrões de ramificação
- podem ser aproveitados por outros fluxos de trabalho orientados para repositórios
- promove a colaboração com os membros da equipe por meio de pull requests e análises de mesclagem
Utilizar o git rebase durante os estágios de revisão e mesclagem de uma ramificação de recursos vai criar um histórico coeso do Git de mesclagens de recursos. Um modelo de ramificação de recursos é uma ótima ferramenta para promover a colaboração em um ambiente de equipe.
Vá mais fundo nos fluxos de trabalho do Git lendo o tutorial abrangente do Fluxo de trabalho Gitflow.
Aprenda a usar o Git com o Bitbucket Cloud | Atlassian Git Tutorial
setName(string name)Já em português:
-
setNome, mistura inglês com português. -
setarNome, neologismo na palavra setar. -
atribuirNome, um pouco grande de escrever/ler além de abrir espaço para certas variações (preencherNome,colocarNome, etc).
Além de outras vantagens (em inglês):
- Possibilidade de qualquer um (diferentes nacionalidades) trabalhar no seu código (essencial se open source).
- Fica bem mais coerente com os nomes das APIs/frameworks que você utilizará, que provavelmente estarão em inglês.
Enfim, no final das contas, escrever inglês é vantajoso em minha opnião. Mas para isso o resto da seu time tem que saber escrever/ler bem em inglês (para não ser mais uma dificuldade).
E claro, seja consistente. Assuma uma forma em seu projeto e a mantenha.
Uma forma simples e eficaz de melhorar a qualidade do seu código legado!
Enquanto trabalhamos em algum projeto, sempre acaba surgindo a necessidade de refatorar uma classe para melhorar seu design, até porque o código envelhece, então precisamos frequentemente melhorá-lo para que ele envelheça bem e não se torne um legado ruim. Logo, manter nosso código limpo é um desafio constante! O problema é que nós não temos tempo de sair refatorando nossas classes para garantir que o código está limpo.
Não limpar nosso código significa acumular uma dívida, um débito técnico, que algum dia será cobrado. Se esse débito crescer muito, então ficará quase impossível manter o código. Mas o que podemos fazer para reduzir esse débito técnico?
Para lidar com isso nós podemos seguir uma das regras dos escoteiros: sempre deixar o campo por onde estamos passando mais limpo do que quando o encontramos. Não precisamos limpar todo o lixo do campo, apenas deixar o campo um pouco mais limpo que antes. Se todos os escoteiros aplicarem essa boa prática, o campo irá se tornar muito mais limpo que antes. Isso também desenvolve um senso de coletivismo entre os escoteiros no qual todos passam a cuidar da qualidade do campo como um todo sem deixar a responsabilidade para apenas uma pessoa.
Bem, e porque devemos aplicar essa regra em nosso código mesmo? O fato é que em algum momento você vai ter que pagar esse débito técnico com refactoring (limpar toda o código sujo acumulado), aplicar a regra dos escoteiros fará com que esse trabalho não se acumule.
Sempre que você passar por uma classe para fazer alguma alteração, aproveite para aplicar algumas das técnicas de refactoring. Não precisa ser um refactoring grande! Você pode fazer refactorings simples como renomear uma variável, extrair um método de um método grande, remover código duplicado, separar as responsabilidades etc.
Aplicar apenas uma técnica de refactoring pode não fazer tanta diferença, mas se toda sua equipe seguir a regra do bom escoteiro, com certeza vocês terão um código mais limpo. Dessa forma você estará melhorando a qualidade do código da sua aplicação, porém sem atrasar as entregas por ter perdido o dia todo refatorando sozinho uma classe inteira.
Lembre-se: seu teste também é código. O código dos testes também precisa ser refatorado para manter sua qualidade e não acumular o débito técnico, logo, aplique essa mesma regra para todo o código, incluindo o código de testes!
E se a aplicação não possui testes ou tem uma cobertura baixa de testes, podemos considerar que aumentar a cobertura de testes é uma aplicação da regra do bom escoteiro.
O RFC reúne dezenas de publicações que documentam padrões, serviços, protocolos e outras informações técnicas oficiais da rede mundial de computadores. Os arquivos estão em poder da IETF, grupo internacional aberto composto por técnicos, agências, fabricantes e pesquisadores que ajudam no desenvolvimento dos padrões da internet.
Cada RFC deve detalhar o funcionamento de todos os aspectos do protocolo proposto. O RFC 3286, por exemplo, possui todas as especificações necessárias para a implementação do controle de fluxo de dados, permitindo a operação de plataformas de streaming como YouTube e Vimeo.
RFCs são documentos criados para especificar padrões técnicos da internet (Imagem: Priscilla Du Preez/Unsplash)
Os RFCs são atribuídos a um tipo específico de status de acordo com a padronização de seu respectivo protocolo. Alguns podem ser regionais e exclusivos de um país, enquanto outros possuem um padrão global que se aplica a todos. São eles:
- Informacional (Informational);
- Experimental;
- Melhor Prática Atual (Best Current Practice);
- Trilha dos Padrões (Standards Track);
- Proposto (Proposed Standard);
- Rascunho (Draft Standard);
- Padrão da Internet (Internet Standard);
- Histórico (Historic).
Os primeiros RFCs foram publicados em 1969. Muitos deles, como o HTTP e o DNS, chegaram bem depois do RFC1 (o primeiro Request for Comments), porém o formato padrão de texto dos documentos praticamente não foi alterado desde a criação do protocolo.
O número de um RFC é único e nunca é alterado. Se por algum motivo o padrão precisar de atualizações, então. IETF gera um novo RFC com melhorias, mas mantendo as características do modelo original.
Quando um novo arquivo é gerado, ele ganha o nome de Request for Change (pedido para mudança, no português). Caso seja aprovado pelo Comitê, esse documento se torna uma nova RFC, com uma numeração diferente da original que não é excluída.