Melhorando a programação

Melhorando a programação

1. Boas práticas de codificação

   • Clareza
     • Facilita a leitura e compreensão do código melhorando a manutenção e debugging
       • Em vez de usar nomes de variáveis (como x ou y), é muito mais proveitoso usar nomes como velocidade ou distancia
   • Comentários
     • Preferir comentar blocos de código ou funções complexas em vez de cada linha
   • Evitar a duplicação desnecessária
   • Modularização
     • Dividir o código em métodos e classes menores, cada um com sua responsabilidade, permite que os desenvolvedores compreendam, testem e mantenham o código com muito mais facilidade
   • Preferir a composição à herança
     • Herança cria uma relação "é um" entre classes, onde uma classe filha herda atributos e métodos de uma classe pai. Porém, isso pode levar a estruturas rígidas e difíceis de modificar, especialmente em sistemas complexos
     • Composição, por outro lado, cria uma relação "tem um", permitindo que os objetos sejam construídos com base em pequenos componentes reutilizáveis. Isso facilita testes, manutenção e reaproveitamento de código, pois cada parte pode ser modificada ou substituída sem afetar toda a estrutura
   • Tipagem forte é uma das características mais poderosas do C#. Aproveitando‑se disso, deve‑se sempre preferir tipos explícitos em vez de var, exceto quando o tipo é óbvio a partir do contexto imediato
     • Isso torna o código mais legível e evita possíveis confusões sobre os tipos de variáveis usadas

2. SOLID

   • S - Princípio da Responsabilidade Única
     • Cada classe deve ter apenas uma responsabilidade e uma única razão para mudar
   • O - Princípio Aberto-Fechado
     • O código deve estar aberto para extensão, mas fechado para modificação
   • L - Princípio da Substituição de Liskov
     • Subclasses devem ser substituíveis pelas suas classes base sem quebrar o código
   • I - Princípio da Segregação de Interfaces
     • Interfaces devem ser pequenas e específicas, evitando métodos desnecessários
   • D - Princípio da Inversão de Dependência
     • O código deve depender de abstrações (interfaces), e não de implementações concretas

3. Design patterns

   • Os padrões de design são soluções reutilizáveis para problemas recorrentes no desenvolvimento de software, ajudando a criar sistemas robustos, escaláveis e fáceis de manter
     • Padrões Criacionais
       • Foco na criação de objetos
         • Singleton
           • Assegura que apenas uma instância da classe exista, evitando conflitos e inconsistências
     • Padrões Estruturais
       • Foco na organização e composição de classes e objetos
         • Adapter
           • Representa hierarquias de objetos, permitindo tratamento uniforme de elementos individuais e compostos
         • Composite
           • Permite que classes com interfaces incompatíveis trabalhem juntas

4. DRY

   • don’t repeat yourself
     • Não se repita
       • Incentiva desenvolvedores a reutilizar o código e evitar a duplicação desnecessária

5. KISS

   • keep it simple, stupid
     • Deixe simples, idiota
       • Prioriza um design simples e fácil de entender

6. YAGNI

   • you aren’t gonna need it
     • você não vai precisar disso
       • Evita a implementação de funcionalidades desnecessárias

7. Occam

   • Escolher a solução mais simples entre várias opções