DEV Community: Fernanda Leite

Regra 7: Elimine casos de falha

Fernanda Leite — Wed, 02 Oct 2024 01:58:03 +0000

Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Em cada post falo um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

O quanto estou tornando difícil para os usuários de um recurso ou interface cometerem um erro? Este capítulo sugere que essa deve ser a principal pergunta ao projetar softwares.

A ideia de criar sistemas onde seja impossível cometer erros pode parecer utópica. Afinal, os usuários sempre encontram maneiras inesperadas de provocar falhas. Então, qual é a solução?

Zimmerman propõe que, em vez de aceitarmos falhas como inevitáveis, devemos projetar nossos sistemas de modo que elas raramente — ou nunca — ocorram. Embora essa abordagem pareça simples à primeira vista, sua implementação exige disciplina e um compromisso com boas práticas de programação.

Um dos principais pontos deste capítulo é adotar uma programação "defensiva" — prevenir falhas antes que aconteçam. Em vez de depender de blocos de "try-catch" para tratar erros, devemos evitá-los, validando entradas, assegurando pré-condições e simplificando o código. Essas medidas são cruciais para minimizar estados de erro.

Essa ideia é especialmente relevante em sistemas complexos, onde exceções e falhas aumentam a complexidade, dificultando a manutenção e depuração do código. Zimmerman enfatiza que falhas previsíveis não devem ser tratadas como exceções, mas integradas ao fluxo normal do programa. Dessa forma, o código se torna mais robusto, legível e fácil de manter.

Um ponto essencial na criação de interfaces seguras é detectar erros de uso o quanto antes. No pior cenário, o uso inadequado passa despercebido, levando a uma cascata de falhas na interface. No melhor cenário, o design impede que erros sequer ocorram.

Entretanto, é importante lembrar:

"Um erro comum que cometemos ao tentar projetar algo totalmente infalível é subestimar a ingenuidade de pessoas falíveis."

Em conclusão, não existe um design perfeito. Podemos impedir que o usuário cometa erros diretos, mas os efeitos colaterais são difíceis de eliminar. Nosso objetivo deve ser criar um design que facilite o uso correto e dificulte que algo dê errado.

Regra 6: Revisões de código são boas por três razões

Fernanda Leite — Mon, 23 Sep 2024 14:10:48 +0000

O Code Review é uma prática amplamente difundida na área de desenvolvimento de software, mas ainda há programadores que se sentem desconfortáveis ou inseguros com a ideia de ter seu código revisado por outra pessoa, como se isso representasse uma invasão de privacidade.

Vamos explorar a importância das revisões de código e como elas impactam diretamente nosso dia a dia, sob uma perspectiva um pouco diferente.

"O valor das revisões de código depende do tempo e esforço investidos nelas, e de como elas são conduzidas."

A razão mais óbvia para adotar a prática de Code Review é a identificação de bugs. Mas será que isso é realmente o mais importante? Esse livro destaca que para que a revisão seja eficaz, é necessário um processo consciente, onde o revisor tenha conhecimento ou até mesmo domínio sobre o código. Só assim ele será capaz de identificar possíveis problemas na implementação. Além disso, a revisão deve ser um diálogo. O livro afirma que o debate entre as partes é essencial para que todos compreendam os diferentes pontos de vista e sugiram melhorias de maneira mais assertiva.

"As revisões de código encontram bugs, mas não encontram todos."

Embora identificar bugs seja uma boa razão para revisar código, não é a única, nem a mais importante. A seguir, veremos outras razões igualmente relevantes.

Quando realizadas corretamente, as revisões são uma excelente ferramenta para disseminar conhecimento na equipe. Esse é um dos pontos mais importantes. Mas o que significa "corretamente"? O autor divide os programadores em duas categorias: sênior (aqueles que têm domínio sobre o código) e júnior (aqueles que ainda estão se familiarizando com o funcionamento do código). Segundo ele, existem três combinações entre revisores que trazem bons resultados:

Sênior revisando código de Júnior: Nessa combinação, o programador sênior não apenas busca bugs, mas também aponta falhas na qualidade ou desvio de padrões que o júnior pode não ter percebido.
Júnior revisando código de Sênior: Aqui, o júnior pode não encontrar muitos bugs, mas ao fazer perguntas ao sênior, ele compreende melhor o contexto e aumenta seu conhecimento sobre o código.
Sênior revisando código de outro Sênior: Essa combinação aumenta a probabilidade de encontrar bugs, além de gerar discussões sobre melhorias, testes adicionais e o futuro do projeto.

