# Squad LTM / Raízen

## Manifesto
[Pragmatismo mais que dogmatismo.](#Pragmatismo-mais-que-dogmatismo)
[Construir para necessidades do presente mais que para possibilidades do futuro.](#Construir-para-necessidades-do-presente-mais-que-para-possibilidades-do-futuro)
[Problemas de domínio mais que problemas de framework.](#Problemas-de-domínio-mais-que-problemas-de-framework)
[Abstrações de terceiros mais que abstrações próprias.](#Abstrações-de-terceiros-mais-que-abstrações-próprias)
[Design simples mais que design complexo.](#Design-simples-mais-que-design-complexo)
[Editável/Apagável mais que extensível.](#Editável/Apagável-mais-que-extensível)
[Sabedoria coletiva mais que heroísmo individual.](#Sabedoria-coletiva-mais-que-heroísmo-individual)
[Código para humanos mais que código para máquinas.](#Código-para-humanos-mais-que-código-para-máquinas)
[Atenção contínua à excelência técnica.](#Atenção-contínua-à-excelência-técnica)

### Explorando os valores

#### Pragmatismo mais que dogmatismo
Analisar de maneira pragmática se as ideias e soluções a serem adotadas condizem com a realidade do nosso projeto. Ter sempre o foco no nosso negócio, nos resultados desejados e no que o nosso time de desenvolvimento precisa. Não impor regras ou ideias de maneiras dogmáticas porque "alguém disse" ou porque "sempre foi feito assim".

#### Construir para necessidades do presente mais que para possibilidades do futuro
Focar apenas no que a sua história pede para ser feita. Ignorar tudo aquilo que possivelmente será usado no futuro. No futuro a abordagem pode ser outra e neste caso houve apenas tempo perdido. Isso não significa criar débito técnico para o futuro. Preservar a habilidade de mudança de direção é desejável.

#### Problemas de domínio mais que problemas de framework
Se você se encontra lutando contra seu framewotk em lugar de resolver problemas de trabalho, pode ter escolhido a tecnologia errada para desenvolver seu produto.

#### Abstrações de terceiros mais que abstrações próprias
Não perder tempo solucionando problemas que já foram solucionados anteriormente e na qual essa solução já foi bem testada em produção. Afinal, um time focado apenas em construir aquela abstração sempre tem um maior _background_ do que alguém sozinho. É sempre necessário verificar se essas abstrações de terceiros possuem suporte e continuam sendo evoluídas.

#### Design simples mais que design complexo
Menos é mais! Sempre tenha em mente que todos do time devem conseguir entender suas ideias. Adicionar complexidade desnecessária implica em aumentar o tempo de _debugging_ e refatoração de código, além de demandar uma maior preocupação introduzindo novos desenvolvedores ao time. _Um código que você não entende é um código que você não confia._

#### Editável/Apagável mais que extensível
Todo código é mutável e, eventualmente, até o mais robusto dos sistemas, exigirá manutenção. Implementar porções de código de fácil manutenção, permite que possíveis alterações não causem efeitos colaterais dispersos e imprevisíveis. Essa premissa endossa a importância do foco na qualidade do código, para que o mesmo, ao sofrer alterações, não se extenda, criando dependências em diversas partes do projeto, mas sim, apresente-se como suscetível a alterações e até remoção completa sem causar efeitos colaterais em nada que não possua relação direta com o método ou a classe alterada.

#### Sabedoria coletiva mais que heroísmo individual
Como desenvolvedores, tendemos a focar no problema sozinhos até resolvê-lo. Essa atitude geralmente resulta em desgaste, dificuldade na resolução e decisões incoerentes com o contexto geral do código. É preciso ser atento tanto a equipe de desenvolvimento, quanto a equipe de gestão, para recorrer sempre que necessário. Existem técnicas e abordagens que se fudamentam em desenvolvimento colaborativo, que se mostram extremamente valorosas e contribuem tanto para produtividade, quanto para qualidade do produto final, como Pair Programming, etapas de Scrum, e outros.

#### Código para humanos mais que código para máquinas
A maior parte do tempo de um desenvolvedor é gasto lendo código, debuggando código. Devemos ter isso em mente ao escrevermos software pois um código claro e preciso evita refatoração e manutenção no longo prazo. Existem camadas de abstrações entre nosso código-fonte e o código binário processado pela máquina, portanto esse código-fonte está mais próximos de nós desenvolvedores do que de fato dos processadores. Mais do que um conjunto de instruções para máquinhas, o código é uma forma de comunicação entre você e um outro desenvolvedor que lerá seu código no futuro - ou mesmo você no futuro. E caso seu código não comunique claramente o que ele faz e o porquê você escreveu daquela forma, esse é um código que provavelmente será refatorado, resultando em mais tempo perdido.

#### Atenção contínua à excelência técnica
O aperfeiçoamento contínuo propicia o aumento da qualidade, melhorias e eficiência no software.

---

## Processos, práticas e ferramentas

[Gitflow](#Gitflow)
[Pull Requests](#Pull-Requests)
[Code Review](#Code-Review)
[Pair Programming](#Pair-Programming)
[TDD](#TDD)
[DDD](#DDD)
[CDD](#CDD)
[CI](#CI)
[CD](#CD)
[Metodologias Ágeis](#Metodologias-Ágeis)
[Conceitos S.O.L.I.D](#Conceitos-S.O.L.I.D)
[Documentação de Código](#Documentação-de-Código)
[Padrões de Commit](#Padrões-de-Commit)
[Versionamento Semântico](#Versionamento-Semântico)
[API Design](#API-Design)
[Documentação Externa de API](Documentação-Externa-de-API)
[Gerenciamento de Dívida técnica](#Gerenciamento-de-Dívida-técnica)

### Gitflow
Modelo de _branching_ para o Git muito adequado para colaboração e _scaling_ da equipe de desenvolvimento.

[Saiba Mais](https://datasift.github.io/gitflow/IntroducingGitFlow.html)

### Pull Requests
Procedimento que informa para outros membros da equipe de desenvolvimento sobre as alterações das quais foi realizado o _push_ para um _branch_ em um repositório no Git. Depois que uma _pull request_ é aberta, é possível discutir, revisar as alterações e adicionar _commits_ de acompanhamento antes que as alterações sofram _merge_ no _branch_ base.

### Code Review (2 aprovadores)
É uma atividade de garantia de qualidade de _software_ (QA) na qual uma ou várias pessoas verificam um software por seu código-fonte, com o intuito de garantir uma melhor qualidade do mesmo, transferência de conhecimento, aumentar o senso de responsabilidade mútua e/ou garantir conformidade com as diretrizes de controle de qualidade.

[Saiba Mais](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/)

### Pair Programming
É uma técnica de desenvolvimento de software ágil na qual dois programadores trabalham juntos em uma estação de trabalho.

[Saiba Mais](https://en.wikipedia.org/wiki/Pair_programming)

### TDD
O TDD (_Test-driven Development_) é um processo de desenvolvimento de _software_ que se baseia na repetição de um ciclo de desenvolvimento muito curto onde os requisitos são transformados em casos de teste específicos, os quais posteriormente serão utilizados como base para a criação de código aprimorado.

[Saiba Mais](https://pt.wikipedia.org/wiki/Test-driven_development)

### DDD
O DDD (_Domain-driven design_) é uma abordagem para o desenvolvimento de _software_ para necessidades complexas, conectando profundamente a implementação a um modelo em evolução dos principais conceitos de negócios.

[Saiba Mais](https://en.wikipedia.org/wiki/Domain-driven_design)

### CDD
O Desenvolvimento Orientado a Componentes (CDD) é uma metodologia de desenvolvimento que ancora o processo de construção da UI em torno dos componentes. Iniciando no nível de componentes e finalizando no nível de páginas ou telas, criando interfaces de usuário de baixo para cima.

[Saiba Mais](https://blog.hichroma.com/component-driven-development-ce1109d56c8e)

### CI
A CI (_Continuous Integration_) é a prática de mesclar as _branches_ de trabalho de todos os desenvolvedores a uma _branch_ principal compartilhada.

[Saiba Mais](https://en.wikipedia.org/wiki/Continuous_integration)

### CD
A CD (_Continuous Delivery_) é uma extensão da _integração contínua_ para garantir que novas alterações sejam liberadas rapidamente, de forma sustentável. Na CD, além de automatizar os _testes_, o processo de liberação de versões também é automatizado.

[Saiba Mais](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)

### Metodologias Ágeis
Desenvolvimento Ágil de Software (_Agile software development_) ou Método ágil é uma disciplina que estuda um conjunto de comportamentos, processos, práticas e ferramentas utilizados para a criação de produtos e sua subsequente disponibilização para os usuários finais.

[Saiba mais](https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software)

### Conceitos S.O.L.I.D
Princípio de Responsabilidade Única, Princípio Aberto-Fechado, Princípio da substituição de Liskov, Princípio da Segregação da Interface e Princípio da inversão da Dependência.

[Saiba mais](https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa)

### Documentação de Código
Visto que a memória humana não é confiável suficiente para guardar todo o contexto envolto de uma funcionalidade, e que nem sempre conseguimos transmitir em códigos todo este contexto, uma boa documentação se faz mais do que necessário para o entendimento futuro de todo o projeto.

[Saiba mais](https://www.deepcoredata.com/4-reasons-need-good-internal-documentation/)

### Padrões de Commit
Com o propósito de melhorar a legibilidade do histórico de _commits_, existem várias convenções afim de padronizar as mensagens do mesmo. Sugiro a leitura dos dois documentos nos links abaixo.

Saiba mais: [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0-beta.4/), [Blog Locaweb](https://blog.locaweb.com.br/desenvolvedores/5-boas-praticas-de-git/)

### Versionamento Semântico
É um padrão que comunica o tipo de mudanças que é feita em cada release de um software. Procura comunicar claramente se as atualizações são correções de bug, novas funcionalidades ou _breaking changes_.

[Saiba mais](https://semver.org/)

### API Design
Afim de seguir boas práticas de desenvolvimento Web, utlizamos os padrões de Web Api da Microsoft.

[Saiba mais](https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design)

### Documentação Externa de API
Ao desenvolver uma estratégia de API é preciso proporcionar uma boa experiência aos usuários e desenvolvedores. O usuário vai precisar de informações acessíveis, claras e completas para que possa integrar algum sistema.

[Saiba mais](https://sensedia.com/api/conheca-6-dicas-para-melhorar-a-documentacao-de-api/)

### Gerenciamento de Dívida técnica
Dívida técnica é uma consequência inevitável do desenvolvimento de software, gerada por alguns fatores desde desconhecimento das melhores técnicas para solucionar um problema, até gambiarras intencionais "temporárias". Se não for monitorada e tratada, a dívida técnica pode resultar em desgaste crescente, comprometendo metas e a estrutura do projeto como um todo.

[Saiba mais](https://agilecoachninja.wordpress.com/2016/03/08/debito-tecnico-divida-tecnica/)