actual coding logo
Actual coding logo

O guia para um bom código

programming languages image

No mundo do desenvolvimento de software, as boas práticas de código são os pilares que sustentam a robustez e a eficiência de qualquer projeto. Como destacado por Alex Xu, renomado profissional com uma trajetória que inclui contribuições para gigantes como Twitter, Apple e Oracle, a excelência no código não é apenas uma preferência, mas sim um alicerce essencial. Neste blog, exploraremos insights valiosos compartilhados por Xu, co-fundador da ByteByteGo e autor de best-sellers, desvendando os segredos por trás de um desenvolvimento sólido e sustentável.

Seguir especificações e boas práticas de código

Quando codificamos algo, é importante seguir algumas normas pré-estabelecidas da indústria, como "PEP 8", "Google Java Style" por exemplo, aderindo padrões e especificações estabelecidos que podem dar mais organização, compreensão e até mais segurança á aplicação, além de previnir problemas e facilitar manutenções e adaptações futuras no código.

Documentação e comentários

Um bom código é documentado e comentado de forma clara e coesa, pra que a a complexidade, lógica e decisões sejam explicadas, comentários devem explicar o por que de certas ações, é melhor ser explicado o ("por que"?) do que ("O que?") de certo código. isso também serve pra commits e versionamento.

Robustez e Versatilidade

Um bom código também deve ser ábil para lidar com a váriedade e inesperadas situações e inputs sem crashar ou dar resultados não esperados. A abordagem mais comum é detectar e lidar com as exceções.

Seguir os princípios SOLID

solid principles image

SOLID é um acrônimo de cinco princípios de design de código na programação orientda a objeto("POO") que servem para organização, legibilidade e manutenção no desenvolvimento de software.
foi introduzido por Robert C. Martin em um artigo em 2000 e se tornou um conceito muito conhecido na área de programação até os dias de hoje.


Agora vamos ver mais sobre os tais princípios:

Single Responsability Principle(Princípio da Responsabilidade única)

"Uma classe deve ter um, somente um motivo para mudar".

Caso uma classe tenha muitas responsabilidades, tem mais chances de bugs ocorrerem, pois fazer mudanças em uma das suas responsabilidades pode afetar os outros sem ter noção disso.

Open/Closed Principle(Princípio aberto/fechado)

"Classes devem ter abertura para a se expandir, mas não para modificação".

A mudança de uma responsabilidade atual da classe pode afetar todos os sistemas da classe, se você quer que a classe tenha mais funções o ideal é adicionar funções que já existem e não muda-las, fazendo com que essas funções funcionem mutualmente e eficientemente.

Liskov Substitution Principle(Liskov Substitution Principle)

"Quando uma classe filha não faz as mesmas ações que a classe pai, pode resultar em bugs".

Se você cria uma classe dentro de uma ela se torna a filha, a classe filha deve processar as mesmas requisições e dar o mesmo resultado que a classe pai ou dar um resultado do mesmo tipo.
Por exemplo o que é pedido na função pai é esperado qualquer tipo de café, mas imagine que a função child entregue água.
se a classe criança não coincide nas requisições, ela é completamente mudada e viola este princípio.

Interface Segregation Principle(Princípio da Segregação de Interface);

“Uma classe não deve ser forçada a implementar interfaces e métodos que não utilizará”.

Quando a classe é requisitada para uma ação que não é utilizada, é um desperdício e pode produzir bugs inesperados se essa classe pode executa essas ações.
Ela deve executar apenas funções necessárias que preenchem o todo. Se não for necessário deve ser removida ou movida para outro lugar se tem que ser usada por outra futura classe.

Dependency Inversion Principle (Princípio da Inversão de Dependência).

“Dependa de abstrações e não de implementações”.

Módulo de alto nível(classe): Classe que executa uma ação com alguma ferramenta.

Módulo de baixo nível(classe): Ferramenta precisada para a execução da ação.

O princípio aponta que a Classe não pode estar fundida à ferramenta que ela usa pra execução de uma ação.
considerando isso ela deve estar fundida com a interface que permitirá a ferramenta conectar na classe. Também aponta que classe e interface não devem saber como a ferramenta funciona, a ferramenta precisa ser específicada na interface.

Testar facílmente

Testabilidade de software é de suma importância. Um bom código deve ser fácil de testar e ao mesmo tempo tentar reduzir a complexidade de cada componente, e com o suporte de testes automizados para a certeza de que tudo ocorre como esperado.

Abstração

A abstração de um projeto requer a extração de sua lógica e minimizar a complexidade definindo os melhores caminhos, para um código mais flexível e genérico.
Bom código deve ter certo nível moderado de abstração no meio termo, nem tão superprojetado e nem negligênciado em expandibilidade e manutenção em longo termo.

Utilize padrões de design, mas não exageradamente

Padrões de design pode nos ajudar com problemas comuns. Porém todo padrão tem seus próprios cenários de aplicação, exagerar ou utilizar mal pode tornar o código complexo demais e pouco legível, princípalmente em trabalho em grupo.

Reduzir Dependências Globais

Podemos as vezes ser atolados em dependências e confundir gerenciamento de estado se usarmos variáveis e instancias globais. Um bom código deve funcionar no seu devido local e parâmetro passado, funções devem evitar ao máximo efeitos colaterais.

Refatoramento contínuo

Um bom código é de bom mantimento e extensibilidade. Contínuo refatoramento reduz problemas futuros identificando e concertando seus problemas o mais cedo possível.

Segurança de prioridade máxima

Fundamental mencionar, bom código deve evitar vulnerabilidades de segurança, especialmente para aplicações envolvendo finanças, deve ser livre de injeção SQL, ataques cross-site scripting(XSS) e interceptação de dados.



E por fim espero ter ajudado atravez do compartilhamento das falas de Alex Xu, um programador de excelência que deve ser seguido como exemplo, pela sua experiência, conhecimento e força de vontade ao também passar conhecimento para outros da área, um bom código na minha opinião resumidaente deve funcionar do jeito esperado, adaptável, seguro e com menos complexidade possível.