Por que um júnior não deve revisar o código de outro júnior? Em muitos casos, esse processo não traz benefícios significativos, pois há pouca transferência de conhecimento e menos contexto para identificar problemas.

"Qualquer pessoa escreve código melhor quando sabe que será revisado."

De acordo com Zimmerman, a razão mais importante para as revisões de código é de natureza social. Quando sabemos que outra pessoa vai analisar nosso código, há uma pressão positiva que nos leva a "caprichar". Seguimos os padrões com mais rigor, evitamos deixar tarefas pela metade e procuramos soluções mais completas. No fim, nos esforçamos para escrever um código do qual nos orgulhamos de compartilhar.

"As revisões de código são inerentemente sociais."

Em conclusão, revisões bem conduzidas são cruciais por três motivos: ajudam a encontrar bugs, disseminam conhecimento e promovem a escrita de código de qualidade. Elas devem ser um processo colaborativo, onde o diálogo é a chave para uma revisão eficaz, com ambas as partes dispostas a aprender e a escutar.

Um processo de revisão saudável fortalece tanto a base de código do projeto quanto as conexões da equipe.

Regra 5: A primeira lição para a otimização é não otimizar

Fernanda Leite — Tue, 20 Aug 2024 01:12:11 +0000

Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Falarei um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

Alguns programadores são verdadeiros fãs da otimização, geralmente isso tem a ver com fazer um sistema ser executado com mais rapidez. O motivo para isso é simples, é fácil medir o sucesso de uma tarefa como essa.

"Devemos nos esquecer de pequenas eficiências, digamos, cerca de 97% do tempo a otimização prematura é a reais de todo o mal." - Donald Knuth, 1974

É instintivo que os programadores se preocupem com os recursos, seja tempo, armazenamento ou largura de banda - e isso pode levar a tentativas de resolver problemas de desempenho antes que eles surjam.

Lições da otimização

A primeira lição da otimização é: não otimize. Simplifique o código o máximo possível, não se preocupe com a rapidez dele.

A segunda lição complementa a primeira: é fácil tornar um código simples rápido. Provavelmente na primeira vez que você examinar esse código vai entender claramente o que precisa ser otimizado. O autor ainda complementa dizendo que se você nunca otimizou algum trecho do código, pode torná-lo de 5 a 10 vezes mais rápido sem muito trabalho.

A terceira lição é interessante: não se preocupe se cometer erros, porque não haverá erros que você não possa corrigir. Erros complexos (que atrapalham os desempenho) não esperam para aparecer, então não se preocupe com isso. Eles serão óbvios.

5 etapas para otimização

Etapa 1: meça e atribua o tempo do processador

Meça quanto do tempo do processador está sendo gasto e atribua-o ás funções, aos objetos ou ao que for conveniente. Identifique o que está forçando seu navegador.

Etapa 2: verifique se não é um bug

É muito comum descobrirmos que o que parece um problema no desempenho na verdade é um bug. Se esforce para encontrá-los.

Etapa 3: avalie seus dados

A maioria das otimizações explora algum aspecto dos dados ou de como eles estão sendo usados. Você não conseguirá tomar boas decisões sobre otimização sem conhecer totalmente a forma de seus dados. Procure de onde vem o problema.

Etapa 4: planeje e crie um protótipo

Não comece a trabalhar em uma otimização até saber que ela faz parte de um plano que pode ser bem sucedido. Procure uma oportunidade de prototipar sua otimização. Crie uma versão "perfeita" para testar.

Etapa 5: otimize e repita

Após terminar as 4 primeiras etapas, você poderá começar a pensar em otimização. Já terá desenvolvido uma noção de quanto custarão várias partes do código, de acordo com o nível de lógica envolvido e com o volume de memória que será acessado. Talvez parte desse código ou do acesso à memória possa ser simplificado ou ignorado. Se não houver maneira simples de acelerar o código, procure algo que você possa explorar nos dados.

Não otimize de imediato, faça um plano.

