Skip to content

👨🏽‍💻 Metodologia

Douglas Medeiros edited this page Jan 4, 2023 · 43 revisions

Essa pagina visa organizar e estruturar a metodologia de trabalho da Dump, de modo a documentar os padrões dos projetos e processos do dia a dia.

Introdução

A padronização de processos é um processo crucial para a Dump. É por meio dela que conseguimos organizar e normatizar nossos fluxos de trabalho, aumentando assim a produtividade e melhorando a interação entre projetos. Sem um padrão definido, as equipes podem acabar trabalhando de formas distintas, o que pode levar a projetos confusos e dificuldades na troca e manutenção deles.

Além disso, ao longo desta sessão, você encontrará hiperlinks que o direcionarão para conteúdos complementares e artigos relacionados. É importante lembrar que esses conteúdos são fundamentais para o entendimento completo do assunto abordado. Como exemplo, linkamos na introdução desta sessão, um artigo sobre gerenciamento de processos. Portanto, é recomendável a leitura desses materiais para um entendimento ainda mais profundo.



Fluxo de trabalho e dia a dia

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 e priorizadas com o negócio 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.

scrum-dark-theme



Repositórios dos Projetos

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.

Publico ou Privado?

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, privados, 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.



Trabalhando no repositório do projeto

Fluxo de trabalho de ramificação de recursos usando Git

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çãohomolog. 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 detalhes de como isso funciona na aba 🐙-Github



Código em Inglês x Português

Descrever certas ações em inglês é bem mais fácil, ex:

setName(string name)

Já em português:

  • setNome, mistura inglês com português.
  • setarNome, neologismo na palavrasetar.
  • 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.



A Regra do Bom Escoteiro

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 ocó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.



RFC

O que é um RFC?

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 comoYouTube e Vimeo.

RFCs são documentos criados para especificar padrões técnicos da internet (Imagem: Priscilla Du Preez/Unsplash)

Status de RFC

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

Exemplos de RFCs

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.

Novos e velhos RFCs

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 deRequest 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.



Style Code

Clone this wiki locally