paint-brush
Código e a arte da manutenção de motocicletas: falhas típicas de novatospor@shcherbanich
169 leituras

Código e a arte da manutenção de motocicletas: falhas típicas de novatos

por Filipp Shcherbanich7m2024/08/16
Read on Terminal Reader

Muito longo; Para ler

A codificação é, na verdade, uma motocicleta, uma muito potente e rápida. Com a codificação, assim como com a pilotagem, você precisa ser responsável e consciente para permanecer no selim e dobrar isso para ser um vencedor. Neste artigo, quero compartilhar meus pensamentos sobre o que tanto os desenvolvedores novos quanto os experientes devem lembrar ao criar software.
featured image - Código e a arte da manutenção de motocicletas: falhas típicas de novatos
Filipp Shcherbanich HackerNoon profile picture
0-item


Codificar é fácil, dizem, é como andar de bicicleta. Bem, programar é na verdade uma motocicleta, uma muito potente e rápida. Com a codificação, assim como com a pilotagem, você precisa ser responsável e consciente para permanecer no selim e dobrar isso para ser um vencedor. De fato, pilotos e programadores compartilham os mesmos erros de novato: os neófitos geralmente tendem a se concentrar em ferramentas rápidas e poderosas e truques inovadores, acreditando que isso por si só define um verdadeiro mestre. Essa mentalidade se deve em parte ao "efeito Dunning-Kruger", onde os novatos não conseguem entender a complexidade e o significado de sua profissão. Felizmente, com a experiência, até mesmo o iniciante mais fervoroso percebe que a arte da programação envolve muito mais do que apenas selecionar o algoritmo ideal. Neste artigo, quero compartilhar meus pensamentos sobre o que realmente importa para um programador e o que os desenvolvedores novos e experientes devem lembrar ao criar software e escrever código.

Legibilidade acima do desempenho, mas nem sempre

Com o que os motociclistas novatos típicos começam? Números e gadgets. Potência, torque, peças de desempenho para morder milissegundos teóricos em um quarto de milha... Como se estivessem prestes a entrar no grid de largada da MotoGP. Enquanto isso, sua tarefa principal é apenas aprender a pilotar com segurança. De forma semelhante, os desenvolvedores iniciantes geralmente ficam fixados no desempenho do código onde ele é desnecessário. Artigos debatendo se `dict()` ou `{}` é mais eficiente em Python, ou os prós e contras de usar frameworks apesar de seu potencial para diminuir o desempenho, alimentam essa obsessão. Embora entender as complexidades da sua linguagem de programação seja benéfico e às vezes crucial - como em software para aviões, robôs de negociação de ações ou dispositivos médicos - nem sempre é crítico para a maioria dos programas que criamos diariamente. Mesmo se você estiver trabalhando em software crítico de desempenho, é essencial saber quais partes do código exigem alto desempenho e quais não.


O que sempre importa, no entanto, é a legibilidade do código. Vários estudos e pesquisas confirmam que os desenvolvedores passam mais tempo lendo e entendendo o código do que escrevendo-o. Por exemplo, o estudo "Eu sei o que vocês fizeram no verão passado - Uma investigação sobre como os desenvolvedores gastam seu tempo" descobriu que apenas 4% do tempo gasto em um IDE é usado para edição de código. Relatório de tempo de código global , com base em uma pesquisa com mais de 250.000 desenvolvedores, revelou que os entrevistados gastam apenas cerca de 52 minutos por dia escrevendo código ativamente. O resto do tempo é gasto discutindo e planejando o projeto, com cerca de 41 minutos dedicados à leitura de código no IDE e à documentação do projeto.


Na maioria dos casos, nosso objetivo é criar um produto sustentável que não exija suporte complexo e prospere em um ambiente competitivo. Isso não significa que podemos ignorar completamente o desempenho; precisamos encontrar um equilíbrio em que a manutenibilidade e o desempenho coexistam. Se for necessário um código de alto desempenho, podemos otimizar seções lentas após o lançamento do projeto.


Também tenha em mente que compiladores e interpretadores evoluem, mas seu código permanece o mesmo. Um trecho de código mágico super-hiper-otimizado escrito para uma versão do compilador pode se tornar um fracasso irrelevante para outra. Além disso, futuros desenvolvedores — ou até mesmo você — precisarão trabalhar com esse código. Então, quando devemos sacrificar a legibilidade pelo desempenho?