Conclusão

Não é fazendo a mesma coisa mais rápido que melhoramos o desempenho. A maneira de tornar o código mais rápido é fazendo menos. Descubra o que o código está fazendo que não precisaria ser feito ou o que ele está fazendo várias vezes que poderia ser feito uma vez. Elimine esses trechos de código e tudo ficará mais rápido.

O autor conclui dizendo: "Confie nas lições da otimização. Escreva código simples e claro e esteja certo de que soluções aparecerão para qualquer problema de desempenho que você encontrar."

Regra 4: A generalização demanda três exemplos

Fernanda Leite — Wed, 31 Jul 2024 12:45:10 +0000

Como programadores, é comum, quando estamos resolvendo um problema ou implementando uma nova funcionalidade, pensar em todos os pequenos casos de uso que achamos que vão ser úteis para só então começar algum código que resolva tudo de uma vez. Pensamos "É melhor escrever uma função que resolva dois problemas do escrever funções separadas para cada problema."

Vamos a um exemplo: encontrar placas.

Inicialmente temos apenas um caso de uso, encontre placas vermelhas. Nesse momento podemos pensar "E se tivermos que encontrar placas com mais cores? Ou com mais de uma cor? Será que podemos encontrar placas pela localização? Ou pelo texto da placa?", essas e muitas outras perguntas e ideias podem surgir o que nos levará a projetar uma solução que atenda tudo isso de uma vez (mesmo que não esteja descrito no nosso único caso de uso).

A grande questão desse tipo de solução é que em nosso primeiro contato com problema não temos muitos exemplos nos quais nos basear, então apenas prevemos os possíveis casos de uso que poderíamos resolver... e provavelmente essas previsões estarão erradas.

Voltando ao exemplo, vamos supor que agora temos um novo caso de uso: encontrar placas vermelhas e encontrar placas em São Paulo.

Ao ler esses casos de uso, poderíamos dizer que fizemos um bom trabalho ao prever e projetar uma solução que resolve tudo. No entanto, vemos que algumas coisas sobraram, como encontrar pelo texto ou por mais de uma cor; ou seja, resolvemos casos que não estão ocorrendo na prática.

Existe um padrão comum utilizado na programação extrema chamado YAGNI, ou "You Ain't Gonna Need It" (Você não vai precisar disso). Resumindo, muito do que projetamos inicialmente foi apenas desperdício de tempo.

A primeira lição que o livro traz é "Nenhuma solução genérica é previsível após um único caso de uso, logo é um erro tentar escrever uma.". Não tente adivinhar qual será o segundo caso de uso. Escreva códigos para resolver problemas que você conhece e não para os que acha que ocorrerão.

Uma objeção a essa estratégia poderia ser "E se os nossos casos de uso aumentarem, teremos o retrabalho de projetar tudo novamente?". O autor dá uma resposta a isso "Não desperdice seu tempo. Quando surgir um caso de uso que seu código não manipule, escreva um código para manipulá-lo.". Resumindo: refatore.

Então, quando podemos generalizar algo? O nosso ponto de inflexão passa a ser quando temos pelo menos três casos de uso independentes. Nesse momento podemos prever com mais clareza quais poderiam ser o quarto e o quinto casos. A generalização não é obrigatória, mas começa a fazer sentido.

"Só generalize se achar que isso tornará o código mais fácil de ler e escrever, baseando-se apenas nos casos de uso que tiver em mãos. Nunca generalize porque está preocupado com o próximo caso de uso.", essa é a segunda lição desse livro pra mim.

Outro problema que pode ocorrer devido à generalização é a perda do contexto inicial. Começamos a utilizar uma única solução para resolver tudo, apenas estendendo o que ela faz. Ela vai ficando cada vez mais complexa, dificultando atender novos requisitos ou suportar grandes mudanças.

O livro termina dizendo "Quando seguramos um martelo, tudo se parece com um prego, certo? Quando criamos uma solução genérica, estamos fornecendo martelos. Não o faça até ter certeza de que possui pregos em vez de parafusos." e a última lição que eu tiro disso é utilize a estratégia certa para resolver uma problema de forma eficaz.

