SOLID, KISS, DRY, YAGNI: Desvendando esses princípios de código
Ser um bom programador vai muito além de programar.
Publicado em 4 de janeiro de 2023
Ser um bom programador vai muito além de programar. É algo que exige que você seja capaz, sobretudo, de resolver problemas complexos de forma eficiente — muitas vezes utilizando algoritmos, testes de unidade e análise de complexidade de espaço-tempo.
No entanto, há também um conjunto de princípios, testados e comprovados, desenvolvidos para refinar a arte e a ciência do desenvolvimento de aplicativos de software. Tais princípios, provenientes da engenharia de software, consistem em abordagens que norteiam a escrita de um código limpo, fácil de depurar e de ser entendido.
Populares entre desenvolvedores e engenheiros de software, SOLID, DRY KISS e YAGNI são princípios básicos que regem a engenharia de software. De maneira geral, eles buscam ajudar a projetar estruturas de desenvolvimento, assim como nortear operações pós-lançamento e suporte de manutenção.
Neste artigo, explicaremos cada um desses métodos, assim como por que eles são considerados elementos cruciais para um processo de desenvolvimento confiável e ágil.
Glossário
O que é Solid
SOLID é um acrônimo mnemônico para cinco princípios destinados a tornar os projetos de software mais compreensíveis, flexíveis e de fácil manutenção. Esse princípio da programação foi criado por Robert C. Martin (ou simplesmente “Uncle Bob”) e representa cinco convenções diferentes de codificação.
Ao seguir esses princípios, poderá melhorar a confiabilidade do seu código trabalhando em sua estrutura e consistência lógica. Em outras palavras, o SOLID trata–se na verdade de um subconjunto de princípios que inclui:
- Single Responsibility principle (princípio da responsabilidade única);
- Open-Closed principle (princípio do aberto/fechado);
- Liskov Substitution principle (princípio da substituição de Liskov)
- Interface Segregation principle (princípio da segregação de interface);
- Dependency Inversion principle (princípio de inversão de dependência).
Single-responsibility principle (princípio da responsabilidade única)
Considerado um princípio-chave da engenharia de software, o Princípio da Responsabilidade Única determina como o código deve ser modularizado na programação orientada a objetos.
Dessa forma, cada módulo deve ser projetado para cumprir somente a sua responsabilidade sobre uma única parte da funcionalidade fornecida pelo software;
Open-closed principle (princípio do aberto/fechado)
O Princípio Aberto-Fechado (OCP) afirma que as entidades de software (classes, módulos, métodos, etc.) devem ser abertas para extensão, mas fechadas para modificação.
Na prática, isso significa criar entidades de software cujo comportamento possa ser alterado sem a necessidade de editar e recompilar o próprio código. Sendo assim, qualquer parte do software deve estar disponível e ser facilmente estendida para outros recursos, mas não deve ser modificada.
Liskov substitution principle (princípio da substituição de Liskov)
Esse princípio define que objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem quebrar a aplicação. Isso requer que os objetos de suas subclasses se comportem da mesma maneira que os objetos de sua superclasse. Em outras palavras, os objetos dentro de um programa podem ser substituídos por instâncias de seus tipos de subcategoria sem alterar a precisão daquele programa específico.
Interface segregation principle (princípio da segregação de interface)
Segundo o Princípio da Segregação de Interface, é melhor evitar adicionar novas funcionalidades ou métodos a uma interface existente. Em vez disso, é recomendável incorporar uma nova interface e permitir que as classes implementem interfaces diferentes com base na necessidade.
Dependency inversion principle (princípio de inversão de dependência)
O Princípio de Inversão de Dependência (DIP) afirma que módulos de alto nível não devem depender dos módulos de baixo nível; ambos devem depender de abstrações. Estas, por sua vez, não devem depender de detalhes e vice-versa.
Ao programador ou desenvolver o software, é comum implementá-lo de forma que cada módulo ou método se refira especificamente aos seus colaboradores, que fazem o mesmo.
Entretanto, esse tipo de programação normalmente não possui camadas suficientes de abstração, o que resulta em um sistema fortemente acoplado, já que cada módulo faz referência direta aos módulos de nível inferior.
Nesse sentido, é preciso utilizar um padrão de design conhecido como “padrão de inversão de dependência”, resolvido pelo uso de injeção de dependência.
O que é DRY
Formulado por Andy Hunt e Dave Thomas no livro The Pragmatic Programmer, Don’t Repeat Yourself (DRY) é um dos princípios de programação mais fundamentais entre todos.
Ele prega que todo programador deve reduzir ao máximo a repetição de informações ou métodos, e com isso evitar redundâncias.
Duplicação é desperdício
Cada linha de código que entra em um aplicativo, e é mantida, se torna uma fonte potencial de bugs futuros. Isso porque, dentre outros fatores, a duplicação “incha” a base de código desnecessariamente, resultando em mais oportunidades para bugs, além de adicionar complexidade acidental ao sistema.
O programador que aprende a reconhecer a duplicação e entende como eliminá-la é capaz de produzir um código muito mais limpo. Sendo assim, é recomendável, por exemplo, dividir o código em segmentos menores para conseguir gerenciá-lo e utilizar um único segmento em qualquer ponto, chamando-o sempre que necessário.
O princípio DRY garante que qualquer modificação de um único elemento de um sistema não requer uma mudança em outros elementos logicamente não relacionados. Além disso, elementos logicamente relacionados mudam de maneira previsível e uniforme, o que os mantém sincronizados.
O que é KISS
O princípio KISS (Keep It Simple, Stupid) lembra que todo o design e implantação de software deve prezar pela simplicidade — seja no desenvolvimento de um site, aplicativo ou simplesmente ao projetar um bloco de código.
O KISS também afirma que não há valor em uma solução ser “inteligente”, mas sim em ela ser facilmente compreensível. Isso porque, muitas vezes, os desenvolvedores se sentem tentados a escrever soluções “inteligentes” que utilizam recursos complexos. Nesse caso, uma solução é melhor quando se usa menos herança, menos polimorfismo, menos classes, etc.
Mas isso não quer dizer que esses recursos não podem ser usados. Em vez disso, eles só devem ser empregados quando necessários ou quando houver alguma vantagem substancial. Como resultado, é possível obter um código-fonte fácil de depurar, cuja manutenção futura por outro desenvolvedor será menos trabalhosa.
Esse princípio foi cunhado pelo engenheiro americano Kelly Johnson ao se referir à exigência de que uma aeronave militar deve ser reparável com um conjunto limitado de ferramentas em condições de combate.
No contexto de desenvolvimento de produtos digitais, o princípio KISS tem um grande impacto no sucesso geral do produto. Algumas das vantagens da sua aplicação incluem:
- Otimização de tempo: os usuários não querem perder tempo. Eles esperam uma experiência sem atrito com fluxos de usuário diretos e intuitivos, nomenclatura sem jargões e resultados rápidos;
- Simplificação: uma estrutura de software mais simples torna os testes, incluindo testes automatizados, mais fáceis e eficazes;
- Baixa complexidade: a complexidade reduzida da base de código facilita e agiliza a manutenção e a integração de novos membros da equipe no meio do projeto.
O que é Yagni
O YAGNI (You Aren’t Gonna Need It) é outro princípio muito adotado do desenvolvimento software que afirma que os recursos só devem ser adicionados quando necessários. Como parte da filosofia de programação extrema (XP), o YAGNI elimina o excesso e a ineficiência no desenvolvimento para facilitar o aumento desejado da frequência de lançamentos.
Trata-se de um dos princípios mais conhecidos do XP, surgido do livro Extreme Programming Installed , de autoria de Ronald Jeffries, Ann Anderson e Chet Henderson.
Esse princípio ajuda tanto desenvolvedores quanto programadores a evitar esforços desperdiçados em recursos que são considerados necessários em algum momento.
A ideia é que essa suposição muitas vezes acaba sendo incorreta. Mesmo que um recurso acabe sendo desejado, ainda pode acontecer que a implementação não seja necessária.
O argumento é que os desenvolvedores não percam tempo criando elementos estranhos que podem não ser necessários e podem atrapalhar ou retardar o processo de desenvolvimento.
Como o YAGNI ajuda a evitar gastar tempo com recursos que não podem ser usados, os recursos principais de um programa são melhor desenvolvidos e menos tempo total é gasto em cada lançamento.
Muito parecido com o princípio Worse is Better, o YAGNI é contra o desenvolvimento de recursos extras e ajuda a evitar o aumento de recursos.
Entre várias coisas, esse princípio ajuda a otimizar todo o processo de desenvolvimento de software, incluindo a diminuição de custos. Isso ocorre devido a:
- Melhora no desempenho do desenvolvedor/programador: a equipe se concentra em entregar os requisitos atuais de forma eficaz. Eles não gastam tempo e esforço em suposições;
- Base de código mais flexível: você não precisa encontrar maneiras de usar soluções abaixo do ideal que você já desenvolveu antes de ter a imagem completa.
Quer se tornar um programador? Conheça a Awari!
A Awari é uma plataforma de ensino completa que conta com mentorias individuais, cursos com aulas ao vivo e suporte de carreira para você dar seu próximo passo profissional.Conheça nossa Trilha de Programação e confira os nossos cursos de Front-end e Back-end com jornadapersonalizada e materiais complementares desenvolvidos por especialistas no mercado.
Artigos Relacionados
Confira abaixo mais conteúdos sobre o tema
Awari e Fluency: A Revolução da Educação Começou
Fluency e Awari estão oficialmente juntas e prometem transformar...
Gestão de Produtos para IA e ML: Como se tornar um especialista na área
A gestão de produtos para IA e ML é...
Gerente de Produto versus Gerente de Marketing de Produto: Qual é a diferença?
"Gerente de Produto versus Gerente de Marketing de Produto:...
