Um resumo prático da teoria de Robert C. Martin - o Uncle Bob - sobre as boas práticas e padrões para projetos de software sustentáveis. “ Aprender a criar códigos limpos é uma tarefa árdua e requer mais do que o simples conhecimento dos princípios e padrões. Você deve suar a camisa; praticar sozinho e ver que cometeu erros; assistir os outros praticarem e errarem; vê-los tropeçar e refazer seus passos; Vê-los agonizar para tomar decisões e o preço que pagarão por as terem tomado da maneira errada. ” Robert C. Martin, em seu livro: “Clean Code: A Handbook of Agile Software Craftsmanship” Um software deve ser sempre desenvolvido de maneira a ser organizado, padronizado, legível, testável e escalável. É um ativo intangível de grande valor em qualquer empresa e por isso merece bastante atenção. Dentro disso, muito se fala sobre padrões de projetos de software, princípios e boas práticas de desenvolvimento e manutenção. E quando esse é o assunto, fica difícil não citar Clean Code ou os princípios SOLID. Recentemente eu desenvolvi um documento descrevendo os padrões de projeto a serem seguidos na empresa onde eu trabalho, a GIRA, para orientar a equipe de desenvolvimento. Mas no início de tudo tive de citar de onde vinham os conceitos que estavam sendo aplicados como fundamentos. Assim me peguei fazendo um resumo sobre o assunto, e resolvi aproveitar a abordagem feita. Recortei a parte genérica e disponibilizei nesse artigo como um resumo prático sobre arquitetura de software. 1. Clean Code O Clean Code é um conjunto de boas práticas aplicáveis em qualquer projeto de software. Seu objetivo principal é aumentar a legibilidade do código, já que passamos muito mais tempo lendo do que escrevendo. É deixar o código fácil de ser manutenido e menos propenso a erros humanos e bugs. 1.1. Siga as Convenções Todo projeto possui suas convenções e padrões. Não se trata do que é melhor ou pior, mas sim de se seguir um padrão definido. 1.2. KISS Keep It Simple & Stupid: a simplicidade é a maior das sofisticações. 1.3. Regra do Escoteiro Sempre deixe o acampamento melhor do que quando você chegou. Sempre que tiver que parar para ler ou mexer em algum código, aproveite para refatorar as partes mais óbvias. 1.4. Causa Raíz Sem gambiarras. Se for para arrumar um bug, ataque a causa raíz. 1.5. DRY Don't repeat yourself: não se repita. Um trecho de código repetitivo é um forte indício de necessidade de refatoração. Abstraia as funcionalidades e as reutilize. Além de aumentar a solidez do código (diferentes módulos funcionam com base na mesma função), também diminui a quantidade de código e aumenta a produtividade da equipe. 1.6. Comentários Somente se Necessário Comentários são confusos e sujam o código. Comente só se for estritamente necessário e não for possível explicitar a informação pelo próprio código. Geralmente é possível remover um comentário melhorando o nome das variáveis e funções, e reorganizando os métodos. Trechos de códigos comentados são duplamente errados. Além de não terem uso algum ainda abrem pretexto para voltar à produção um código que com o passar do tempo se torna deprecado (leia-se inútil). 1.7. Nomenclaturas Nomes de módulos e variáveis devem ser autodescritivos em suas intenções. Também sempre utilizar uma língua forte, no nosso caso é o inglês. Além disso, é muito importante utilizar uma linguagem onipresente, que significa utilizar no software os mesmos nomes e termos que se utiliza no mundo real em uma conversa entre stakeholders. Aqui vale a regra do simplificar para não complicar. 1.8. Utilize Injeção de Dependência Sempre que possível utilize injeção de dependência, vai tornar o código mais limpo. Isso só é aplicável se seus módulos forem baseados em interfaces e desacoplados. 1.9. Testes Limpos Um código só é considerado limpo se puder ser validado através de um teste, que também deve ser limpo. Assim, existem algumas regras para garantir a boa codificação de um teste, que deve ser: Fast: O teste deve ser rápido, permitindo que seja realizado várias vezes e a todo momento; Independent: Ele deve ser independente, a fim de evitar que cause efeito cascata quando da ocorrência de uma falha – o que dificulta a análise dos problemas; Repeatable: Deve permitir a repetição do teste diversas vezes e em ambientes diferentes; Self-Validation: Os testes bem escritos retornam com as respostas true ou false, justamente para que a falha não seja subjetiva; Timely: Os testes devem seguir à risca o critério de pontualidade. Além disso, o ideal é que sejam escritos antes do próprio código, pois evita que ele fique complexo demais para ser testado. 1.10. Bom Senso Este ponto não é citado pelo Uncle Bob no Clean Code, é uma adição própria minha. A questão é que os princípios, metodologias e patterns existem para nos ajudar, e não atrapalhar. É aí que entra o bom senso. Se um padrão está mais te atrapalhando do que ajudando, não hesite em deixá-lo. Também não ficamos com medo de adotar um padrão à nossa maneira, sem preocupações e sem dever explicações a ninguém. É claro, falando em bom senso, é necessário saber adaptar as coisas da maneira correta, sem descartar os princípios básicos que as constituíram, para que não se perca a razão de ser. 2. Clean Architecture Na arquitetura limpa, a principal preocupação é a separação de responsabilidades. Isso é conseguido dividindo o software em camadas. Falar em separação de responsabilidades é lembrar em desacoplamento de código, que significa que as dependências são interligadas via interface. O caminho das dependências são sempre apontando para dentro das camadas, e as camadas interiores não conhecem o código de camadas externas. As diretrizes e preocupações listadas pela teoria do Clean Architecture viabilizam códigos que naturalmente acabam sendo: 2.1. Independentes de Frameworks A arquitetura propõe códigos que são independentes de códigos e bibliotecas externas carregadas de recursos. Isso não significa que o código não utilize essas bibliotecas, mas que são desacoplados. 2.2. Testáveis O desacoplamento e interfaceamento é pré-requisito para tornar um módulo testável. Seguindo as diretrizes, é possível testar as regras de negócio sem a UI, banco de dados, servidor ou qualquer outro elemento externo (teste unitário). 2.3. Independentes de UI A UI pode mudar independente da regra de negócio. Isso é implementado naturalmente no esquema cliente SPA e backend (cliente e servidor). 2.4. Independentes de Database Possibilidade de alterar entre SQL, Mongo ou qualquer outro sem alterar o funcionamento do sistema. As regras de negócio e o sistema em si não são ligados ao banco de dados diretamente. 2.5. Independentes de qualquer agente externo De fato as regras de negócio não estão cientes de qualquer informação sobre o "mundo externo". 3. SOLID SOLID é um acrônimo (iniciais) de 5 princípios básicos de desenvolvimento de software que sustentam um código mais fácil de entendimento, de adaptabilidade e vida útil no longo prazo. 3.1. Single Responsability Principle Princípio da responsabilidade única. O princípio afirma que cada classe deve ter um único motivo para ser alterada. Como consequência, de maneira prática, diz-se que uma classe só deve existir para fazer uma coisa (única responsabilidade). Isso é algo subjetivo e não deve ser levado ao pé da letra. Eu gosto de dizer que uma classe deve ser constituída por uma "unidade modular", onde definiremos por bom senso. É bom lembrar que o fato de um método chamar outro método, outra classe, ou ter um IF ou um SWITCH-CASE, ou até mesmo trabalhar em cima de uma FLAG como parâmetro, é um forte indício de que está ferindo ao princípio da responsabilidade única. 3.2. Open/closed Principle Princípio do aberto/fechado. Afirma que uma classe deve ser aberta para extensão mas fechada para alteração. Na prática significa que é possível adicionar funcionalidades em uma classe sem mexer em código antigo. Também que a classe é sempre reutilizável, mas não deve ser alterada. 3.3. Liskov Substitution Principle Princípio de substituição de Liskov. Afirma que uma classe derivada deve ser substituível por sua classe base. Na prática, isso significa que quando uma dependência é definida via interface, qualquer implementação que respeite essa interface pode ser utilizada. 3.4. Interface Segregation Principle Princípio da segregação de interfaces. Uma classe não deve ser forçada a implementar interfaces e métodos de que ela não precisa. Na prática, isso significa que as interfaces devem conter estritamente as declarações necessárias. 3.5. Dependency Inversion Principle Princípio da inversão de dependência. Dependa de abastrações e não de implementações. Conclusão Para construir software organizado, é essencial premissas, bom senso e interpretação flexível de regras. Manter padrões é crucial, visando consistência, organização e otimização. Apesar dos trade-offs, a habilidade na aplicação de conceitos e empatia são vitais. Criar padrões demanda compreensão técnica e de negócios, considerando planejamento de longo prazo. Aplicar padrões exige comunicação eficaz, sinergia de equipe e questionamento constante para evolução contínua. Lembre-se: software é meio, não fim, uma ferramenta facilitadora que não deve ser um problema isolado