Existem 3 problemas de código que você encontra na programação: Hardcode, Govnokod e Schizokod.
Vamos conversar sobre isso.
Hardcode
Esse é um problema conhecido quando um programador, por causa de pressa ou preguiça, escreve código sem levar em consideração variáveis. Talvez o caso mais comum seja o domínio do site. Pode variar de ambiente para ambiente e geralmente causa muitos problemas. Tudo é simples aqui. Em plataformas diferentes, isso é resolvido de maneiras diferentes. O principal é cumprir os acordos e regras adotados na plataforma.
Normalmente, os problemas dessa classe são rapidamente detectados e facilmente tratados.
Govnokod
Este é um problema mais difícil. Frequentemente subjetivo. Grosso modo, isso é uma violação do estilo de código adotado no chefe, equipe ou comunidade.
Existem diferentes estilos de código, dependendo da plataforma e até mesmo dentro da plataforma:
Isto é do mundo php. Em outras comunidades, a situação é semelhante. Isso também inclui histórias sobre a guia, a guia após 2 espaços ou a guia após 4 espaços, etc.
Aqui surge o problema do código puro ... por exemplo, funções longas de 3-4 páginas, que são criticadas. Isso nem sempre é ruim, mas muitas vezes é possível tornar essas funções mais curtas, dividi-las em uma série de funções curtas, cada uma das quais resolve seu próprio problema.
Normalmente, esses problemas são facilmente tratados através de software e controle de padrões aceitos em uma equipe específica.
Acrobacias, quando um desenvolvedor pode alternar entre diferentes estilos de código, dependendo do projeto.
É ruim quando o desenvolvedor viola o estilo de código adotado pela equipe ou considera seu estilo de código favorito (geralmente o único aprendido) o único correto.
Não há estilos de código corretos. Existem estilos aprovados na equipe ou estilos geralmente aceitos.
Também é um problema relativamente simples e facilmente resolvido.
Schizocode
Esse é um problema menos popular, mas geralmente o mais caro.
Schizocode - vem do conceito de esquizofrenia. Squeeze from Wikipedia:
Esquizofrenia (de outro grego: σχίζω “split”, “split” + φρήν - “mente, pensamento, pensamento”), anteriormente lat. demência praecox ("demência prematura") ou esquizofrenia é um distúrbio mental polimórfico endógeno ou grupo de transtornos mentais associados à quebra dos processos de pensamento e reações emocionais.
Existem 2 pontos importantes: divisão e demência. Quais são as causas do esquizocódigo.
Um código ideal é aquele que não está escrito. Schizocoders não estão familiarizados com este conceito.
Em resumo, o esquizocódigo é um código que viola o princípio Razor da Occam.
Squeeze from Wikipedia:
“Navalha de Occam (lâmina)” é um princípio metodológico, nomeado em homenagem ao monge inglês Franciscano, filósofo nominal William Ockham. De uma forma simplificada, lê-se: "Você não deve multiplicar a existência sem necessidade"
É expresso no fato de que os desenvolvedores começam a complicar o código e a arquitetura sem uma boa razão. Ou o peso das razões existe apenas em sua imaginação.
Problemas imaginários - a raiz do software ruim
Existem 2 sintomas principais: a invenção de bicicletas em muletas e a multiplicação de camadas de abstração.
A invenção de bicicletas de muletas
Expressa-se que os desenvolvedores, em vista da pouca capacidade de aprender, em vez de procurar soluções / métodos ideais dentro da estrutura da plataforma e da arquitetura existente, começam a inventar bicicletas / muletas.
Exemplos:
- Escrevendo suas próprias estruturas CMS / ptm de que as existentes têm uma falha fatal
- Blog do Symfony Apesar do fato de o mundo inteiro usar o WordPress para isso.
- Lojas on-line no Laravel, apesar do WooCommerce (número 1 do mundo), Magento (também bom), 1C-Bitrix (na pior das hipóteses, melhor que o Laravel)
- Eu conheci uma situação em que o layout estava no Bootstrap, mas o desenvolvedor decidiu escrever seus próprios estilos para etiquetas. O que o impediu de adicionar a classe de rótulo que o Bootstrap já possui?
- Funções, métodos e classes redundantes não possuem cálculos que poderiam ser evitados usando bibliotecas e métodos prontos nas plataformas usadas
Propagação descontrolada de camadas de abstração: classes extras, herança, métodos
O leitor atento pode notar um conflito com o govnokod. Em um caso, o problema é que a função ou classe é muito longa, mas o problema é que, pelo contrário, há uma fragmentação excessiva de entidades.
Aqui deve-se notar que este é um dos extremos, cuja fronteira nem sempre é fácil de observar.
Por um lado, é ruim tentar resolver tudo com uma função em 3 páginas ou uma classe que contém HTML e mecânica de modelos e, em algum lugar, é mais rentável dividir o código em várias funções / classes / componentes, cada um dos quais resolve seu próprio problema. Este é um extremo.
Por outro lado, um código muito simples é dividido em 5 classes, cada uma com 3-4 métodos de 3-4 linhas, com muitas heranças inúteis, quando você pode fazer uma ou duas com herança mínima ou mesmo sem herança, se isso puder ser evitado.
As consequências de abstrações supérfluas e ruins
Propagação de métodos, classes, herança sem uma boa razão - este é um código supérfluo e o crescimento de camadas de abstração.
Tudo tem um preço, além de abstrações extras:
- treinamento para novos desenvolvedores mimado
- quanto mais código, mais pontos de falha, mais erros
- diagnóstico e depuração de código é complicado
Problema de pensamento
Quanto mais camadas de abstração, herança, métodos, mais pensamento é necessário para mudanças, melhorias e diagnósticos de problemas.
E o volume de trabalho de combustível é finito e muitas vezes sua escassez acarreta custos de desenvolvimento muito grandes.
Cada desenvolvedor que fez o diagnóstico e alterou o código de esquizo descansou em uma escassez de combustível para pensamentos. Mas nem todo mundo estava ciente disso.
Um vídeo que explica o que o combustível está pensando e oferece um exercício simples por 1 minuto, o que permite que você lembre a sensação de falta de combustível em um exemplo simples:
Está sendo executado em OOP, classes e herança?
Nem um pouco. No entanto, há alguma verdade nisso. Em um estilo funcional, é mais fácil novokovodit, mas esquizokod é difícil lá. OOP, por um lado, oferece muitas vantagens, mas também abre espaço para um esquizocódigo.
POO, classes e herança não são ruins nem boas. Essas são as ferramentas. Eu pessoalmente os uso.
No entanto, tenho várias regras próprias:
- Quase sempre escrevo classes por causa do encapsulamento, mas muitas vezes tenho Singleton suficiente, métodos estáticos e sem estado
- Onde existe um método comumente usado, escrevo funções que geralmente são apenas invólucros para os métodos de uma classe, mas às vezes uma função é apenas uma função sem uma classe e isso é bom quando apropriado.
- Classes com estado - sim, mas com menos frequência e novamente apenas onde houver boas razões
- A herança é ainda mais rara, e somente onde há boas razões para isso (tento reduzir as camadas de abstração e economizar pensamento e combustível em uma equipe)
Sumário
Falamos muito sobre hardcode e govnokode porque eles são compreensíveis e facilmente tangíveis. Mas o esquizocódigo geralmente fica impune, porque é mais difícil identificar e entender a quantidade de danos causados por ele. E a quantidade de dano resultante disso é possivelmente mais do que se pode imaginar com uma investida.
Meu manifesto é simples:
- é melhor aprender o melhor princípio da raça antes de inventar outra bicicleta de muleta que ninguém precisa
- vamos escrever menos esquizocódigo
- vamos aprender a cumprir o princípio Razor da Occam e não complicar o código sem motivo
- vamos salvar nossos pensamentos e nossa equipe
Bem, terei prazer em comentar tanto em apoio ao manifesto quanto a suas críticas.