Tradução: 10 Programming Principles Every Software Developer Should Know - 10 princípios de programação que todos os desenvolvedores de software devem conhecer

 

10 Programming Principles Every Software Developer Should Know

10 princípios de programação que todos os desenvolvedores de software devem conhecer 

Tradução do texto publicado na OSSPH, escrito pela Paula Isabel Signo:
Paula é uma escritora técnica da OSSPH e desenvolvedora web. No seu tempo livre, Paula contribuí para vários projetos Open Source, voluntários em comunidade e compartilha seu conhecimento escrevendo artigos e tutoriais. Conecte-se com Paula aqui para saber mais sobre o trabalho e interesses dela. Sigam ela nas redes sociais: https://twitter.com/codewithpau

Aprenda os princípios fundamentais de programação que permitem aos desenvolvedores de software escrever códigos mais limpos, fáceis de manter e escaláveis.

 Programação é um campo fascinante que empodera os indivíduos, tornando-os capazes de criar soluções de software inovadoras e funcionais. No entanto, escrever código não significa apenas fazer as coisas funcionarem, também é preciso criar código limpo, eficiente e de fácil manutenção. Para conquistar isso, os desenvolvedores de software devem se familiarizar com um conjunto de princípios fundamentais de programação. Esses princípios são como guias, ajudando os desenvolvedores a escrever códigos robustos, escaláveis e fáceis de entender. Esse artigo irá explorar 10 princípios essenciais de programação que todo desenvolvedor de software deve conhecer. Entender e aplicar esses conceitos às suas abordagens de codificação permitirá que você crie um código que não seja apenas funcional, mas também limpo e gerenciável. 

 

