Durante todo o meu trabalho com a Bitrix, tive a oportunidade de trabalhar com um grande número de projetos que alguém desenvolveu antes de mim. Aqui estão pequenas melhorias, correção de vários bugs e erros da lógica, redesenho do site e alterações globais na funcionalidade existente. E, como qualquer outro desenvolvedor, eu odeio vasculhar o lixo, as muletas e as correções "temporárias" de outras pessoas, que na verdade são lembradas por mais 8 edições do produto.
Aqui tentarei não focar nas “piores práticas” padrão ao programar em PHP, como um desrespeito à escolha de nomes e funções de variáveis, consultas excessivas ao banco de dados em loop, falta de verificação de dados do usuário em formulários, ignorando comentários e similares. Tentarei abordar exatamente os momentos inerentes ao desenvolvimento do Bitrix, que posteriormente permitirão evitar indignação e xingamentos contra você do programador que teve que acompanhar seu código. E sim, muitas vezes você se tornará esse programador em um ano ou mais, quando esquecer completamente por que inseriu essa ou aquela muleta aqui.
“Escreva o código como se fosse acompanhado por um psicopata violento que sabe onde você mora” (c) John F. Woods
O primeiro e mais importante, na minha opinião, importante - pelo amor de Deus,
use a pasta local . É simplesmente vital ao usar o sistema de controle de versão - tudo o que você precisa fazer é adicionar a pasta / bitrix / às exceções. Só isso. Além disso, quase todo o desenvolvimento é realizado apenas nele. Isso simplifica muito a pesquisa dos arquivos e componentes necessários mais tarde, ajuda a não obstruir o repositório com arquivos desnecessários e, de fato - ele traz a árvore do projeto para uma aparência mais limpa e "humana".
Não modifique o kernel . Mesmo se você tiver certeza de que não será atualizado. Mesmo que seja mais rápido. Mesmo se você é preguiçoso. Esqueça esse pensamento como um pesadelo. Se você precisar alterar a lógica de um componente padrão, transfira-o para o novo espaço para nome / local / components / modify / e trabalhe com ele. O mesmo vale para módulos, gadgets e atividades de processos de negócios.
Não desarrume o arquivo init.php . Combine funções para trabalhar com um módulo específico ou funcional em uma classe, escreva essa classe inteira em um arquivo separado e, no init.php, inclua esses arquivos e escreva manipuladores de eventos. Eu conheci arquivos init.php de 500Kb cada, onde funções, definição de constantes, classes e inicialização de manipuladores foram misturadas em uma confusão. Obviamente, quando tive que entender esses arquivos, amaldiçoei meus antecessores.
O próximo parágrafo não diz respeito ao caso do desenvolvimento de soluções prontas para o Marketplace, quando o objetivo é tornar a funcionalidade mais personalizável da parte pública para o usuário final. Se você estiver trabalhando em um projeto específico, em um ToR específico -
não tente criar um modelo unificado para o componente em todas as ocasiões . Pessoalmente, aderir a uma filosofia - é melhor ter alguns modelos simples que são usados para fins diferentes de um universal, mas nos quais o diabo quebrará sua perna mais tarde. Obviamente, em cada caso, você precisa desenvolver o que é - os termos de referência, as opções de implementação e coisas do gênero, mas não se esqueça do Navalha da Occam. Como exemplo, darei um projeto de uma empresa de leasing, que por acaso editei. O projeto em si, é claro, foi terrivelmente implementado; para o verdadeiro horror, estava nas páginas de uma seção do catálogo de serviços. Cada uma das cinco seções tinha seu próprio layout, no qual a posição dos blocos na página e, em princípio, a presença de algumas delas diferiam. E para todas as cinco páginas, um modelo foi usado com várias duplas de chamadas de componentes, conectando estilos e scripts, que, além disso, periodicamente conflitavam entre si. Como resultado - um enorme arquivo para entender "sem um litro" era como a morte. Embora, ao que parece, o que o impediu de criar 5 modelos diferentes e não criar dificuldades inesperadamente?
Use a API . Não reinvente a roda onde ela não é necessária. Use a documentação - todo o produto está bem descrito e também cada função pode ser visualizada em detalhes no bxapi.ru.
Evite consultas diretas ao banco de dados . Este é um caso especial do parágrafo anterior - use a API. Solicitações apressadas e inseguras podem levar à corrupção, perda ou até comprometimento dos dados.
Não use componentes CNC da raiz do site . As conseqüências, em regra, são bastante tristes, uma vez que o CNC usa um arquivo manipulador de endereços, uma tentativa de usá-lo a partir da raiz quebra facilmente o endereço de outros componentes, bem como 404 páginas. Não haverá nada errado se os artigos que você possui forem direcionados para a pasta / articles / e os produtos forem relativos a / catalog /.
Conecte css e js usando a API. Ainda vejo scripts e folhas de estilo usando tags html em todos os lugares. Use o objeto de classe \ Bitrix \ Main \ Page \ Asset e as funções addJs () e addCss (). Isso permitirá combinar arquivos e, posteriormente, armazená-los em cache com um clique da caixa de seleção nas configurações do módulo principal
E, finalmente, o erro diz respeito não apenas ao Bitrix, mas já era muito doloroso para mim encontrar problemas associados a ele.
Verifique se a matriz está anulada com os resultados da seleção . Como exemplo, a última vez que encontrei esse problema foi ao trabalhar com uma loja online. Reclamação: as páginas às vezes carregam por 16 segundos. O que está conectado não está claro. Por tentativa e erro, descobri que as páginas são carregadas indecentemente por muito tempo quando a cesta está vazia. Parecia, por que? Como se viu, uma janela pop-up apareceu na cesta ao passar o mouse, na qual foram exibidas imagens das mercadorias colocadas na cesta. Bem, o que o desenvolvedor anterior fez? Peguei o resultado do componente "small basket" e, no arquivo result_modifier.php, fiz uma chamada para GetList () dos produtos para selecionar imagens com um filtro da matriz de IDs de produto e adicionei imagens src dos resultados da seleção à matriz do produto correspondente. Como resultado, quando não havia mercadorias na cesta, o filtro foi deixado vazio e o catálogo INTEIRO de mercadorias caiu na seleção. Bem, então um ciclo para cada um e ... nós temos o que temos. É claro que na fase de desenvolvimento do teste 15 produtos isso era imperceptível e já surgiram problemas em condições de combate. Embora pareça que valeu a pena colocar o cheque em branco ($ arResult ['ITEMS'])) ...
É aqui que encerro minha “pior prática” pessoal em relação ao desenvolvimento do Bitrix. Se pelo menos alguém esta informação ajudará a evitar erros no futuro e a melhorar seu estilo de desenvolvimento, isso não foi em vão.