A tentativa de prever e resolver todos os possíveis casos de uso desde o início de um projeto de programação pode parecer uma abordagem inteligente, mas muitas vezes leva ao desperdício de tempo e recursos. O princípio YAGNI nos ensina que devemos focar nas necessidades imediatas e evitar a complexidade desnecessária. Ao resolver problemas conhecidos e refatorar conforme novos casos de uso surgem, podemos criar soluções mais eficientes e flexíveis.

Generalizar prematuramente não apenas complica o código, mas também pode nos desviar do contexto original do problema, tornando mais difícil atender novos requisitos. Assim, é crucial encontrar o equilíbrio entre a simplicidade inicial e a capacidade de adaptação futura.

Lembre-se, a programação eficaz não é sobre prever todos os possíveis problemas, mas sim sobre criar soluções claras e concisas para os desafios atuais. Ao aplicar essas lições, podemos escrever códigos mais limpos e manter um desenvolvimento de software ágil e eficiente.

Regra 3: Um bom nome é a melhor documentação

Fernanda Leite — Wed, 24 Jul 2024 12:24:24 +0000

Esse capítulo já começa nos fazendo refletir com essa pequena citação de Shakespeare, mais especificamente da peça Romeu e Julieta:

"O que há em um nome? O que chamamos rosa
Teria o mesmo cheiro com outro nome"

Ainda existem programadores que defendem uma ideia parecida com essa, de que o nome não importa e sim o que foi nomeado. Então surgem variáveis como var n ou funções com nomes nada descritivos e sem nenhum padrão.

O nome de algo é a documentação mais importante que temos. Ele deve conter o que é importante sobre o elemento, ou seja, se for nomear uma variável o nome deve mostrar o que ela representa. Já se for nomear uma função o nome deve mostrar o que ela faz.

Abaixo temos alguns tópicos que podem ajudar nesse processo.

Não otimize usando menos pressionamento de teclas

Nosso código é lido muito mais do que é escrito. Isso quer dizer que outras pessoas que entrarem em contato com o que escrevemos não saberão o contexto no qual escrevemos uma função com o nome function sd () { ... } por exemplo. Como consequência elas gastarão muito mais tempo tentando entender o que aquele trecho faz.

Evite nomes curtos demais!

Não misture convenções

A segunda maneira de os nomes não ajudarem é devido à inconsistência. Podemos facilmente nos confundir quando não temos regras definidas para nomear elementos, como por exemplo: nomes em português ou inglês? devo usar camelCase ou snake_case? Essas são algumas das dúvidas que podem surgir tanto para quem escreve quanto para quem lê.

O mais importante é escolher as convenções que fazem sentido com seu projeto e que se integrem bem com as bibliotecas externas que você utiliza.

O livro traz outro ponto interessante "elementos semelhantes, nomes parecidos", dessa forma ao percorrer diferentes trechos do código será fácil identificar o que aquele elemento é ou faz.

Não me faça pensar

Tudo que dependa de uma tomada de decisão ou um raciocínio cuidadoso de alguém está sujeito as experiências dessa pessoa. O que quero dizer com isso é que em relação a convenções e regras não podemos deixar diferentes programadores tomarem suas próprias decisões, pois cada um vai decidir de acordo com aquilo que lhe parece melhor.

O segredo da consistência é tudo ser o mais mecânico possível. Devemos deixar nossas regras bem documentadas e utilizar ferramentas que automatizem esse processo. Com isso todos utilizam um mesmo padrão e quando trabalhamos com o código de outra pessoa parece que estamos trabalhando com nosso próprio código.

Pra finalizar o conselho do livro é _"Descubra quais das convenções de projeto você pode tornar mais mecânicas e faça isso. Você colherá os frutos durante muitos anos."
_

Regra 2: Bugs são contagiosos

Fernanda Leite — Tue, 16 Jul 2024 15:16:58 +0000

Segundo o dicionário de Oxford, esta é a definição de bug: defeito, falha ou erro no código de um programa que provoca seu mau funcionamento. Fica claro por essa definição que o bug é algo que atrapalha o funcionamento de um software levando a consequências como um sistema inutilizável, a perda de credibilidade com usuários e até mesmo a perda de dinheiro em situações mais graves.

