Como desenvolvedor de software, profissional, e gerente de projetos, aprendi que um bom código não só é uma obrigação de um programador, mais também, é uma amostra do perfil profissional, da organização, e do que ele espera da sua carreira profissional.
Um código meia-boca foi feito por um desenvolvedor meia-boca, portanto, escreva um código que você possa apresentar e sentir orgulho dele, ele não deve só funcionar, ele tem que ser rápido, eficiente, escalável, funcional, organizado, limpo e bem documentado.
Steve Jobs declarou em uma palestra o seguinte “Seu trabalho vai preencher uma grande parte de sua vida, e a única maneira de ficar realmente satisfeito é fazer o que você acredita ser um ótimo trabalho. E a única maneira de fazer um ótimo trabalho é amar o que você faz.” e você deve levar isso ao pé da letra.
Vou deixar essas dicas para servirem como um guia, que você possa ir acrescentando a sua vida cotidiana, como desenvolvedor, se você quiser se aprofundar ainda mais na qualidade do seu código, recomendo o livro Código Limpo de Robert Cecil Martin, também conhecido como “Uncle Bob” ou Tio Bob. que é um livro clássico das boas práticas de desenvolvimento de software usando metodologia Ágil.
Obviamente, isso não é um manual completo, e a partir daqui você poderá evoluir e transformar essas dicas de muitas maneiras, conforme seu nível de amadurecimento em programação, você deve experienciar e descobrir mais estilos de codificação, esquemas e pontos de vista.
O objetivo aqui é cobrir o que é um código limpo e de qualidade, de maneira geral ou global, não vamos falar de uma ou de outra linguagem, e sim de conceitos comuns e visões macro. À medida que você avançar como desenvolvedor, pode ir se aprofundando nos detalhes, nas táticas e informações práticas de cada um desses e de outros pontos.
Faça um favor para o próximo – Você pode ser o próximo de outra pessoa!
Embora os desenvolvedores escrevam códigos durante o exercício de sua própria profissão, eles passam a maior parte do tempo lendo códigos de outros programadores. Se a maior parte de nosso tempo é gasta em compreensão e leitura de código, é melhor ter certeza de que, quando realmente codificarmos, não estamos gerando um código de difícil entendimento.
Como você provavelmente será a próxima pessoa a ler o código que alguém está escrevendo, e escrevendo algo que outra pessoa vá ler, certifique-se de entendê-lo bem, se hoje você pegar um código seu escrito a três meses, será possível compreende-lo na primeira leitura?
Tenho certeza de que quase todo programador escreve código às 3 da manhã apenas para acordar no dia seguinte e passar horas tentando descobrir o que está acontecendo, ou como aquilo está funcionando.
Garantir que seu código esteja claro e limpo minimizará o tempo necessário para que você ou outro profissional, aumentará sua produtividade e terá resultados duradouros em longo prazo. Faça um favor a si mesmo e comece a escrever um código limpo agora mesmo.
“Funciona” X “Está Certo”
O código não deve ser medido apenas com base em “funciona” ou “não funciona”. Obviamente, o código que não funciona não presta, é inútil. Mas o código que funciona não é necessariamente bom, e essa é uma distinção muito importante a se fazer.
Uma vez que nosso código prova que funciona, nosso trabalho como desenvolvedor não está concluído, é obrigação, garantir que ele passe por todos os testes, também esteja claro com variáveis declaradas e comentadas, limpo, com a edentação correta, comentado, documentado e passível de manutenção.
Não devemos julgar o código apenas por sua funcionalidade, existem mais parâmetros e princípios orientadores para o que é um código bem escrito.
Melhor clareza do que inteligencia!?
Como desenvolvedores de software, nos envolvemos na solução de problemas, o que envolve criatividade e pensamento intensivo, e muitas vezes, quando se deparamos com problemas complexos, nosso código pode se tornar “inteligente”, fazer coisas muito inteligentes que apenas a pessoa que escreveu o código pode entender o que diabos está acontecendo.
Esse é um resultado indesejável, mesmo quando o problema é difícil de resolver. O verdadeiro domínio e profissionalismo consistem em resolver um problema complexo e mostrar sua solução de forma clara, para que outras pessoas possam revisar o que foi feito e se envolver com ele.
Não fazemos isso para se gabar de ter encontrado a solução, ou porque precisamos ser simpáticos com nossos colegas e compartilhar com eles, embora esse também seja um bom motivo, mas se você for a única pessoa a entender o código, isso irá prejudicá-lo a longo prazo.
Outro desenvolvedor terá dificuldade por exemplo em refatorar o código, ou traduzi-lo para outra linguagem, o que pode acabar restringindo o projeto, tornando seu desenvolvimento mais lento, ou tornando você o responsável por isso, e você ficará preso a um pedaço de código para sempre até morrer ou deixar a empresa.
Devemos ter certeza de que, depois de resolver um problema, a solução parecerá clara e simples para qualquer pessoa que ler esse trecho de código. Se não for, ou se existir complexidade inerente no processo, deixe tudo documentado e comentado, se usou alguma referência externa, deixe-a na documentação.
Confiança gera Confiança
Quando você lê o código de alguém, ou outro desenvolvedor lê seu código, há um processo de construção de confiança entre ambos. Quando já existe um alto grau de confiança no código que entre vocês, o projeto pode se mover mais rápido.
Lembre-se, o você do futuro, pode se deparar com um código seu escrito hoje, ou mesmo com um código seu escrito no passado. Se você não confia em seu próprio código, boa sorte para você, você vai precisar.
Para passar confiança na leitura, o seu código deve antecipar o que está acontecendo e o que vai acontecer, permitindo que o resultado seja previsível. Não estamos escrevendo um livro de aventura ou suspense, quando outro programador estiver fazendo manutenção no código, essa antecipação dos acontecimentos, permite que caso ele precise inserir um novo processo ele não precise se preocupar com possíveis efeitos colaterais e ter que ler o código inteiro.
Evite surpresas, códigos ambíguos, nomes mirabolantes e coisas muito surpreendentes podem confundir. Digamos que uma função ou classe é antecipada deixando claro o que ela realiza não é necessário mais nenhuma ação, mas quando o leitor fica surpreso e outras ações são realizadas, a confiança é abalada e o leitor não pode mais confiar no programador, afinal, como ele poderia, quais outras surpresas aquele código ainda vai trazer?
Um passo de cada vez, e logo você saberá andar e correr
Escrever um código limpo, e funcional, não é algo para ser feito de uma vez, por isso, na carreira de desenvolvedor, existem níveis, treinee, júnior, pleno, master, sênior, expert e mais alguns outros só para se ter uma ideia. O que diferencia eles não é o conhecimento na linguagem ou no problema, e sim a confiança transmitida pelo código de cada um.
Ou seja, escrever um código limpo certamente não acontece por si só, nem da noite para o dia, é um processo que requer prática, iterações contínuas, refatoração e adesão constante aos princípios das metodologias ágeis, em seu livro Robert Cecil, menciona claramente que nem mesmo ele escreve um código limpo na primeira vez, cada trecho ou pedaço de código é examinado depois de escrito e refeito para aderir aos princípios propostos.
Cada qual com sua preocupação e responsabilidade
Ao escrever código limpo, devemos ter em mente que aquele bloco de código não existe sozinho, faz parte de um todo, certa vez, ouvi uma história infantil, que contava sobre uma coruja, que levava água no seu bico, afim de tentar apagar o incêndio da floresta, o que a principio era impossível, porém, quando ela foi perguntada sobre o que estava fazendo ela disse, “só estou fazendo a minha parte, se todos o fizerem, vamos conseguir”.
Quando escrevemos funções ou classes que envolvem interesses distintos não fazemos um código limpo, manter a lógica de negócios separada, cada qual em seu próprio nível de abstração, e com suas próprias responsabilidades, isso sim é um código limpo.
O princípio é direto: qual é a lógica que estou escrevendo agora? Qual é a principal preocupação? Eu tenho outras preocupações que foram implementadas? Isso pode causar outros efeitos?
Código é como um artigo ou um livro didático, não como um romance ou suspense
Um artigo, ou blog, tem uma estrutura clara. O assunto principal está no topo, e à medida que avançamos com o artigo podemos notar que o assunto está sendo dividido em subpartes, e dentro delas temos mais detalhes sobre cada parte.
Um livro didático é escrito do mesmo modo, se você já leu algum livro para aprender a programar em uma determinada linguagem, já deve ter reparado que o autor ensina desde os princípios básicos e vai evoluindo em conceitos e complexidade até abordar todos os níveis. Não adianta ele usar no principio conceitos complexos.
O código deve seguir o mesmo princípio. No início, teremos a principal preocupação com o trecho de código. À medida que progredimos, a função e as classes envolverão mais detalhes de implementação e manterão uma separação clara de interesses – exatamente como cada artigo do blog tem um subtítulo e um parágrafo estreitamente relacionado a ele.
Cada pedaço de código deve ser dividido em classes e funções que lidam com uma preocupação específica e, à medida que avançamos nelas, eles lidam apenas com essa preocupação, não mais com o todo. Porém, fazendo a sua própria parte para interagir com o todo de maneira responsável.
Primeiro Mandamento – A Regra do Escoteiro
Todo o programador deve participar pelo menos durante um final de semana, de um acampamento de escoteiros ou de um treinamento de sobrevivência na selva. Quando estava no escotismo, nosso princípio orientador quando em viagens de campo era “deixe o lugar mais limpo do que o encontrou”.
Quando programadores, devemos nos nortear pelo mesmo principio, ou seja – Sempre deixe o código melhor do que você o encontrou -. Código limpo é um processo, que consiste na melhoria constante e no desenvolvimento contínuo, por você e por outras pessoas na organização. Portanto, deixe o código melhor do que estava antes.
Nomes de variáveis ruins, comentários inúteis, código comentado, erros de edentação ou estruturais que não estejam seguindo o código de conduta do projeto, quanto mais tempo isso permanecer no código, mais podre fica, e lembre-se quando você faz um simples comentário em um código existente ela passa a ser SEU.
Se a partir daquele ponto, sobraram restos e sujeiras, foi você que deixou, não o visitante anterior. Seja pro ativo. Seja um escoteiro.
Organização, Limpeza, Sustentabilidade, Reciclável
Sempre certifique-se de que seu código segue essas quatro diretrizes. Se ele acompanha essas 4 regras, você já atende a mais da metade das regras de um código limpo. Código limpo é o código que tem uma boa estrutura, é claro, é bem nomeado e não contém surpresas.
O código reutilizável força você a separar interesses, manter o nível correto de abstração e impede que você escreva código que seja logicamente dependente de outras seções.
O código sustentável permite que outros contribuam e entendam o que está acontecendo. Ele leva em consideração que o software se transforma com o tempo. Portanto, antecipe as mudanças e certifique-se de que o código será fácil de refatorar se as mudanças acontecerem.
Organização é o principio básico da compreensão, tenha em mente que TODO o processo de codificação deve seguir 3 passos básicos, receber os dados de entradas, realizar algum tipo de processamento desses dados, realizar a saída dos resultados.
Não Copie, Não Duplique, Não Reinvente a Roda
Se você está copiando um código seja de outra parte do seu software, ou de um sistema externo ou mesmo de um outro programador, não copie, reescreva, siga as suas regras de codificação e o seu código de conduta, lembre-se, você será o responsável por aquele código, e se você não entendeu exatamente o que está sendo feito, refaça.
Duplicação significa de fato que o código não está limpo, se você copiou algo e duplicou significa que você não está fazendo as coisas de maneira correta.
Se houver necessidade de realizar uma duplicação de um bloco de código, verifique se o melhor não é fazer uma refatoração, ou mesmo uma reorganização do seu código, de modo que ele se torne mais reutilizável.
Não reinvente a roda, pois podem acontecer duas coisas, você inventar uma nova roda, diferente, porém que não funciona da maneira esperada. Ou, você vai investir muito tempo, se desgastar e conseguir reinventar uma nova roda que no máximo vai substituir de maneira funcional a que já existe.
Antes de fazer essas coisas, se pergunte se existe uma opção, e garanto que quase sempre a resposta é um SIM definitivo.
Evite Dependências Lógicas
Dependência lógica significa que uma parte do seu código está contando com uma parte separada, que pode ou não ser sua, para conter uma certa lógica de negócios, assumindo que o código não será alterado e, portanto, a implementação está bem.
Só de ler este paragrafo, você vai entender que não, não está bem, quando escrevemos código, devemos ter certeza de que ele está “por conta própria”, ou seja, que temos o nível correto de abstração, que o código não conhece informações que não deveria conhecer, que, se for refatorado, não teremos um problema incomum de efeitos colaterais em outras funções e classes.
Escolha dos Nomes – Pense bem antes de escolher
Os nomes devem descrever o que é feito ou contido neles. Parte de ser claro é não deixar nenhuma outra interpretação para o nome e direcionar o leitor a apenas uma conclusão possível. Observe que ao nomear corretamente não requer nenhum comentário ou explicação de qualquer tipo, ele é descritivo e leva a apenas uma conclusão.
Nomes incomuns, ou fora das regras do código de conduta, podem causar conflitos, podem ser difíceis de serem entendidos. Hoje em dia, com o uso de IDE’s e Editores de Código, a tecnologia pode ser usada A FAVOR ou CONTRA, a maioria deles permite que o desenvolvedor localize uma estrutura seja ela uma classe, um método ou uma variável de maneira automática, o que pode facilitar a localização. Porém, pode ser um pesadelo, facilitando uma falha de nomenclatura ou criando dependências lógicas desnecessárias.
Faça uso das boas práticas, não das ferramentas, elas existem para te auxiliar, algumas até permitem que você defina regras para nomenclaturas corretas, porém, o bem senso ainda é a melhor opção.
Faça distinções significativas É importante ter nomes distintos no contexto e na estrutura. Por razões óbvias, não queremos confundir o contexto e o significado de uma variável / função com a outra. No entanto, eles também não devem ter um nome muito semelhante. Por isso o recurso de preenchimento automático em todos os editores de código também deve ser levado em consideração. Ter nomes muito semelhantes está sujeito a erros de auto-sugestão, leitura inadequada e, conseqüentemente, funções incorretas sendo chamadas.
Use a busca e veja os resultados, não dê nomes muito curtos (VR – ValeRefeicao, MED – MedicosPlantao), não use palavras chave da linguagem como parte do nome (returnMedicos – HorarioRetornoAlmocoMedicos, forSale ProdutosDisponiveisVenda), nomes fora do contexto ou escopo (contador – ProfissionalContabilidade, variavelMedicos / funcaoMedicos – Medicos/GetMedicos), ou que possam causar ambiguidade (contato – ContatoPaciente, Salvar() – SalvaDadosContatoCliente() ). Por isso, use a ferramenta de pesquisa global da sua IDE e veja os resultados, não busque somente o nome inteiro use buscas parciais e você vai aprender que é mais fácil do que parece.
Sem Mágica ou Resultados Fantásticos
Quando você precisa codificar valores FIXOS, use constantes. Imagine uma situação onde seu código informa quais médicos precisam entregar este ano o seu certificado de reciclagem profissional, que deve ser entregue entre 30 e 36 meses de exercício da função.
Notou que os valores 30 e 36 podem acabar por serem escritos literalmente, agora imagina que 5 anos depois essa regra muda, você tem que pesquisar diversos lugares para alterar.
Valores mágicos são valores que aparecem “magicamente” no código e supostamente transmitem algum significado, mas ninguém pode dizer, já que são apenas números / strings. Evite espalhar valores mágicos por todo o código a todo custo. Certifique-se de atribuir uma variável ou constante a esses valores para clareza e fácil refatoração.
Não Externe a Implementação do Código ou Crie Padrões Exclusivos
A maneira como implementamos o código difere de tempos em tempos e se transforma completamente, até mesmo em forma de uma ou de outra linguagem de programação. Vincular uma determinada forma de implementação é restritivo e, na verdade, se tornará obsoleto com o passar do tempo.
Não é incomum hoje em dia partes do código serem desenvolvidos em uma ou outra linguagem, e compartilhada através de uma API ou de outros métodos, se você cria uma forma de implementação única, dificilmente conseguirá expandir ou escalar ou mesmo integrar essa implementação com o mundo externo.
Exceto por razões muito específicas, ou acadêmicas, ou se você trabalha para uma entidade de padronização ou uma mega empresa mundial, ou órgão governamental, prefira externar dados e informações de maneira independente ou utilizando padrões já conhecidos e que possam ser mais facilmente explicados ou utilizados.
Cuidado com as convenções
Para profissionais mais experientes, que já estão em um nível de desenvolver uma convenção ou código de conduta e de trocas de dados ou regras de codificação, você deve prestar atenção no nível que sua equipe se encontra, não podemos transformar a água em vinho de uma hora para outra.
Devemos ir gradualmente cobrando as mudanças, treinando nossa equipe, um passo de cada vez, ao receber novos membros, devemos deixar claro as regras que devem ser seguidas e ir moldando e adequando conforme a maturidade total da equipe.
As convenções possuem uma validade indeterminada, mais não são eternas, elas podem ir sendo alteradas para ir se adequando a realidade atual, períodos de transição devem existir e cabe ao profissional experiente fazer a mediação do que é realmente necessário e em que ponto estamos. Se devemos avançar mais um passo ou se manter, ou até mesmo se demos um passo muito grande, se não é hora de regredir um pouco.
Simplicidade – Menos é Mais em Alguns Casos
Quando falamos de regras, criar um conjunto com poucas de grande abrangência, é muito mais fácil do que ter uma lista de 612 condutas estritas a serem seguidas. Por exemplo:
-Adotamos a notação de nomenclatura CamelCase.
Ao invés de: Adotamos CamelCase no nome de classes, snake_case em nomes de métodos, tpNotacaoHungara em nomes de variáveis e dromedaryCase para processos externos.
Além disso, os nomes devem refletir a realidade, ser consistentes e descritivos o suficiente para evitar qualquer necessidade de um mapeamento mental ou memorização de qualquer tipo.
Divida em Partes Pequenas
Pequenas funções ou blocos ajudam você a contar a história corretamente. Eles adicionam ordem, separação de interesses, abstração adequada e estrutura correta para seu código. Se sua função não for pequena, provavelmente não está seguindo outros princípios cruciais, pequenas funções, quando nomeadas corretamente, tornam o código claro, fácil de depurar e simples de seguir.
Quão pequeno? Depende, a experiência diz que quanto menor é melhor, não existe um limite rígido. Quando estamos lidando com uma complexidade maior, geralmente podemos ir refatorando e sempre ter problemas menores.
No livro Clean Code, Uncle Bob, diz rigidamente um número de 20 instruções. Esse número serve como um alerta, que talvez ali caiba uma refatoração. Em relação ao número exato, tenha certeza de que é apenas uma bandeira vermelha para nos manter alertas se escrevermos funções grandes.
Uma coisa de Cada Vez
As funções devem fazer uma única coisa e apenas uma coisa. Às vezes, é muito difícil ter certeza de que ela faz somente isso, mas é um princípio importante ter certeza de que não estamos fazendo várias coisas ao mesmo tempo.
Se fazem coisas diferentes, quebre e cada uma deverá fazer uma única coisa.
Bois Devem ter Nome de Boi, Gatos de Gatos!
Todas as funções realizam ações, esse é o propósito delas, ao nomear funções, eles devem ter verbos que implicam o que fazem, por exemplo getMedicosDisponiveis() ou setMedicoDisponivel(), removeMedicoDisponivel() e por ai vai.
Uma exceção comum, entretanto, que é amplamente conhecida, é a palavra is– para verificar se há uma condição booleana. A convenção é que a função deve retornar um booleano em relação à condição.
Minimize o Numero de Argumentos
Idealmente, quanto menor o número de argumentos, melhor. No entanto, se quisermos tornar nossas funções reutilizáveis e independentes de qualquer outra lógica de negócios, podem ser necessários.
Novamente não existe um limite rígido, em geral, de 2 a 3 argumentos são suficientes, porém, podem haver casos onde seja necessário um número maior. Se possível, use os argumentos essenciais primeiro, e valores padrão para os demais.
A ideia por trás desse princípio é que as funções são muito pequenas, então se você precisa de 3 argumentos que são vitais para a lógica do negócio, provavelmente a dissociação de uma grande função foi mal feita. Ou seja, a lógica está fortemente ligada e talvez a separação em um ponto diferente no código seja melhor.
Cuidado com Efeitos Colaterais
As funções não devem ter quaisquer efeitos colaterais ou implicações em outros processos, além de sua responsabilidade principal. Como a regra “Faça uma coisa” sugere, ele não deve fazer nada além de sua tarefa designada.
Isso ajuda a evitar surpresas, é mais fácil depurar e controlar exatamente o que faz o quê.
A maneira limpa de escrever funções
Vamos admitir. É muito difícil escrever funções que sigam esses princípios em nossa primeira tentativa. Provavelmente vamos pensar demais e planejar muito mais do que precisamos para conseguir isso no início.
Mas a verdade é que não deveria ser perfeito na primeira vez que escrevemos o código. Assim como na escrita, a codificação tem suas camadas, rascunhos, refinamentos (refatoração) e desenvolvimento até ficar nítida e brilhante.
Classes Também Devem Ser o Menor Possível
As classes devem seguir o mesmo princípio das funções – torne-as o mais pequenas possível. Há, no entanto, uma pequena distinção as classes podem fazer mais de uma coisa. Eles provavelmente farão mais de uma coisa na maioria das vezes. Dito isso, eles devem seguir o Princípio de Responsabilidade Única. Ou seja, tudo o que elas fizerem deve estar relacionado entre si.
É aqui que a separação de interesses é uma preocupação real, como desenvolvedores, devemos ter certeza de que as classes têm apenas uma responsabilidade. Responsabilidade é um termo que, neste contexto, significa um motivo para mudar.
Deve haver apenas um motivo para a mudança de classe, se vários motivos podem fazer com que a classe mude, isso significa que a classe tem muitas responsabilidades. Essa é uma maneira concisa de garantir que a classe tenha uma única responsabilidade.
Coesão
Quão bem a lógica dentro de uma classe está relacionada? Existem pontos de conexão dentro delas? Os métodos são bem implementados com a lógica? Esta tudo no lugar adequado?
Um bom indicador, que pode ajudar neste caso é responder a essas perguntas. Outro é o número de variáveis de instância em uma classe, idealmente, preferiríamos reduzir o número de variáveis de instância e usar cada uma delas nos métodos da classe, isso é a coesão em uma classe.
Os métodos são fortemente relacionados à classe, eles usam as variáveis de instância e a lógica é cultivada e usada por todos os métodos. Este é um forte indicador de que todos os métodos e preocupações estão no lugar certo.
Fale Pouco, mais fale bem
Os comentários no código, excluindo os de aspectos técnicos, devem ser mitigados tanto quanto possível. Eles são difíceis de manter, e geralmente tentam encobrir um código que não é limpo o suficiente.
Se você sentir necessidade de escrever um comentário que explique o que o código faz, isso deve levantar uma bandeira vermelha e você deve examinar o seu código e certificar-se de que está limpo o suficiente.
Não estamos nos referindo a comentários que fazem parte da documentação por exemplo de uma biblioteca, nem a comentários técnicos de licenciamento, ou mesmo os comentários sobre dados de uma função.Hoje, muitas IDEs precisam de comentários documentais, para realizar ações dentro do código, auxiliar no autocomplete do código etc, esses são os comentários que obrigatoriamente devem existir.
Os comentários devem ser mitigados. O princípio básico é que, se você precisar explicar o que o código faz, ele não é claro o suficiente. O código deve se explicar por si mesmo. Deve ser autoexplicativo para que outros colegas revisem. Comentários de código de podem existir, podem ser relacionados a um aspecto técnico ou lógica do negócio, por exemplo.
Entenda o algoritmo
Compreender o algoritmo é uma etapa crucial para escrever um código limpo. Além das razões óbvias pelas quais precisamos entender o algoritmo, é através dele que vamos nos basear o real proposito do nosso código.
Se investirmos tempo no aprendizado do algoritmo e nos certificando de que conhecemos suas complexidades, seremos capazes de desconstruí-lo em partes menores. A partir daí, o caminho para escrever código limpo é bastante simples.
Cuidado com os níveis de abstração
Um nível de abstração é um conceito importante a ser considerado ao planejar e escrever código. Enquanto escrevemos uma função, consideramos onde ela se encontra no grande esquema da solução completa.
É uma função de alto nível intimamente relacionada ao algoritmo? Ou é uma função responsável por uma finalidade de utilidade como analisar uma linha de comando, verificar condicionais, realizar certos cálculos?
O princípio do nível de abstração é outra maneira de garantir que estamos mantendo todas as nossas funções e classes no lugar em que devem estar e fazendo apenas uma coisa. Se uma função mistura níveis de abstração, definitivamente está fazendo mais de uma coisa.
Para ser prático, sempre começaremos com as funções de nível superior que estão no nível mais alto de abstração. Cada função deve descer apenas um nível abaixo enquanto chama a outra função.
A orquestração de toda a lógica. Verificação de limites, tratamento de erros, análise, cálculos – eles estão em um nível diferente de abstração. Eles devem ser extraídos para funções diferentes, cada uma lidando com seu próprio nível de abstração.
Porque não é sua responsabilidade, uma função obtém uma entrada e retorna uma saída após fazer as operações. Pode haver erros? excelente, eles não são sua responsabilidade, ou ela retorna um sucesso ou uma indicação de que algo não saiu como esperado.
Como provavelmente entendemos, não é seu trabalho registrar o erro. Seu trabalho é lidar com o erro – chamar as funções relevantes no próximo nível inferior de abstração e repassar as informações, simples né.
Palavra final: seja consistente
Para concluir, acredito que esta seja uma receita para código limpo e ser um grande programador. Todo mundo tem seu próprio estilo, ponto de vista único e uma abordagem diferente para resolver problemas.
Portanto, ser consistente com todos os princípios mencionados neste artigo é a chave para escrever um código sustentável, reutilizável, claro e limpo.
Invista em realizar sempre o seu melhor, se você aceita um trabalho medíocre, significa que você é um profissional medíocre, portanto, almeje e exija sempre o melhor, em qualquer nível que você esteja. Sinta orgulho de tudo aquilo que você faz, sempre. Espero ter ajudado, se ficou alguma dúvida, não exite de me contactar pelas redes sociais.