Identificar quando priorizar o desempenho em detrimento da legibilidade envolve identificar gargalos em seu aplicativo:


  • Criação de perfil do aplicativo : se a criação de perfil revelar que seções críticas específicas do código impactam significativamente o desempenho, a otimização desses fragmentos pode justificar a redução da legibilidade.

  • Teste de carga : simular altas cargas pode ajudar a identificar gargalos de desempenho antes que eles se tornem problemas reais.

  • Análise de feedback do usuário : coletar feedback dos usuários pode destacar áreas com desempenho ruim.

  • Logging e monitoramento : analisar logs de execução e métricas pode identificar áreas problemáticas durante a operação do aplicativo no mundo real. Este estágio pode revelar problemas inesperados, como uso impróprio de API causando problemas de desempenho.

  • Ferramentas de Análise de Código Estático : Algumas ferramentas podem sugerir melhorias de desempenho durante revisões de código. Executar essas ferramentas automaticamente durante revisões de tarefas é uma boa prática.


Essas dicas podem ajudar a identificar os pontos fracos do seu aplicativo, permitindo que você se concentre nas otimizações necessárias. Com base na minha experiência pessoal, essas otimizações têm menos probabilidade de envolver construções de linguagem exóticas e mais probabilidade de envolver a otimização de interações de banco de dados ou uso de API externa.

A documentação ajuda a entender o trabalho realizado

Ao sair na estrada, uma das habilidades cruciais de segurança é ser previsível e, da mesma forma, ler as intenções dos outros. Na codificação, assim como na pilotagem, você não pode ler diretamente a mente de outras pessoas. Em duas rodas, você tem que perceber movimentos sutis e prever o que os outros farão no próximo segundo. Os programadores possuem (mas nem sempre empregam) uma ferramenta poderosa para substituir a telepatia: a papelada. A maioria dos desenvolvedores concorda que a documentação é crucial para um projeto, como evidenciado por pesquisas como a Pesquisa de desenvolvedores do Stack Overflow 2023 , onde 90,36% dos entrevistados usam documentação técnica regularmente. No entanto, eles geralmente não conseguem encontrar todas as respostas lá, recorrendo ao Stack Overflow (82,56%) e a vários blogs (76,69%). Outro estudo, Pesquisa Microsoft: O cotidiano dos desenvolvedores de software , mostra que os desenvolvedores gastam de 1% a 2% do seu dia com documentação, com 10,3% dos entrevistados perdendo muito tempo devido a papelada desatualizada ou de baixa qualidade.


A documentação pode assumir muitas formas, desde descrições detalhadas de projetos em sistemas como o Confluence até comentários de código e sites de descrição de projetos gerados automática ou semi-automaticamente. Pode até ser tão simples quanto um arquivo README no diretório raiz do projeto. Independentemente do formato, o processo de criação de documentação vai muito além de apenas transmitir informações sobre como o produto funciona. Esse processo nos faz repensar o que fizemos , o que muitas vezes pode levar a melhorias na API e na arquitetura geral. Muitas vezes percebi, ao documentar a funcionalidade que criei, que pode ser difícil trabalhar com ela, e encontrei maneiras de consertar isso.


É importante lembrar que manter a documentação sempre exige um esforço significativo, especialmente se o projeto estiver em um estágio em que muda frequentemente. Nesses casos, você deve pesar todos os riscos e considerar cuidadosamente qual lógica documentar. Se seu projeto atingiu um estado maduro, uma boa documentação trará mais benefícios do que desafios: novos desenvolvedores podem embarcar e ganhar impulso mais rápido, enquanto funcionários de longa data podem descobrir rapidamente como certos recursos funcionam. Além disso, a documentação com uma boa funcionalidade de pesquisa em um grande projeto com muitas equipes pode evitar a duplicação de recursos.

Contar aos outros o que você está fazendo não é vergonha

Usar piscas é a forma mais básica de ser um piloto previsível. Da mesma forma, comentar o código é provavelmente a maneira mais fácil e direta de dizer aos outros o que você está fazendo. E, assim como usar piscas, isso não o torna menos legal. Eu sei, há uma crença comum de que comentários são desnecessários porque o código deve ser autoexplicativo. Mas, nah, eu não concordo totalmente com isso. Código de qualidade pode frequentemente ser compreendido intuitivamente graças à boa nomenclatura de variáveis e funções, estrutura clara e adesão aos princípios de código limpo. No entanto, mesmo nesses casos, comentários bem pensados podem fornecer informações inestimáveis.