Por que os bugs são contagiosos? A partir do momento que existe um bug acabamos (sem querer ou sem saber) escrevendo código dependente dele e então criamos um emaranhado de problemas. A melhor maneira de interromper esse contágio é eliminando os bugs o mais cedo possível, antes que sua influência maligna possa se alastrar.

O livro traz algumas sugestões de como podemos evitar esses problemas. Primeiramente ele relata como não podemos depender dos usuários do sistema para identificar os bugs, pois nem sempre eles percebem os problemas e quando percebem podem pensar é aquilo é uma resposta natural do sistema. Logo uma das maneiras mais adequadas como "primeira defesa" contra os bugs são os testes automatizados contínuos.

Sobre os testes o autor diz: "De modo geral, a ideia é a de que o sistema (ou melhor, o projeto inteiro) tenha um conjunto de testes que você possa executar de maneira rápida e conveniente para colocá-lo totalmente em funcionamento e detectar problemas.". Através dessa estratégia qualquer bug encontrado poderá ser rapidamente corrigido.

Escrever testes pode custar caro e demandar tanto tempo quanto escrever o próprio código, mas o custo de resolver possíveis problemas no sistema completo do futuro é muito maior.

Porém nem todo sistema é totalmente testável, muitas vezes existem varias dependências ou casos em que não sabemos como medir o sucesso daquele código. Pra esses momentos o conselho é "Teste o que puder, controle o que puder e lembre-se de que não está testando tudo.", ou seja, qualquer parte do código que não for coberta por seus testes automatizados terá quer ser testada manualmente. Planeje isso!

Outra boa sugestão do livro é estruturar o código para torná-lo mais fácil de testar. Uma estratégia importante é a redução da quantidade de informações de estado no código. Esse tipo de código (stateless) além de ser mais fácil de testar é também mais fácil de criar. Sempre que possível utilize funções puras (uma função que só depende de suas entradas diretas, não tem efeitos colaterais e tem resultados previsíveis)

Se não puder eliminar estados, audite seus dados.

Pra finalizar nas palavras do autor "Um código mais fácil de testar - ou, melhor ainda, que teste a si mesmo continuamente - permanece íntegro por mais tempo. Isso significa menos problemas para corrigir e correções mais fáceis de fazer quando forem necessárias.".

Regra 1: O mais simples possível, mas não mais simples do que isso

Fernanda Leite — Wed, 10 Jul 2024 01:07:51 +0000

Uma das habilidades mais necessárias como programador é a capacidade de abstrair o problema e encontrar possíveis soluções. Eu acredito que esse é o ponto chave dessa regra: pensar no problema.

O autor diz “(…) a melhor maneira de implementar uma solução para qualquer problema é a mais simples que atenda a todos os requisitos desse problema.”. Fica obvio por essa frase que abstrair o problema é essencial. Compreender todos os desdobramentos, requisitos e até avaliar a sua complexidade.

Essa investigação sobre o problema pode nos mostrar que não existe uma solução simples para uma definição ampla do mesmo, mas se o quebrarmos em pequenos pedaços podemos encontrar soluções simples e que resolvam a parte do problema que realmente precisa ser resolvida. Sobre isso o autor diz “Se não conseguir simplificar a solução, tente simplificar o problema”.

É melhor que o código seja mais simples (desde que resolva o problema), mas como avaliar essa simplicidade? Existe um limite pra isso? O livro expõe 3 critérios básicos para a avaliação da simplicidade: quantidade de código escrita, quantas ideias foram introduzidas e quanto tempo seria necessário para explicá-lo (facilidade de criação e facilidade de compreensão).

Particularmente acho que o primeiro critério não deve ser uma “regra”, nem sempre o código que possui menos linhas é o mais simples. Muitas vezes ele causa uma dificuldade de compreensão do que está sendo feito naquele trecho devido a suas implementação extremamente resumida. Uma boa abstração desses critérios é “Um código simples é fácil de ler - e um código mais simples pode ser percorrido totalmente do início ao fim, como lemos um livro.” como o próprio autor diz.

Pra finalizar, quanto mais complexo fica o código mais difícil fica trabalhar com ele e progredir se torna cada vez mais lento. Sempre que puder procure oportunidades para remover complexidade ou projete soluções de forma que novos recursos não aumentem a complexidade do inicial. Faça sua equipe trabalhar em conjunto da forma mais simples possível.