Aconteceu que a maior parte da minha vida consciente eu programa em PHP. Nosso cérebro, percebendo informações de qualquer fonte, faz isso sem interrupção da autoridade dessa fonte. Grosso modo, se você ama PHP - você adicionou automaticamente pontos de credibilidade ao autor deste artigo e, se não gostar - eles os removeram automaticamente. Esse processo ocorre em um nível inconsciente e é essencialmente um prisma de percepção, que por um lado nos protege de cair em uma análise interminável de informações de qualquer grau de autoridade, mas por outro lado nos limita na busca de informações novas e mais relevantes. A pior parte é que a credibilidade da fonte raramente é verificada em um nível consciente (porque leva tempo e recursos na forma de calorias preciosas); posso ter a mesma probabilidade de um desenvolvedor positivo, um cozinheiro de dona de casa, um encanador sem uma princesa ou geneticamente modificado gato Não julgue meu artigo estritamente, tenho patas.
O mesmo se aplica à leitura do código de outra pessoa: se o autor estiver do lado esquerdo do seu trono, estiver trabalhando na sua empresa há mais de 10 anos e ganhar um zero a mais do que você, isso não será o mesmo que o autor que foi demitido por algo- isso é ruim e você foi contratado no lugar dele. Mas, de fato, o código aqui e ali é apenas um conjunto de bytes que seria útil para avaliar sem referência à autoridade da fonte.
Quando lemos o código de outra pessoa, uma grande variedade de emoções pode nos visitar: admiração, riso, irritação, decepção, rejeição completa. É útil saber que a manifestação de qualquer emoção em qualquer contexto é uma resposta automática do (primeiro) nível inferior do sistema nervoso, formado de maneira evolutiva, necessário em um ambiente primitivo. A principal tarefa dessa resposta, no caso de uma emoção "negativa", é lançar o mecanismo de ação "bater ou correr" com um único objetivo - sobreviver. Em nosso ambiente atual de escritório, ao analisar o código de outra pessoa, essa resposta se torna inútil e até prejudicial, porque você gasta um tempo e recursos preciosos, além de poluir seu cérebro com neurotransmissores que diminuem seu raciocínio rápido em prol da velocidade da reação. A boa notícia é que essa resposta pode ser reprogramada. Você pode suprimir reações emocionais negativas ou inventá-las, por exemplo, rir onde costumava ficar com raiva. O riso, ao contrário da raiva, lança para o cérebro neurotransmissores bons, saborosos e úteis que dão prazer, reforçam a experiência e o motivam a continuar trabalhando.
Para reprogramar a emoção, você precisa mentalmente entrar em uma meta-posição para avaliar sua própria situação e avaliar a si mesmo, em vez de condenar o código de outra pessoa. Por que esse pedaço do código de outra pessoa me dá nojo? É realmente que o amador escreveu, e agora eu tenho que sofrer tão bem e experimentar? Se eu sou tão bom e experiente, por que estou tendo problemas para entender o código de outra pessoa e reescrevê-lo como achar melhor? Talvez eu simplesmente não tenha RAM suficiente para perceber esse macarrão? Talvez o autor desta peça saiba algo que eu não sei?
As modernas ferramentas de desenvolvimento permitem que você transforme o código de outra pessoa em estruturas mais compreensíveis e agradáveis quase que instantaneamente. Uma função ou variável é mal nomeada - ctrl + shift + R e em alguns segundos é chamada para sempre. Abas em vez de espaços, recuos inconvenientemente dispersos e chavetas incomuns no estilo egípcio - ctrl + shift + F e formatação restaurada! O comentário é redundante ou desatualizado - ctrl + D e não é. Se você mudar o prisma da percepção, a leitura do código de outra pessoa pode se transformar em um divertido jogo de detetive interativo.
Código é apenas uma ferramenta. Não importa o quão ruim e terrivelmente ele tenha sido escrito, em um momento específico e em um determinado local, ele resolveu com êxito um problema específico, o que significa que ele já está "justificado". Algo mudou nos requisitos de negócios, algo não foi levado em consideração - o código foi quebrado ou desatualizado, e isso é normal. O código tem a capacidade de evoluir de várias maneiras: e gradualmente, cheio de camadas e revolucionário, escrevendo do zero. Obviamente, é bom quando o programador prevê o futuro e, nos estágios iniciais, define no código as possibilidades de seu desenvolvimento. Mas esse machado é agudo por dois lados, você pode cometer um erro ao prever o futuro, o futuro pode não chegar e o tempo e os recursos serão irremediavelmente perdidos. É importante entender o código em que grau de qualidade é necessário para você. Se esse é um sistema distribuído enorme, cujos módulos são programados por seus colegas de todo o mundo em empresas pouco conectadas às suas, então sim, faz sentido usar padrões modernos, envolver módulos em contêineres de serviço, mesmo onde você não pode imaginar por que isso é possível. preciso. Mas se esse é um pequeno CRM local para uma empresa, cujos módulos são tão rigidamente dependentes um do outro que desabilitar qualquer módulo impede o funcionamento de todo o sistema ... nesse caso, é justificável chamar os métodos de outras pessoas diretamente, isso reduzirá o número de classes e tornará operacional o seu funcionamento. memória e reduza o tempo para depurar problemas. Mas aqui surge uma situação em que um pequeno CRM local se transforma em algo expansível que sua empresa deseja colocar em domínio público e vender. Os requisitos de negócios foram alterados. O programador deve ser responsabilizado por não prever isso?
Padronização
O código é apenas uma ferramenta, mas sua criação é pura criatividade. Qualquer problema pode ser resolvido por um número infinito das mais diversas formas. Alguns deles são mais produtivos que outros - um exemplo de avaliação objetiva. Alguns deles são mais legíveis que outros - um exemplo de avaliação subjetiva. Mesmo se você convencer todo o escritório de que algum código não é legível, ainda haverá pelo menos um autor que não concorda com você. A padronização do código visa transformar a pura criatividade no conjunto de ações mais rotineiras, para que seja mais fácil para outros programadores entenderem o seu código. Isso é, de fato, para que você possa ser substituído por outro especialista, mais dócil e mais barato. E depois de algumas décadas, é uma inteligência completamente artificial. Vale lembrar que, se algum padrão é contrário ao senso comum, pode fazer sentido violá-lo em alguns lugares, ou mesmo abandoná-lo completamente ou substituí-lo por outro mais adequado.
Padrões maduros se vendem da posição de "ao escolher um padrão, preste atenção à popularidade da comunidade". Eu me pergunto como eles se venderam quando acabaram de sair. A idéia principal é que a popularidade de um padrão específico não é um fator que você gostaria de considerar antes de tudo ao escolher. A popularidade e as comunidades são muito inertes e podem por muitas décadas rejeitar novos e melhores padrões. Especialmente se forem revolucionários.
É dada especial atenção aos padrões que se estabeleceram completamente na cultura simplesmente porque surgiram antes de outros padrões semelhantes. Um exemplo canônico é a guerra santa entre os layouts de QUERTY e Dvorak. O segundo, obviamente, é melhor, mas o primeiro é um golpe (continua a ser mais popular) simplesmente devido à massa crítica de usuários que não desejam treinar um novo.
Exemplos semelhantes são encontrados o tempo todo e na cultura da programação. O padrão PSR representa 4 espaços em vez de guias, ignorando o fato óbvio: o ambiente de desenvolvimento da maioria dos programadores PHP mudou de editores de console para IDEs completos, em que a tabulação é mais conveniente de várias maneiras: é mais fácil excluí-la pressionando Backspace uma vez e você pode configurar comprimentos individuais Guias a gosto.
Ao aplicar esse ou aquele padrão, faça a pergunta: para quem você o torna mais conveniente? Quem é mais desconfortável? Quem se beneficiará com a regra "nomear os nomes dos métodos do lowerKamelKeysom"? Obviamente, apenas para aqueles que estão acostumados a chamá-los assim. Todos os outros ficarão desconfortáveis, terão que se adaptar, e essa perda de tempo e recursos é absolutamente do zero, dado o fato de que
a) agora temos IDEs mágicos que destacam diferentes elementos do código em cores diferentes,
b) os programadores têm a capacidade de pular de um projeto para outro, padrões de codificação que podem variar.
Pessoalmente, ao desenvolver meus projetos, eu uso:
- CamelCase para nomear classes e métodos
- $ CamelCase para nomear variáveis que contêm uma instância de um objeto
- $ snake_case para nomear variáveis contendo tipos simples
Não tenho problema em distinguir um nome de classe de um nome de método, pois o primeiro é um substantivo e o segundo é um verbo. Além disso, a luz de fundo ajuda. Mas esse é o meu gosto pessoal, não o imponho a ninguém. Este é um prisma de percepção pessoal, é individual para cada cabeça individual. Alguém teve "sorte" de mergulhar imediatamente no padrão popular, alguém teve "azar" de iniciar sua carreira com outros alternativos, e alguém geralmente desenvolveu o seu. Estou levando você ao fato de que, em vez de treinar outras pessoas, pode fazer sentido treinar-se para perceber o código em qualquer padrão. Ou mesmo além dos padrões.
Obviamente, os adeptos da padronização neste local ficarão indignados e me lançarão muitas razões contra. Este artigo não é para eles, estou escrevendo para aqueles que estão interessados em entender a essência das coisas, tentando imaginar o que o autor realmente tinha em mente e qual o objetivo que ele perseguia.
Capacidade de entender o código de outra pessoa
O gatilho que causa os impulsos de vômito na grande maioria dos programadores (um exemplo de avaliação subjetiva). Nunca lhe pareceu estranho que muitas vezes é mais fácil reescrever todo o código do zero do que entender o de outra pessoa? Em qualquer outro setor, agimos de maneira diferente: primeiro aprendemos a ler, depois a escrever; primeiro uso (eletrodomésticos, edifícios) e depois projetá-los. Parece-me que o ponto principal está em nossa educação (especificamente no campo da programação). Somos ensinados a atingir a meta da maneira mais direta e rápida, usando algum conhecimento recém adquirido. Como resultado, combinamos eles (conhecimento) exatamente até que “funcione”, testamos um pouco e enviamos ao professor para moderação. Na minha opinião, seria bom adicionar uma etapa adicional a esse processo, na qual comparamos nosso código com o código mestre, que, embora não seja o ideal e o único correto, mas fornece uma solução alternativa, geralmente mais otimizada e legível.
Quanto ao gatilho, para desligá-lo, basta colocar-se mentalmente no lugar de um cliente que tem assistido programadores que partem e se aproximam toda a vida, alegando que o trabalho de seus antecessores é fecal e que você precisa reescrever tudo para torná-lo bom. O cliente não tem competência para descobrir se você está dizendo a verdade ou apenas tem preguiça de entender o código de outra pessoa. Para ganhar sua confiança nesse assunto, você deve investigar o código de outra pessoa, encontrar algumas brechas gigantes na segurança e demonstrá-las ao cliente. Mas, mesmo nessa situação, do ponto de vista dos negócios, pode ser mais lucrativo "endurecer". Especialmente se for uma terceirização com prazos e dinheiro específicos. O programador deve ser responsabilizado por isso?
Conclusão
O que você deve escrever com a letra I. Em vez de café da manhã, beba café e manteiga no liquidificador.
Olhe mais fundo, pense mais, procure alternativas. Nunca pare de se desenvolver.