Desenvolvimento Web Os 10 antipadrões de codificação que você deve evitar
Projetar a arquitetura de um site ou aplicativo, ou configurar um fluxo de trabalho de codificação eficaz, freqüentemente nos faz lidar com problemas recorrentes. Nós não necessariamente precisamos resolver esses problemas de design de software a partir do zero, como soluções no nível de arquitetura podem ser reutilizadas Da mesma maneira que trechos de código no nível micro.
Padrões de design são geralmente soluções reutilizáveis para certos cenários, isso pode vem a calhar para resolver problemas comuns, e pode nos ajudar enormemente a otimizar nosso código.
Embora os padrões de design sejam ótimos para melhorar nosso processo de desenvolvimento usando fórmulas bem testadas, às vezes também podemos errar com eles. Estes são chamados antipadrões.
O que são antipadrões?
O termo “antipadrão” foi cunhado em um livro chamado AntiPadrões em 1998. Ele se refere a soluções reutilizadas que inicialmente parecem úteis, mas depois acaba fazer mais mal do que bem.
Isso pode acontecer por diferentes razões, por exemplo, se não usarmos os padrões no contexto, configuração ou tempo corretos (soluções que eram eficazes no passado nem sempre funcionam no presente) ou, em outros casos, todo o paradigma foi ruim desde o início.
Antipadrões também são freqüentemente chamados padrões de falha. A boa notícia é que é possível reconhecê-los e evitá-los.
Neste post, veremos 10 antipadrões de codificação comuns no desenvolvimento da Web que podem nos iludir e pensar que temos código otimizado. (Observe que os antipadrões listados neste post não são necessariamente os mesmos que você pode encontrar no livro mencionado acima.)
1. Otimização Prematura
Um bom timing é um fator crucial na otimização de código. Podemos facilmente reproduzir o antipadrão de “otimização prematura”, se prestarmos atenção a pequenas eficiências e otimizarmos para elas muito cedo no processo de desenvolvimento, antes de sabermos exatamente o que queremos fazer.
De acordo com a famosa citação de Donald Knuth “Otimização prematura é a raiz de todo o mal“, o que pode ser um exagero, mas ainda mostra como problemas sérios de otimização prematura podem causar mais tarde.
Se otimizarmos o desempenho antes de configurar uma arquitetura eficaz, poderemos menor legibilidade do código, faço depuração e manutenção mais difícil, e adicionar peças supérfluas para o nosso código.
Para evitar a otimização prematura, é uma boa idéia seguir o princípio de programação YAGNI (Você não precisa ir), que aconselha a “sempre implementa as coisas quando você realmente precisa delas, nunca quando você apenas prevê que precisa delas.”
2. Reinventando a Roda
o “reinventando a roda” antipadrão é por vezes também referido como “projetando no vácuo”. Isso acontece quando queremos fazer tudo sozinhos e escreva tudo do zero, sem procurar por métodos, APIs ou bibliotecas já existentes.
Reinventar a roda não é apenas uma coisa que desperdiça tempo, mas soluções personalizadas, especialmente para funcionalidades básicas, raramente são tão boas quanto as padrão que já foram testados por muitos desenvolvedores e usuários.
Inferno da Dependência
O oposto do “reinventando a roda” antipadrão é outro antipadrão comum chamado “dependência inferno”.
Se, em vez de escrever tudo do zero, usarmos muitas bibliotecas de terceiros que dependem de versões específicas de outras bibliotecas, podemos facilmente encontrar uma situação dificilmente administrável quando queremos atualizá-los, já que essas dependências são em muitos casos incompatíveis entre si.
Inferno dependência pode ser resolvido usando gerenciadores de pacotes que são capazes de actualizar de forma inteligente as dependências interdependentes. Se estamos muito sobrecarregados pelo problema, a refatoração também pode ser uma boa ideia.
4. Código Espaguete
“Código espaguete” é provavelmente o antipadrão de codificação mais famoso. Descreve um aplicativo que é difícil de depurar ou modificar devido à falta de uma arquitetura apropriada.
O resultado do design de software ruim é um monte de código que é semelhante em estrutura a uma tigela de espaguete, ou seja,. emaranhado e complicado. A legibilidade do código de espaguete é muito baixa, e geralmente é uma missão quase impossível de entender como funciona exatamente.
O código de espaguete geralmente vem do combinação de diferentes práticas de codificação incorretas, como o código que não contém blocos condicionais apropriados, ter muitas instruções goto, exceções e encadeamentos, contendo partes que pertencem a outro lugar, tem relações mínimas entre objetos, possui funções ou métodos que não podem ser reutilizados ou não são documentados corretamente ou em absoluto.
5. Programação por Permutação
“Programação por permutação” ou “programação por acidente” acontece quando tentamos encontrar uma solução para um problema, experimentando sucessivamente pequenas modificações, testando-as e avaliando-as uma por uma e, finalmente, implementando aquela que funciona primeiro..
Programação por permutação pode facilmente introduzir novos bugs no nosso código, pior ainda, são bugs que não reconhecemos necessariamente de uma só vez. Em muitos casos, também é impossível antecipar se a solução funcionará para todos os cenários possíveis, ou não.
6. Copie e Cole a Programação
“Copie e cole programação” ocorre quando não seguimos o princípio de codificação Don't Repeat Yourself (DRY) e, em vez de criar soluções genéricas, inserimos fragmentos de código já existentes em locais diferentes e depois editamos para caber no contexto fornecido.
Esta prática resulta em um código altamente repetitivo, como as partes do código inserido geralmente diferem apenas em pequenas discrepâncias.
Copiar e colar programação não é apenas comprometida por desenvolvedores novatos, mas programadores experientes também, como muitos deles são propensos a use seus próprios trechos de código pré-escritos e bem testados para tarefas específicas, o que pode facilmente levar a repetições não intencionais.
7. Programação Carga-Culto
O nome de “programação de cultos de carga” vem de um fenômeno etnográfico específico chamado “culto de carga”. Os cultos de carga surgiram no Pacífico Sul após a Segunda Guerra Mundial, quando o contato forçado com civilizações avançadas levou os nativos a pensarem que produtos manufaturados, como Coca-Cola, TVs e refrigeradores trazidos por navios de carga para as ilhas, foram criados por seres sobrenaturais. métodos; e se eles realizam rituais mágicos semelhantes aos costumes dos ocidentais, a carga cheia de mercadorias virá novamente.
Quando cometemos o antipadrão de programação de cultos de carga, basicamente fazemos o mesmo. Usamos frameworks, bibliotecas, soluções, padrões de design, etc., que funcionaram bem para outros, sem entender por que fazemos isso, ou como essas tecnologias funcionam exatamente.
Em muitos casos, os desenvolvedores apenas ritualmente fazer o que é hip naquele momento sem qualquer propósito real. Essa prática não é ruim apenas porque torna nosso aplicativo superfluamente inchado, mas também pode introduzir facilmente novos bugs em nosso código.
8. Fluxo de Lava
Nós falamos sobre o “fluxo de lava” antipadrão quando precisamos lidar com código que tenha peças redundantes ou de baixa qualidade naquela parece ser integral para o programa, ainda não entendemos completamente o que faz ou como isso afeta o aplicativo inteiro. Isso torna arriscado removê-lo.
Isso geralmente acontece com código legado, ou quando o código foi escrito por outra pessoa (geralmente sem documentação apropriada), ou quando o projeto se moveu muito rápido do desenvolvimento para a fase de produção.
O nome do antipadrão vem de sua semelhança com a lava vinda de vulcões, ou seja, a princípio ele se move rápida e fluidamente sem tomar muitas precauções, mas depois se solidifica e se torna difícil de remover.
Em teoria, podemos nos livrar dos fluxos de lava com testes extensivos e refatoração, mas na prática, a implementação é freqüentemente difícil ou mesmo impossível. Como os fluxos de lava geralmente têm altos custos de desempenho, é melhor evitá-los configurando uma arquitetura bem projetada e um fluxo de trabalho de som desde o início.
9. Codificação Rígida
“Codificação rígida” é um antipattern conhecido contra o qual a maioria dos livros de desenvolvimento web nos adverte no prefácio. A codificação dura é a prática infeliz em que nós armazenamos dados de configuração ou entrada, como um caminho de arquivo ou um nome de host remoto, no código-fonte em vez de obtê-lo a partir de um arquivo de configuração, um banco de dados, uma entrada do usuário ou outra fonte externa.
O principal problema com o código rígido é que ele só funciona corretamente em um determinado ambiente, e em a qualquer momento as condições mudam, precisamos modificar o código-fonte, geralmente em vários lugares separados.
10. Codificação Suave
Se nos esforçarmos muito para evitar a armadilha da codificação, podemos facilmente encontrar outro antipadrão chamado “codificação suave”, que é o seu exato oposto.
Em codificação suave, colocamos coisas que deveriam estar no código fonte em fontes externas, por exemplo, armazenamos a lógica de negócios no banco de dados. A razão mais comum para isso é o medo de que as regras de negócios mudem no futuro, portanto, precisaremos reescrever o código.
Em casos extremos, um programa de código tornar-se tão abstrato e complicado que é quase impossível compreendê-lo (especialmente para novos membros da equipe) e extremamente difícil de manter e depurar.