Comentários desempenham um papel crucial quando se trata de algoritmos ou soluções complexas que exigem contexto adicional para serem entendidas. Eles podem explicar o "porquê" por trás de uma abordagem, o que nem sempre é óbvio no próprio código. Isso é particularmente importante quando o código é otimizado para desempenho, mas suas intenções e lógica não são imediatamente claras. Comentários também podem ajudar a reconsiderar se o algoritmo escolhido está se movendo na direção certa.


Comentários são salva-vidas em lógicas de negócios complexas ou requisitos específicos de projetos, que podem não ser óbvios para novos membros da equipe ou em caso de suporte de projeto de longo prazo. Eles ajudam a reter conhecimento dentro da equipe e facilitam a transferência de projetos entre desenvolvedores.


Claro, é essencial evitar comentários excessivos onde os comentários declaram o óbvio ou se tornam desatualizados e enganosos. O propósito deles é garantir clareza e dar suporte à compreensão do código, não desorganizá-lo com informações desnecessárias.

Testes: uma ferramenta para compreensão e verificação de código

Ok, agora imagine que finalmente aprendemos a pilotar e agora queremos tentar a sorte em uma pista de corrida de verdade. Bem, logo descobriremos que corrida de verdade não é só sobre ser capaz de "acelerar a fundo". Envolve treinamento, testes e ajustes finos da sua máquina para se adequar aos seus hábitos e condições de corrida. O mesmo se aplica ao código: ele deve ser completamente testado, testado e corrigido, se necessário, antes de poder ser lançado para uma volta real. Portanto, abordar o teste de código com a máxima responsabilidade é crucial. Os testes são frequentemente vistos apenas como uma ferramenta para encontrar bugs, mas seu papel é mais amplo:


  • Detecção de erros e defeitos : os testes identificam erros e comportamentos imprevistos antes que o produto chegue ao usuário, melhorando a qualidade e reduzindo os problemas do usuário.
  • Compreensão do código : a criação de cenários de teste requer uma compreensão profunda da estrutura e funcionalidade do código, promovendo uma melhor compreensão da lógica e interação do programa.
  • Suplemento de documentação : os testes podem servir como exemplos de uso para funções e métodos, ajudando a localizar informações sobre a funcionalidade do projeto e auxiliando novos especialistas ao fornecer casos de uso reais.


Testes eficazes são vitais para produzir código de alta qualidade, confiável e compreensível. No entanto, assim como a documentação, os testes podem exigir muitos recursos, principalmente nos estágios iniciais do projeto. Equilibrar a necessidade de testes com restrições de tempo e recursos é essencial.


Também é óbvio que a cobertura de teste absoluta para código complexo é simplesmente inatingível. Assim, os desenvolvedores devem priorizar o teste de funções-chave e seções críticas de código, sabendo quando parar para evitar um ciclo de teste sem fim.

Ame seu código como você ama seu amigo e cuide dele

Finalmente, nenhuma motocicleta pode ser confiável sem a manutenção adequada. Há algumas pessoas que negligenciam esse aspecto da pilotagem, mas elas criam histórias (que variam de engraçadas a assustadoras e tristes) das quais definitivamente não queremos fazer parte. No mundo da programação, assim como no motociclismo, a manutenção do código não é apenas uma recomendação, mas uma necessidade, especialmente para projetos de longo prazo. A falta de manutenção e atualizações leva à obsolescência do produto e vulnerabilidades de segurança.


Quando o código não é atualizado para compatibilidade com os compiladores e interpretadores mais recentes, atualizá-lo pode (e realmente vai) se tornar cada vez mais difícil. Seu produto pode parar de funcionar com novas versões do sistema operacional se você estiver desenvolvendo um aplicativo para desktop ou celular. Para um site, ele pode parar de funcionar devido a ferramentas e tecnologias desatualizadas. O problema mais simples pode ser um certificado de segurança expirado ou software desatualizado para sua renovação.


Atualizações regulares e refatoração também são cruciais para manter a legibilidade do código. Isso mantém o projeto gerenciável, simplificando futuras mudanças e adições de recursos.


Resumindo, ame seu código e dedique tempo a ele – mas não excessivamente, ou você acabará como o protagonista de "O Teorema Zero". Boa sorte!