Bom dia, faço programação há 8 anos e em todas as suas manifestações: desenvolvendo o lado do servidor em diferentes linguagens de programação, desenvolvendo o lado do cliente, programando as redes, administrando o linux e otimizando o desempenho. E quando você está ocupado com uma empresa há tanto tempo, ama sinceramente e se esforça para o autodesenvolvimento, então inevitavelmente começam a surgir vários relacionamentos causais no campo correspondente, você começa a ver aqueles relacionamentos que você nem conhecia antes ou simplesmente os considerava insignificantes, é isso que as pessoas chamam de experiência.
E é sobre um desses relacionamentos causais que eu gostaria de compartilhar com você neste artigo. Pensei em escrever que esse é um dos relacionamentos mais importantes de causa-efeito, para ser um pouco menos radical, mas ainda assim não, esse relacionamento de causa-efeito é o relacionamento mais importante de causa-efeito na programação por uma margem enorme. Ele funciona como um encadeamento em absolutamente todas as áreas da programação: escrever código, projetar uma interface, implantar um aplicativo, organizar uma equipe, manter um rastreador de erros e assim por diante. E eu chamo essa relação causal sagrada de
minimização de variáveis .
Com o termo variável, quero dizer não apenas variáveis comuns (que são declaradas pelas palavras-chave
var ,
let ,
function ), mas também variáveis em um sentido mais abstrato da palavra: pastas criadas na árvore do projeto, bibliotecas conectadas, número de chamadas ajax para o servidor, número componentes na interface, o número de protocolos que o programador deve seguir ao confirmar o código (por exemplo, revisão de código, cada recurso em um brunch separado) e assim por diante.
De fato, todo o processo de programação é uma enumeração de variedades na direção de como implementar isso ou aquilo funcional usando o número mínimo possível de variáveis (pelo menos, olho para a programação dessa perspectiva). O código que implementa o recurso com menos dependências / arquivos / linhas de código é melhor que o que implementa a mesma funcionalidade com um grande número de variáveis. Se uma classe de utilitário contiver apenas uma função - você precisa se livrar dessa classe de utilitário, se a função consistir em apenas uma linha - você precisará se livrar dessa função se houver apenas 10 linhas de código no componente - será necessário excluir esse componente se houver apenas um arquivo na pasta - você precisa se livrar dessa pasta e assim por diante. E quando vários milhares dessas mudanças aparentemente insignificantes são somadas, o resultado é um código bonito, conciso e minimalista, que é muito fácil de ler. O diabo está nos detalhes, como eles dizem.
Aqui está uma lista de efeitos positivos que aparecem quando você inicia a programação com base no princípio de minimizar variáveis:
- Menos bugs. Como menos código é gravado, o número de lugares onde você pode cometer um erro é correspondentemente reduzido.
- É mais fácil apresentar novas pessoas ao projeto. A complexidade do projeto é diretamente proporcional ao número de variáveis nesse projeto; quanto menos variáveis, mais fácil é a introdução de novas pessoas.
- Mais fácil adicionar novas funcionalidades. Como é necessário estudar uma quantidade menor de código, torna-se mais fácil “carregar” o funcional no cabeçote e, como resultado, adicionar novas funcionalidades ou modificar o código existente.
- Previsibilidade. O processo de programação se torna muito mais previsível, é mais fácil prever quanto tempo levará para desenvolver um recurso ou outro devido ao fato de o número de "gags" ser reduzido. Normalmente, são os plugues que causam o maior número de problemas e levam ao atraso dos prazos.
Mas muitas vezes ocorre a situação oposta, os programadores começam a se afirmar introduzindo novas variáveis. Apresentamos 20 bibliotecas diferentes, estruturas CSS, criamos um grande número de abstrações em vários níveis, como o
UserFactoryManager (programadores Java especialmente pecam por esse motivo), criamos muitos diretórios, introduzimos metodologias de desenvolvimento mais avançadas, adicionamos mais protocolos antes de enviar arquivos, e assim por diante. E a motivação por trás de tais decisões pode ser entendida, porque cria a ilusão de profissionalismo, eles dizem ver o quanto eu sei e quais abstrações complexas eu posso lidar. Mas muitas vezes isso causa danos terríveis ao projeto.
Não me interpretem mal, não sou contra o uso de metodologias, estruturas e tecnologias mais avançadas, apenas digo que muitas vezes elas são introduzidas simplesmente por causa do hype, e não porque essa tecnologia resolve qualquer problema urgente no projeto.
A solução para o problema de muitas quantidades de variáveis pode ser chamada de
Superengenharia . Mas você deve admitir que, se você descrever essa situação como se o problema estivesse sendo resolvido por muitas variáveis, essa é uma descrição muito mais precisa desse fenômeno.
Freqüentemente, a introdução de novas variáveis é justificada pela escalabilidade, eles dizem que se você criar um
UserManagerFactory aqui , poderemos pegar e adicionar uma função a qualquer momento, se necessário. Mas, na realidade, a escalabilidade não ocorre quando muitas variáveis são introduzidas, mas quando há poucas variáveis. Pense em onde será mais fácil escrever novas funcionalidades: no mecanismo do navegador chrome ou em um projeto completamente novo que você escreve do zero?
A introdução de novas variáveis não leva à escalabilidade da arquitetura. O que realmente melhora a escalabilidade de um projeto é quando você remove variáveis desnecessárias e simplifica o código existente.
Um grande número de variáveis desnecessárias - esse é exatamente o motivo pelo qual odeio a linguagem de programação Scala com ódio feroz e o motivo pelo qual amo o JavaScript. Scala é apenas a quintessência de um sistema de tipos muito complicado e muito confuso, muitos conceitos que se duplicam, conversões implícitas, um grande número de maneiras de fazer a mesma coisa. Quando uso essa linguagem de programação, penso não no
que precisa ser feito, mas em
como fazê-lo. Muitas vezes me encontro agora, meu objetivo é apenas calar a boca o compilador. Por outro lado, o JavaScript é exatamente o oposto de Scala, é uma ordem de magnitude mais minimalista; usando-o, dedico muito menos esforço mental para expressar um ou outro conceito. Obviamente, essa simplicidade também tem suas desvantagens, por exemplo, no Scala, o compilador relata um erro no estágio de compilação, enquanto no JavaScript você pode reconhecer apenas um erro no tempo de execução e é fundamentalmente impossível para o JavaScript escrever o mesmo IDE funcional que para os de tipo forte. idiomas, mas essas são as vítimas com as quais estou pronto para conciliar.
O princípio de minimizar variáveis precisa ser aplicado ao projetar interfaces, por exemplo, vamos comparar interfaces da Web para duas redes sociais concorrentes para namorar o
Tinder e o
Badoo . De fato, existe apenas uma página na interface da web do Tinder, o perfil do usuário, bate-papos ativos e a busca de novos conhecidos são exibidos em uma página e não há necessidade de alternar para outras páginas; nessa interface, todas as necessidades do usuário são atendidas por um número mínimo de componentes. Enquanto no Badoo a funcionalidade de alternar para o perfil do usuário, a interface da mensagem e a página para encontrar pares são implementadas como páginas separadas, o usuário precisa executar mais ações para atender às necessidades e, portanto, essa interface é menos eficiente. Obviamente, este é apenas um exemplo muito pequeno, mas quando existem dezenas e centenas de exemplos, todos juntos determinam se a interface foi pensada ou não.
Ao projetar a interface, é necessário criar um número mínimo de componentes para satisfazer as necessidades do usuário.Pelo mesmo motivo, eu absolutamente não gosto das abordagens que separam lógica, dados e apresentação, porque, neste caso, surge uma situação na qual escrever uma parte da funcionalidade é necessário criar três arquivos, o número de componentes começa a crescer e, quando o projeto já está grande, então o número de arquivos começa a rolar sobre todos os limites razoáveis. Por exemplo, ao escrever interfaces da Web, os estilos são geralmente descritos em arquivos separados, enquanto os nós aos quais esses estilos estão conectados estão em outro arquivo. Por mais estranho que pareça, a principal motivação para essa separação é o dimensionamento; portanto, se você separar os nós e seus estilos, será mais fácil navegar no projeto e será possível desenvolver independentemente essas duas partes do funcional. Mas vamos ver quais variáveis são adicionadas a essa abordagem: novos arquivos com estilos para cada componente, seletores (eles descrevem a qual nó os estilos estão anexados), regras em cascata (se vários seletores abordarem o mesmo nó). Embora se você escreva estilos diretamente nos nós aos quais esses estilos devem ser conectados (por exemplo, através do atributo style), todas essas variáveis adicionais não serão mais necessárias, o que simplifica bastante o código. Recentemente, essa abordagem se tornou cada vez mais popular; existem muitas bibliotecas que permitem escrever estilos diretamente no atributo style.
Novas variáveis sempre devem ser introduzidas no projeto gradualmente. Por exemplo, no início, ao escrever um projeto, tenho todos os arquivos no diretório raiz, sem subdiretórios, simplesmente porque é mais fácil e, somente quando o número de arquivos aumenta para 40-60 arquivos, alguns arquivos são agrupados em diretórios. No início, nenhuma metodologia de desenvolvimento é necessária, basta jogar todos os programadores em uma pilha, dar-lhes tarefas e eles descobrirão eles mesmos; se a metodologia de desenvolvimento for introduzida muito cedo, parecerá algum tipo de conceito substituto. Quando variáveis são introduzidas antes de serem necessárias, isso é chamado de otimização prematura.
Da mesma forma, é necessário minimizar as variáveis ao escrever documentação / artigos, quando escrevo documentação, sempre penso no número exato de frases que preciso para transmitir meus pensamentos. Analiso literalmente cada sentença e, se me parece que essa sentença não é necessária, não carrega nenhuma carga semântica adicional, é excluída, como resultado, é obtida uma página muito compactada com documentação, que contém a quantidade máxima de informações necessárias em uma quantidade mínima de texto.
De fato, em geral, qualquer variável tem uma presunção de culpa, nenhuma variável é necessária até que o contrário seja provado.
Você pode se opor a mim, eles dizem o mesmo para mim, descobriu a América, é conhecida há muito tempo e é descrita por princípios como:
Okama ,
SOLID . Mas prefiro chamar esse conceito de "minimização de variáveis", simplesmente porque essa interpretação é muito sucinta na cabeça e, portanto, é muito mais fácil manter-se na prática. Quantos de vocês podem se gabar de se lembrar de todos os pontos do princípio SOLID?
Iniciantes escrevem código simples porque não sabem escrever código complexo, programadores comuns escrevem código complexo, simplesmente porque podem, os profissionais escrevem código simples porque não querem escrever código complexo.
Deve-se lembrar que qualquer extremo é ruim: se é fanático minimizar as variáveis até o nível atômico, essa abordagem, assim como a introdução de muitas variáveis, é extrema. E qualquer extremo, como você sabe, é ruim, a verdade está sempre em algum lugar.