Need help with pilares-design-codigo?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

asouza
144 Stars 15 Forks 62 Commits 3 Opened issues

Services available

!
?

Need anything else?

Contributors list

# 272,759
CSS
HTML
Shell
59 commits
# 174,700
Kotlin
audio-p...
Android
HTML
1 commit

Meus pilares para a criação de um código

  • A prioridade máxima é funcionar de acordo com o caso de uso. Beleza e formosura não dão pão nem fartura.

  • Execute o seu código o mais rápido possível. Estou falando de execução real, não de testes automatizados.

  • Protegemos as bordas do sistema como se não houvesse amanhã.

  • Quanto mais externa a borda, mais proteção temos.

  • Não retornamos nulo dentro das regras da aplicação. Pense que seu computador vai explodir.

  • Separamos as bordas externas do sistema do seu núcleo. Não ligamos parâmetros de requisição externa com objetos de domínio diretamente, assim como não serializamos objetos de domínio para respostas de API.

  • Avaliamos de forma lógica o nível de complicação de cada trecho de código. Aqui não tem espaço para feeling. Usamos a teoria da carga cognitiva e medimos o nível de pontos de entendimentos necessário por trecho. Uma leitura que explica melhor o assunto https://github.com/asouza/pilares-design-codigo/blob/master/ddd-da-massa.md

  • Toda indireção aumenta a dificuldade de entendimento da aplicação como um todo, ela precisa merecer existir. Ou seja, precisa ajudar a distribuir a carga intrínseca pelo sistema.

  • Usamos o construtor para criar o objeto no estado válido.

  • A complicação do nosso é código é proporcional a complicação da nossa feature. Quanto mais simples, melhor.

  • Usamos tudo que conhecemos que está pronto. Só fazemos código do zero se for estritamente necessário.

  • Idealmente, todo código escrito deveria ser chamado por alguém. Se não tem ninguém chamando, ele não deveria existir.

  • Só alteramos estado de referências que criamos. Não mexemos nos objetos alheios. A não ser que esse objeto seja criado para isso, como é o caso de argumentos de métodos de borda mais externa. Estes são, geralmente, associados a frameworks.

  • A versão mais eficiente de uma pessoa programando é aquela que entende, questiona e implementa estritamente o que foi combinado. Não inventamos coisas que não foram pedidas, não fazemos suposição de funcionalidade e nem caímos na armadilha de achar que entendemos mais do que a pessoa que solicitou a funcionalidade.

  • Você precisa entender o que está usando e olhar sempre o lado negativo de cada decisão.

  • Deixamos pistas que facilitem o uso do código onde não conseguimos resolver com compilação.

  • A sua api deve deixar claro o caminho que deve ser seguido pelo ponto do código que decide usá-la. Não espere que ninguém lembre de invocar nada. Faça de tudo para gerar obrigações. Quanto mais específico é seu código, menos democrático ele é.

  • Não usamos exception para controle de fluxo.

  • Regras de negócio devem ser declaradas de maneira explícita na nossa aplicação.

  • Favorecemos a coesão através do encapsulamento.

  • Criamos testes automatizados para que ele nos ajude a revelar e consertar bugs na aplicação.

Informações complementares

  • Diminua a complexidade do código observando a carga cognitiva dele - https://github.com/asouza/pilares-design-codigo/blob/master/design-orientado-a-carga-cognitiva.md
  • Um pouco da explicação sobre o meu quality profile do sonar - https://github.com/asouza/pilares-design-codigo/blob/master/quality-gate-deveficiente.md
  • Quality gate para seu projeto analisado pelo sonar - https://github.com/asouza/pilares-design-codigo/blob/master/sonar-rules-deveficiente.xml

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.