[Desenvolvimento] Princípios, boas práticas, chame do que quiser!
Acho que todo mundo aqui conhece princípios como DRY e YAGNI. A galera, depois que lê os livros do tio Bob, fica toda animada para usar esses termos, mas você tá ligado que existe uma porrada deles? Então, bora olhar mais alguns além desses super conhecidos. Bem, alguns desses princípios são meio contraditórios e podem rolar alguns conflitos, por isso muitas vezes temos que realizar um trade-off. Como sempre, veja o que se aplica melhor para seu caso!
Antes de tudo, vamos dar uma olhada nesses mais famosinhos só para ficar na mesma página.
- DRY (Don’t repeat yourself)
Cada parte “lógica” deve ser única, certeira e bem definida. Resumindo, evite duplicidade de código.
- YAGNI (You aren’t gonna need it)
Simples, se não vai usar, não implemente. Gaste energia com que realmente importa.
- KISS (Keep it simple, stupid)
Já pegando o embalo do DRY e YAGNI, mantenha as coisas simples (pequenos pedaços que quando juntos montam algo). Isso é muito interessante porque as vezes é bem difícil manter simples (em casos de performance, por exemplo) por isso nossa lista agora vai ganhar outro rumo.
Chega de siglas (talvez) e bora fazer a diferença.
- Do the simplest thing that could possibly work
Como a tradução já diz, faça as coisas da maneira mais simples para funcionar.
- Don’t make me think
Seu código tem que contar uma história, apenas lendo eu tenho que ser capaz de saber o que ele faz.
- Open/Closed Principle (OCP)
Suas classes, funções, componentes, módulos, entidades ou etc, tem que sempre estar disponíveis para serem estendidas, mas não modificadas.
- Write Code for the Maintainer
Outra tradução que já fala o que é, escreva o código para quem vai manter. Software é vivo e sempre terá manutenção.
- Principle of least astonishment
Basicamente mantenha seu código sem surpresas, exemplo: Se uma função para ler arquivos .txt, espero que ela só leia arquivos .txt, sem surpresas.
- Single Responsibility Principle (SRP)
Novamente, sua classe, função ou sei lá o que deve ter uma responsabilidade bem definida.
- Minimize Coupling
Diminua o coupling, mas e aí, o que é coupling? É (o inimigo comum) as dependências que seu código, classe, função ou sei lá carrega, é impossível um sistema não ter coupling, mas quando seu código tem muito “acoplamento”, sua manutenção começa a virar o caos em cada mudança que precisa ser feita.
- Maximize Cohesion
Funcionalidades parecidas devem estar umas próximas das outras.
- Abstraction Principle
Cada funcionalidade deve estar implementada em apenas um lugar no seu código (DRY?).
- Hide Implementation Details
Como já falado e repetido em outros princípios esconda os detalhes da implementação, eu não preciso saber que o método .sort() do Java implementa uma Quick Sort, porque se um dia mudar, ninguém vai sentir.
- Law of Demeter
Seu código (classe, função, etc) deve se comunicar apenas com códigos que tem uma direta relação (tipo uma classe com sua herança).
- Avoid Premature Optimization
Nossa vida é assim, a gente coda e no dia seguinte já vê algo para melhorar, mas cuidado, as vezes aquele 0,01 segundo que você ganhou a mais no render do seu site, deixou seu código uma caca.
- Code Reuse is Good
BEEEM controverso, reutilizar código as vezes é bom, pois dependendo do código já tem uma confiança nele e acelera bastante nosso desenvolvimento, mas não deixa de ser uma prática perigosa, já que precisamos ter a certeza que a aplicação daquela estrutura, lógica ou resultado se molda à nossa necessidade atual. A grande reutilização de códigos geralmente acaba criando "code smells" no sistema.
- Separation of Concerns
Novamente diferentes funcionalidades devem estar em lugares diferentes com o mínimo de sobreposição possível.
- Embrace Change
O mundo de desenvolvimento é ágil, se prepare para mudanças.
- Command Query Separation
Comando é o que faz algo, muda um estado ou faz uma ação. Query retorna algo, manter essa distinção te permite um mundo de possibilidades.
- Boy-Scout Rule
“Deixe o acampamento mais limpo do que você o encontrou”, isso se aplica muito quando você vai mexer em uma base de código já existente, se você vê coisas para melhorar, MELHORE!
- Composition Over Inheritance
É aquilo visando diminuir o acoplamento dê preferência a composição, evite herança.
- Orthogonality
Coisas que não são relacionadas conceitualmente não devem estar relacionadas no sistema. Mudanças no back-end não devem necessariamente vir juntas com mudanças no front-end, por exemplo.
- Robustness Principle
Quando temos interfaces bem definidas tudo é uma maravilha, mas quando essas interfaces começam a se estender precisamos manter nosso foco, nem sempre a extensão de uma interface vai pedir uma implementação direta de algum lugar por isso faça o que conheça com o mínimo de interrupção.
- Don't call us, we'll call you - ou mais conhecido como Inversion of Control (DIP)
Todas as partes de um software devem receber o fluxo de uma estrutura genérica. Mais precisamente: Um código de alto nível não pode depender de um baixo nível, devem depender da abstração.
- Liskov Substitution Principle (LSP)
Aqui cai muito em POO, pois é o polimorfismo, uma classe derivada deve ser substituível pela super classe (classe base, classe pai, etc).
- Curly's Law
Ter um objetivo claro e único em qualquer parte do código.
- Encapsulate What Changes
Mesma coisa que esconder a implementação, afinal encapsulamento é isso.
- Interface Segregation Principle (ISP)
Assim como classes, funções e afins, interfaces também precisam ser bem específicas, por isso é melhor criar várias interfaces do que uma grande e genérica.
Eita, hoje falamos pacas. Como deu pra reparar, eu só dei uma pincelada e vale muito a pena dar uma pesquisada mais profunda. Você que é um cara mais atento, percebeu que todos os princípios do SOLID estão aí (e merecem uma atenção maior). Provavelmente existem outros que não estão nessa lista, mas como ela inclusive já ficou meio repetitiva, a ideia de um “bom” código está bem esclarecida. De lição de casa, pegue cada item, dê uma googlada e comece já a incluí-los na sua vida.
Abraços!