Tecnologia / Artigos /
Diretrizes de Desenvolvimento

Cléber

![lighthouse.jpg](/files/180) *Photo by [Leif Christoph Gottwald](https://unsplash.com/@project2204) on [Unsplash](https://unsplash.com/s/photos/rules-list)* --- # Capítulo 1 1. Nenhum código entra na base sem code review. 1. Exceto boilerplate já bem conhecido. 1. Nenhum código vai direto para o galho-mestre. 1. Exceto arquivos de tradução. Arquivos de tradução jamais ficam em outros branches: é confusão. 1. Senhas, chaves e segredos jamais devem habitar o repositório de código. # Capítulo 2 1. Testes automatizados bem feitos ajudam a evitar regressão. 1. Nenhuma nova funcionalidade pode ir para o galho-mestre sem testes automatizados. 1. O galho-mestre deve ser sempre "deployable". # Capítulo 3 1. Todo desenvolvedor deve ler e entender [The Twelve Factor App](https://12factor.net/). 1. Nenhum projeto deve depender de pacotes "extravagantes" instalados no sistema operacional. Ou seja: deve ser possível executá-los normalmente sem permissões de *root*. 1. Exceto se isso for absolutamente necessário. 1. De qualquer maneira, sempre facilite a execução do projeto adicionando um Dockerfile adequado. # Capítulo 4 1. O domínio para testes ou mock deve sempre example.com ou example.org (eles existem para isso mesmo). 1. Jamais use "random" para preencher dados de teste. 1. Quando em dúvida para usar um nome de gente, use "John Doe". 1. Cuidado com repetições em valores usados nos testes. "11111" é um péssimo valor, pois programadores são como vampiros: ele perderão tempo contando os dígitos. E mesmo assim, confundirão em algum lugar com "111111", gerando testes que falham "inexplicavelmente". # Capítulo 5 1. O desenvolvedor deve entender a [Filosofia Unix](http://www.catb.org/esr/writings/taoup/html/philosophychapter.html). 1. A soma das partes é maior que o todo. 1. Faça apenas uma coisa, mas faça com perfeição. 1. Seus programas devem se comunicar via interfaces simples, de preferência via texto plano. 1. O tempo do programador é mais caro que o tempo do computador. 1. Clareza é melhor que esperteza. 1. Robustez é filha da clareza e da simplicidade. 1. Ao desenhar interfaces, sempre prefira a opção menos surpreendente. 1. Jamais silencie erros. Se for falhar, falhe o mais barulhentamente possível. 1. Faça funcionar antes de otimizar. 1. Programe para o futuro. # Capítulo 6 1. O desenvolvedor deve dominar o git. 1. Não existem "pull requests" no repositório. Isso é uma ilusão criada pelo github e ferramentas semelhantes. No git só existem commits. 1. Cada commit deve ser atômico. Cada commit deve entregar valor per si. 1. O desenvolvedor deve saber usar "git commit --amend" e "git rebase", no mínimo. # Capítulo 7 1. Tudo deve ser código. 1. Exceto configuração. 1. Todo código deve estar em um repositório de código. 1. Ou seja: tudo, exceto configuração, deve estar em repositórios de código.

Curti

32 visitantes curtiram esse Item.

Anterior: XFCE: quase como o Lada