🍁 🎳 👩🏽‍🏭 Maldito CRM antigo 🤥 🉐 🗞️

No ano passado, nossos funcionários finalizaram o CRM 2.0 com o BPMS Camunda e apenas dez processos, em vez de centenas de status, e tentaram implementá-lo para usuários e serviços sem perder nada. Espero que, depois de finalmente cortar o primeiro tcm-ku (a parte mais antiga de todos os Skyeng) do nosso ecossistema, eles compartilhem o ancinho e os achados aqui.

Enquanto isso, tendo me interessado pelo assunto, encontrei um caso semelhante - e decidi perguntar a Dmitry Kosov, da Finam, sobre sua experiência de abandonar a herança do início dos anos 2010.

Olá , sou o mesmo "Seryozha de Bryansk" que decidiu aumentar o conhecimento sobre desenvolvimento por meio de blogs e screencasts sobre o tópico PHP. Este ano, quero adicionar um podcast às minhas atividades: convidar colegas do setor para ele. No primeiro episódio, a história da mudança do primeiro Zend para o Symfony. Se você quiser mais detalhes técnicos, confira também a palestra de Dima no Youtube . Bem, em nossa discussão após o relatório, você saberá:

como não perder e encontrar motivação, se você entender que ainda falta um ano para lançar seu código em produção,

por que alguma documentação, se não está mentindo, está mentindo,

e como o processo de refatoração de dois anos é organizado sem interromper a produção de recursos usando o exemplo de um projeto e equipe reais.

Gosta de ler ou ouvir .

Quais estruturas foram escolhidas entre 2011? E como escolher um novo em 2016

Dima, Finam: Eu olhei especificamente, me preparando para o lançamento: temos exatamente 4.600 arquivos no papai, onde exatamente nosso código não é fornecedor, nem js. Esse papai pesa 16 metros. E o primeiro compromisso que já teríamos feito em dezembro de 2011 - seu autor ainda está trabalhando, este é o nosso líder de equipe.

Inicialmente, a pilha foi selecionada corretamente. E mesmo em 2012, era bastante moderno - o primeiro Zend era bastante relevante. Depois, trabalhei em outro emprego, mas lembro que no dia 12, no final da primavera, escolhemos a pilha para um novo projeto. Nós olhamos para:

Zend - o segundo acabou de sair, mas era muito jovem, não havia comunidade para ele,

primeiro Yii - mas não gostamos do conceito ActiveRecord,

Phalcon,

e algo mais do exótico.

E eles também escolheram o primeiro Zend. Naquele momento, foi uma escolha boa e relevante. Mas a língua foi adiante. Mas você deseja usar espaços de nome normais, em vez de nomear classes através de sublinhados. Eu gostaria de conectar algumas bibliotecas prontas a partir de código aberto, que, é claro, ninguém escreve no primeiro Zend. Eu gostaria de atrair funcionários para a equipe - algumas vezes quando procurávamos novas pessoas, para algumas estava escrito diretamente na cara: "Eu não aceito".

Por fim, o primeiro Zend simplesmente parou de apoiá-lo. Por exemplo, na versão 7.0, eles ainda lançavam um patch de atualização de segurança, e nós mesmos corrigíamos 7.2 e 7.3.

Nós puxamos um pouco com o início do processo de realocação.

Não havia risco global - apenas analisamos o que é moderno, relevante. Comparado com o de outros projetos: não somos a única equipe de PHP na empresa. Percebemos que o Symfony estava feliz com todos - parecia um projeto que durará vários anos, tem uma comunidade extensa, muitas bibliotecas prontas, novos utilitários e assim por diante.

Comecei esse negócio - eu estava cavando nos primeiros momentos apenas para me mudar, no movimento em direção ao Symfony. Quando cheguei, eu estava imerso em diferentes partes do projeto para que eu pudesse conhecê-lo o mais amplamente possível - e quando a refatoração em larga escala começou, eu já sabia o suficiente. E outro camarada veio depois que começamos. Mergulhamos no processo - mas tentamos não assustá-lo muito. Pelo menos no começo)

ESTÁ BEM. Nós escolhemos uma estrutura. Qual é o próximo?

Seryozha, Skyeng: Existem duas maneiras - você pode reescrever tudo de uma vez. Você pode tentar arrastar e soltar lentamente. Por onde você começou?

Dima, Finam: Começamos com o holivar, que caminho seguir. Ninguém teve a experiência de reescrever esse volume. Por exemplo, no meu trabalho anterior, tive experiência em reescrever um pequeno serviço autônomo - ali congelamos o desenvolvimento por um mês, reescrevemos tudo e continuamos. Aqui não teríamos sido suficientes por um ano. Talvez nós tivéssemos conseguido fazer 80% em um ano, mas, você sabe ...

Há um princípio: os primeiros 80% do trabalho levam 80% do tempo. Os 20% restantes do trabalho levarão outros 80% do tempo.