1. DRY (Don't Repeat Yourself) - NSR (Não Se Repita)

 O primeiro princípio de programação da lista é o NSR que significa "Não se repita". Isso quer dizer que você deve evitar código duplicado em seu programa, e ao invés disso se esforçar para tornar seu código mais reusável e modular. 

 Duplicar código pode levar a muitos problemas, como maiores esforços para manutenção, maior chance de bugs e uma dificuldade para fazer as alterações em vários locais.

Imagine que você está construindo um programa que calcula diferentes áreas de diferentes formas. Em vez de escrever funções separadas para calcular a área de cada forma (por exemplo, uma função separada para calcular área de um quadrado, outra para um triângulo e assim por diante), você pode usar o NSR criando uma função única chamada calcularArea que pega parâmetros necessários e retorna a área.

 

 Dessa forma, você vai poder reusar a mesma função para todas as áreas que passarem com parâmetros adequados. Assim você evita ter que repetir a mesma lógica para cálculos de área, tornando seu código mais eficiente e fácil de manter.

 Lembre-se, seguir o NSR não é o único que pode ajudar a escrever códigos mais limpos e organizados, mas também economiza tempo e esforço no longo prazo.

2. KISS (Keep it Simple, Stupid) - MISE (Mantenha Isso Simples, Estúpido)

  MISE enfatiza a importância da simplicidade do desenvolvimento de software. Isso sugere que devemos nos esforçar para manter o código e soluções o mais simples possível. Simplificando o código para ser mais fácil de compreender, manter e debugar, reduzindo a possibilidade de erros ou problemas.

 Por exemplo, digamos que precisamos escrever um programa que calcula a média de uma lista de números. Uma forma simples e direta seria iterar na lista, somar os números e depois dividir a soma pela contagem total. Essa abordagem é fácil de entender e requer poucas linhas de código.

 Por outro lado, mais complexidade pode envolver uso de fórmulas matemáticas avançadas ou a incorporação de recursos desnecessário com lógica complicada. Essa complexidade a mais pode tornar o código mais difícil de compreender e manter no futuro. 

 Simplificar o código ajuda melhorando a compreensão e adaptabilidade para você e desenvolvedores futuros. Adicionalmente reduz a probabilidade de introduzir erros.

3. YAGNI (You Aren’t Gonna Need It) - VoNaNeDi (Você Não Necessitará Disso)

 VoNaNeDi é um princípio útil para desenvolvedores de software. Ele nos lembra para evitar adição de recursos funcionalidades desnecessárias no nosso código. Em outras palavras, não escreve no código coisas que você não precisa ou antecipe as funcionalidades necessárias futuras. Esse principio encoraja simplicidade e eficiência no desenvolvimento de software.

 

 Para ilustras o VoNaNeDi, vamos considerar um cenário de desenvolvimento de um programa para gerenciamento de uma lista de pendências (to-do list). Usar VoNaNeDi implica concentrarmos inteiramente na implementação das tarefas necessárias para lista de tarefas, como adicionar, deletar e marcar uma tarefa como completa. Ele alerta contra a introdução de funções sofisticadas como lembretes, notificações ou codificação por cores, coisas absolutamente não necessárias para a funcionalidade fundamental do programa.

 

 Seguindo o VoNaNeDi vamos poupar tempo e esforço, evitando a construção de funcionalidades desnecessárias que podem nunca ser utilizadas ou que poderão ser adicionadas posteriormente, se necessário. Este princípio serve para manter uma base de código limpa e gerenciável, o que diminui o risco de bugs.

 

4. Separation of Concerns (SoC) - SEB (Separar Em Blocos)

O principio da separação em blocos (SEB) é um principio fundamental no desenvolvimento de software que promove a divisão de um programa em partes distintas e independentes, com cada parte abordando uma preocupação ou responsabilidade específica.

Em termos mais simples, isso significa que diferentes partes de um programa devem se concentrar em fazer uma coisa bem feita, sem se envolver em tarefas não relacionadas. Essa abordagem auxilia na melhoria da manutenibilidade, modularidade e reutilização do código.

Por exemplo,digamos que você esteja construindo uma aplicação web que permita aos usuários se registrarem e fazerem login. Aplicando o princípio do SEB, você separaria a funcionalidade de registro do usuário da funcionalidade de login. Isso significa criar módulos ou funções separadas que tratem de cada preocupação de forma independente. Isso garante que o código responsável pelo registro do usuário foque apenas nessa tarefa, enquanto o código encarregado do login trate da autenticação e autorização.

Essa separação facilita a atualização ou modificação de uma parte da aplicação sem afetar a outra. Além disso, permite que diferentes membros da equipe trabalhem em várias responsabilidades simultaneamente, melhorando a colaboração e a eficiência do desenvolvimento.

 

5. Do The Simplest Thing That Could Possibly Work - Faça o mais simples póssivel que funcione

 Faça o mais simples possivel que funcione enfatiza a importância da simplicidade no desenvolvimento de software. Ao invés de soluções complicados desenvolvedores devem procurar as abordagens mais simples e minimalistas que faça os requisitos imediatos. Esse principio encoraja evitar a complexidade desnecessaria o que vai levar a um código mais gerenciavel e de fácil manutenção.

Por exemplo, digamos que você tenha a tarefa de desenvolver um programa que calcule a média de uma lista de números. Em vez de projetar um programa elaborado com múltiplas etapas e fórmulas matemáticas avançadas, você pode seguir o princípio da simplicidade. Você pode começar somando todos os números da lista e depois dividindo a soma pela contagem total de números.

Esta abordagem simples alcança o resultado requerido sem complexidade excessiva ou cálculos desnecessários. Focar na solução mais simples não apenas economiza tempo e esforço, mas também resulta em um código mais fácil de compreender, depurar e manter no longo prazo.

6. Code For The Maintainer - Codar para quem for fazer manutenção

Quando falamos sobre “codar para quem for fazer manutenção”, queremos dizer escrever código de uma forma que facilite a compreensão, modificação e manutenção dele por outros desenvolvedores no futuro. Como desenvolvedor de software, é essencial considerar as pessoas trabalharão em seu código depois que você terminar de usá-lo. Assim como um livro bom é escrito pensando no leitor, um código bom deve ser escrito pensando no mantenedor.

Uma maneira de obter a manutenção do código é seguir as convenções de codificação e práticas recomendadas estabelecidas. Por exemplo, o uso de variáveis descritivas e nomes de funções pode melhorar bastante a legibilidade. Em vez de usar nomes misteriosos como a, b ou x, prefira escolher nomes significativos que descrevam claramente o propósito e a funcionalidade do código.

Fora isso, organizar o código em seções de lógica, adicionar comentários para explicar partes complexas ou obscuras e dividir tarefas complexas em funções menores e gerenciáveis também pode tornar o código mais fácil de compreender e realizar manutenção.

A adoção dessas técnicas pode ajudar futuros desenvolvedores que precisam trabalhar em seu código a entendê-lo melhor, diminuindo a possibilidade de introdução de bugs ou comportamento imprevisto durante manutenção e atualizações. Finalmente, escrever código para quem for fazer manutenção garante que o software seja estável e possa evoluir perfeitamente ao longo do tempo.

7. Avoid Premature Optimization - Evite otimização prematura

Evite a otimização prematura é para lembrar aos desenvolvedores de software que devem priorizar a escrita de código limpo e funcional antes de focar na otimização do desempenho. A otimização prematura refere-se à prática de gastar tempo e esforço excessivos na otimização de código que pode não necessariamente precisar dele. Em vez disso, os desenvolvedores devem primeiro se concentrar na criação de código que seja fácil de entender e manter e que atenda aos requisitos funcionais desejados.

Digamos que você está construindo um programa para calcular a soma de todos os números de uma determinada lista. Como desenvolvedor, você pode ficar tentado a gastar muito tempo otimizando o código para que ele seja executado o mais rápido possível. No entanto, se você priorizar a otimização prematura, poderá acabar com um código complexo e complicado, difícil de entender e sujeito a bugs. Em vez disso, seguindo o princípio de evitar otimização prematura, você se concentraria em escrever uma solução simples e direta que funcionasse corretamente.

Depois que o código estiver funcional e atender aos requisitos, você poderá analisar seu desempenho e otimizá-lo, se necessário, com base em padrões de uso reais ou medições de desempenho. Isso garante que seu tempo e esforço sejam gastos com sabedoria e que complexidades excessivas sejam evitadas nas fases iniciais de desenvolvimento.

8. Boy Scout Rule - Regra do Escoteiro

A Regra do Escoteiro é um princípio de codificação que incentiva os desenvolvedores de software a deixar a base de código em um estado melhor do que a encontraram. Ela promove a ideia de melhorar continuamente a qualidade do código ao fazer pequenas mudanças incrementais sempre que você trabalha com ele. Assim como os escoteiros deixam um acampamento mais limpo do que encontraram, os desenvolvedores devem se esforçar para deixar a base de código mais organizada, legível e sustentável após fazer alterações.

Por exemplo, digamos que você esteja trabalhando em um projeto de software e se depare com uma seção de código que é difícil de entender ou que poderia ser escrita de forma mais eficiente. Em vez de apenas fazer as mudanças necessárias e seguir em frente, a Regra do Escoteiro sugere que você reserve um pouco mais de tempo para melhorar o código. Isso pode envolver renomear variáveis para que sejam mais descritivas, simplificar lógicas complexas ou refatorar o código para seguir as melhores práticas.

Aplicar a Regra do Escoteiro não apenas resolve o problema imediato, mas também melhora a base de código para os futuros desenvolvedores que trabalharão nela.

9. Law of Demeter - Lei de Demeter

A Lei de Demeter é uma diretriz que ajuda os desenvolvedores a escrever código mais modular e menos dependente dos detalhes internos de outros componentes. A principal ideia por trás deste princípio é minimizar o acoplamento entre diferentes partes de um sistema de software.

Em termos simples, sugere que um módulo deve ter um conhecimento limitado sobre a estrutura interna de outros módulos e deve interagir apenas com seus vizinhos imediatos.

Vamos imaginar um cenário onde temos um objeto chamado Pessoa que possui várias propriedades e comportamentos. De acordo com a Lei de Demeter, se quisermos acessar uma propriedade do endereço da pessoa, em vez de acessá-la diretamente como pessoa.endereco.rua, devemos usar um método fornecido pelo próprio objeto pessoa, como pessoa.getRua(). Dessa forma, o objeto Pessoa encapsula os detalhes de seu próprio endereço e expõe uma interface de alto nível para outros componentes interagirem com ele.

Seguir a Lei de Demeter resulta em um código mais versátil e fácil de manter. Se a estrutura interna do objeto Pessoa ou seu endereço mudar, só precisamos atualizar os métodos dentro do objeto Pessoa, em vez de modificar todos os lugares no código onde o endereço é acessado diretamente. Este princípio promove o acoplamento fraco, reduz dependências e realça a modularidade geral do nosso sistema de software.

10. SOLID Principles - Principios do SOLID*

Os princípios SOLID são um conjunto de cinco princípios de design que ajudam os desenvolvedores de software a criar código manutenível e flexível. Esses princípios fornecem diretrizes para escrever um código limpo, modular e expansível. Vamos examinar cada princípio e entendê-los com exemplos.

Single Responsibility Principle (SRP)

Este princípio afirma que uma classe ou módulo deve ter apenas uma razão para mudar, ou seja, deve ter uma única responsabilidade. Classes focadas em um único propósito são mais fáceis de entender, testar e adaptar. Por exemplo, considere uma classe chamada EmailSender. Ela deve ser responsável por enviar e-mails e não tratar de outras tarefas não relacionadas, como gerar relatórios ou analisar dados. Mantemos a base de código mais manutenível e modular aderindo ao SRP.

Open/Closed Principle (OCP)

O princípio OCP enfatiza que entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação. Isso significa que devemos ser capazes de adicionar novas funcionalidades ou comportamentos sem modificar o código existente. Uma forma de alcançar isso é usando herança ou interfaces. Por exemplo, imagine uma classe Shape com diferentes subclasses como Rectangle e Circle. Se quisermos adicionar uma nova forma, podemos criar uma nova subclasse sem modificar a classe Shape existente. Este princípio promove a reutilização do código e reduz o risco de introduzir bugs em um código já funcional.

Liskov Substitution Principle (LSP)

O LSP afirma que objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem afetar a correção do programa. Em termos simples, qualquer instância de uma classe deve poder ser usada no lugar de sua classe pai sem causar comportamentos inesperados. Por exemplo, suponha que temos uma classe base chamada Animal com um método makeSound(). Subclasses como Cat e Dog devem poder substituir a classe Animal e ainda produzir o comportamento esperado sem causar erros ou inconsistências.

Interface Segregation Principle (ISP)

O ISP aconselha que os clientes não devem ser forçados a depender de interfaces que não usam. Ele incentiva a criação de interfaces específicas adaptadas às necessidades dos clientes em vez de ter interfaces grandes e monolíticas. Isso evita que as classes tenham que implementar métodos que não são relevantes para elas. Por exemplo, imagine uma interface chamada Printer com métodos como print(), scan() e fax(). Em vez de ter uma única interface, é melhor dividi-la em interfaces menores, como Printable, Scannable e Faxable. Dessa forma, as classes podem implementar apenas as interfaces de que precisam, mantendo a base de código mais limpa e focada.

Dependency Inversion Principle (DIP)

O DIP sugere que módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações. Ele promove acoplamento solto e permite modificações e testes mais fáceis. Na prática, isso significa que as classes devem depender de interfaces ou classes abstratas, e não de implementações concretas. Por exemplo, considere uma classe chamada Logger que precisa escrever logs em um arquivo. Em vez de depender diretamente de uma implementação específica do sistema de arquivos, ela deve depender de uma interface como FileSystem, que pode ter várias implementações (por exemplo, LocalFileSystem, CloudFileSystem). Assim, podemos alternar entre as implementações sem modificar a classe Logger.

Desenvolvedores de software podem criar códigos mais manuteníveis, escaláveis e flexíveis ao aderir aos princípios SOLID. Esses princípios promovem modularidade, reutilização e testes fáceis, o que, no final das contas, leva a um software de maior qualidade. Embora possam requerer um esforço e planejamento adicionais inicialmente, os benefícios a longo prazo tornam-nos diretrizes valiosas a serem seguidas no processo de desenvolvimento de software.

Concluindo

Compreender e aplicar princípios de programação é vital para todo desenvolvedor de software. Esses princípios fornecem um conjunto de diretrizes e práticas recomendadas que ajudam a criar um código limpo, eficiente e de fácil manutenção. Os desenvolvedores podem melhorar a reutilização, modularidade e flexibilidade do código aderindo a esses princípios, resultando em soluções de software mais escaláveis e robustas. Além disso, esses princípios promovem bons hábitos de codificação, melhoram a colaboração entre os membros da equipe e, em última análise, contribuem para o sucesso dos projetos de software. À medida que o desenvolvimento de software continua a evoluir, a adoção desses princípios de programação capacitará os desenvolvedores a escrever códigos de alta qualidade que atendam às demandas do cenário tecnológico atual em constante mudança.

 

 

Texto original: https://blog.ossph.org/programming-principles-every-developer-should-know/

 Autora: Paula Isabel Signo

*SOLID é melhor não traduzir