Era impossível parar o aplicativo e suas tarefas atuais. E existem exatamente dois conceitos para este caso: você está fazendo algo com o aplicativo atual ou está implantando um novo. Recusamos a opção de implantar um novo - porque há muito código. Como resultado, não implantamos o aplicativo Symfony próximo ao antigo, mas em cima dele.

Mas por que sim? Temos mais de 250 tabelas no banco de dados e, se você remover algumas placas de serviço, são cerca de 200 entidades. Eles estão fortemente conectados entre si e, devido a esse número de conexões, é muito difícil obter o código em algumas partes lógicas autônomas. De qualquer forma, não quebre, uma conexão ficará fora dessa peça: por exemplo, chamadas e telefonia são conectadas a gerentes e clientes. Portanto, percebemos: se você implantar um novo aplicativo, comece a escrever novos recursos para ele e a transferir lentamente os antigos, isso resultará em trabalho duplo. Afinal, o código que transferiremos para o novo aplicativo não pode ser completamente cortado do antigo. E teremos que apoiá-lo em dois lugares.

Então nos lembramos de outra experiência que nossa equipe já teve.

Essa é a experiência de reescrever uma camada para acessar dados. Porque era uma vez, juntamente com o primeiro Zend, o Mongo foi escolhido como o banco de dados principal. Mas a prática mostrou que a escolha não é muito correta.

Seryozha, Skyeng: Sim, você tem todas as conexões relacionais, mas escolheu um banco de dados orientado a documentos.

Dima, Finam: Sim, e quando cheguei, os caras estavam reescrevendo do Mongo para o PostgreSQL ... E tivemos a ideia de que possuímos uma camada de acesso a dados. E como já sabemos como reescrever as camadas para acesso a dados, talvez a possamos ampliar um pouco e imediatamente pegar a camada ORM.

Se você imaginar o aplicativo como uma torta, haverá 5 camadas: ORM, acesso a dados, lógica de negócios, controlador, visualizações. E podemos tocar em 2,5 camadas - alterar completamente o ORM e acessar os dados, além de parcialmente - a lógica de negócios. Não os algoritmos em si, mas as classes e objetos com os quais esses algoritmos funcionam. Eu sabia claramente que é possível digerir a doutrina separadamente, bem, eu fiz.

Então, entrei no bootstrap, inicializei a doutrina lá, prescrevi todas as configurações necessárias - e dei aos caras uma revisão de código com as palavras: "Bem, alguém deveria ter começado isso".

O início do caminho pode ser algo assim. E então aplicamos o princípio de que um mamute deve ser comido em partes. Às vezes, as peças acabavam sendo mais do que pensávamos, mas a tarefa básica do sprint de duas semanas era dar um movimento - e garantimos que não houvesse tarefas de destaque na mesma área.

Eu peguei insetos, revirei, desenrolei

Seryozha, Skyeng: Ainda assim, a refatoração é uma coisa crucial, como você se segurou ?

Dima, Finam: Temos vários testes de unidade - eles cobrem pontos-chave. Existem vários testes funcionais automatizados por nosso testador. A principal tarefa do CRM é trabalhar com dados. E para testar sem dados, com testes de unidade nem sempre é possível: é mais fácil enviar um pacote, verificar se ele é processado normalmente, se uma entidade com os parâmetros necessários foi criada nele.

Naturalmente, verificamos muito com as mãos: especialmente algumas coisas importantes e importantes, como os mesmos clientes e chamadas.

Lembro-me bem de como fiz essa tarefa. Liguei para o chefe da central de atendimento e concordamos que, quando o dia de trabalho acabasse e apenas o atendente permanecesse, eu entregaria tudo e o atendente verificaria tudo em ligações reais. Eu dei o meu melhor, observei nos logs, peguei um monte de insetos, rolei para longe, governei-os, avisei o atendente, desenrolei, peguei novamente o pacote seguinte, recuei ... E algumas iterações.

Seryozha, Skyeng: Tendo percorrido todo o caminho, mas agora é provavelmente mais da metade do caminho, o que você recomendaria então?

Dima, Finam:Provavelmente, eu recomendaria a implantação do mesmo aplicativo Symfony um pouco antes do nosso. Para garantir que o que escrevemos, o que fazemos, realmente funcione. Lembro-me de como a implantamos, a lançamos primeiro no console e depois no controlador, atropelamos nossa camada de lógica de negócios - e garantimos que o aplicativo a veja, possa acessar todos os serviços, usar todos os métodos, descarregar os resultados.

Acabei de perceber o quão forte era um motivador ao perceber que realmente escrevemos tudo corretamente. Para verificar se você está indo na direção certa, para garantir que está fazendo tudo corretamente, isso deve ser feito cedo.

Não nos primeiros passos, mas quando você já tiver algo escrito, faça assim, fotografe para o próximo ano, organize uma máquina local, verifique se está fazendo tudo certo - isso lhe dará força. E você irá além.

ps

Obrigado por ler e ouvir. Mais podcasts PHP podem ser encontrados aqui .

E se você quiser relatórios e conversas mais interessantes, "venha" para a terceira reunião virtual do PHP em 30 de maio.

Maldito CRM antigo