Neste post, falarei sobre os problemas que nossa equipe de Scrum Front End enfrentou durante um ano trabalhando em um projeto decente. Começamos a desenvolver o projeto do zero usando a pilha de tecnologia React + Typescript. Olhando para trás, vejo muitos milhões desperdiçados simplesmente porque o processo de desenvolvimento não foi definido desde o início. Mas há razões para isso.
Primeiro você teve que ganhar a licitação. Para fazer isso, foi necessário arquivar rapidamente um Produto Mínimo Valioso. E aqui está o primeiro erro que custa uma quantia decente para o nosso cliente. Parece assim: rapidamente corte o MVP. O cliente deseja ver rapidamente o resultado, mas isso significa que sacrificamos boa infraestrutura, arquitetura confiável e, um ano depois, chegamos à conclusão de que nossa arquitetura Front-End requer séria refatoração. Cerca de alguns meses. Então, vazamos 500.000 rublos.
Olhando para trás, posso dizer com confiança que a primeira coisa a fazer foi levar em consideração todas as funcionalidades que o cliente queria ver no final, depois de alguns anos. Portanto, poderíamos evitar erros de arquitetura no estilo de "essa arquitetura não prevê isso". Como resultado, cada chip principal exigia uma refatoração séria.
Para vencer a licitação, nossa empresa enviou desenvolvedores que não tinham experiência em projetar aplicativos grandes e sistemas extensíveis confiáveis. Negócio claro, o concurso não é uma ordem e ninguém quer espalhar um bom pessoal. Mas a falta de um arquiteto técnico no (nível de classe) levou ao fato de que nosso aplicativo se transformou em código espaguete e parou de atender aos requisitos do SOLID. E aqui está o erro de cada cliente. Não é possível manter um ritmo constante de desenvolvimento sem aumentar os recursos da equipe. O princípio Ágil “Investidores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente” só funciona se os requisitos forem conhecidos e elaborados desde o início, todo o conjunto de funcionalidades, uma arquitetura confiável e extensível foi projetada (em uma palavra, se cada classe fosse pensada levando em consideração o resultado final). funcionalidade do sistema) e processos claramente definidos. E isso tinha que ser feito em MPV antes de serrar o produto. Caso contrário, com o tempo linear, a complexidade do aplicativo aumenta exponencialmente. Isso significa que o recurso de corte em um ano custará O (e (N)) mais caro do que no início.
Em nossa equipe, o único designer era um funcionário remoto. Foi um erro grave. Um funcionário remoto sempre vive sua própria vida. Ele desenha um design para si mesmo, lindamente e bem, o cliente está feliz. Mas todos esses encantos acabam resumindo-se ao fato de que, nas mesmas formas lógicas, temos N estilos e layouts diferentes. Desde o início, valeu a pena colocar um requisito: estilizar uma certa estrutura (tínhamos o Ant Design). Se algo não estiver lá, faça o que está lá. O cliente achou que o React era um construtor de blocos. E ele ainda não entende por que estamos vendo formas primitivas por 4 dias. React é um construtor, mas somente se, no início do desenvolvimento, tivermos um conjunto de componentes reutilizáveis semelhantes (estrutura da interface do usuário). Um designer sem experiência em layout nunca fará isso sozinho. O desenvolvedor nunca dirá ao cliente sobre isso. Isso deve ser seguido pelo líder. Portanto, o líder da equipe do Front-End deve ser o desenvolvedor do Front-End no passado, e não o Back-End como sempre. Portanto, chegamos à conclusão de que uma equipe Agile totalmente funcional deve incluir um líder competente em cada uma de suas áreas de trabalho (FE, BE). Esses líderes devem ter fortes habilidades de Soft para transmitir ao cliente o que estou tentando descrever neste artigo. E isso é muito, muito difícil.
Quando lançamos o primeiro lançamento, percebemos que algo estava constantemente quebrando no último dia antes da demo. Ao longo do ano de desenvolvimento, cada ramo de lançamento se transforma em um conjunto infernal de muletas (desligue-o, remova-o) que depois magicamente termina no ramo de desenvolvimento. E há uma série de confirmações (ative, ative). Depois de um ano, chegamos à conclusão de que precisamos ter uma política clara de ramificação. Mas o mais importante, uma pessoa responsável que eliminaria o caos existente. Isso significava: moderar os desejos caóticos do cliente ou moderar os bugs caóticos ou, em cada estande, ter sua própria configuração desativando algum tipo de recurso ou botão gráfico. Quebrar cada botão em uma instrução if é uma loucura. Chegamos à conclusão de que precisamos de uma arquitetura Front-End modular de recurso de plug-in (desativar - ativar). Estou pensando há muito tempo em como conseguir essa arquitetura. Mas uma coisa eu entendi com certeza. Precisávamos de um contexto completo. Assim, a biblioteca js-beans nasceu (https://www.npmjs.com/package/js-beans). Cada estande teve seu próprio contexto json. Os plug-ins foram coletados em uma cadeia (cadeia) através do padrão Proxy. Assim, por exemplo, tínhamos uma fonte de dados como um compartimento separado e várias transformações foram feitas como compartimentos de proxy opcionais, substituindo esse compartimento, mas injetando-o em si. Por exemplo, se você precisar dimensionar o modelo de dados para testar o desempenho do FPS, basta adicionar a linha para ativar o plug-in de dimensionamento no arquivo json. Algo quebrou na produção, mas não é reproduzido localmente, ligo o logger com uma linha sem reconstruir o estande (o estande leva cerca de 20 minutos e uma dúzia de estandes nem sempre é suficiente para todos). Ou se você precisar desativar rapidamente algum módulo devido ao fato de ele poder ser quebrado (desative o bean opcional no contexto).
Com o passar do tempo, as arquibancadas foram desligadas por uma semana. Era impossível desenvolver a frente localmente. Não fornecemos arquitetura autônoma nos mokas. Eu tive que cortar através da dor com um rangido. Olhando para trás agora, eu teria feito isso no começo. Mas tínhamos MVP e fomos forçados a escrever código sem uma engenharia profunda. Mas o cliente nos considerou profissionais e achou que deveríamos escrever código imediatamente, sem erros. Aqui está o seguinte erro. O nome da empresa não fala sobre o profissionalismo da equipe. O profissionalismo da equipe é determinado pelo profissionalismo do líder da equipe. Se não houver um líder técnico na equipe, em um ano o seu projeto será interrompido. Então você mescla mais alguns milhões.
Tínhamos um arquiteto remoto. Mas só se sabia uma coisa sobre ele: ele é. A última etapa do desenvolvimento do líder, de acordo com Vladimir Tarasov. Nisto, nosso arquiteto alcançou a perfeição. Erro número N: você não tem um arquiteto técnico que projeta o sistema no nível da classe. Você não tem uma pessoa para pedir ajuda se estiver parado. Peça ajuda a outras equipes mais experientes, disse o cliente. Mas, por alguma razão, as outras equipes nunca tiveram tempo para nos ajudar. Nosso PR está suspenso pelo segundo mês. Espero sinceramente que haja um homem corajoso que o aprovará. Como resultado, a vida recompensou nosso código com uma rica abundância de fenômenos paranormais na forma de magia e conjuntos de muletas para todas as ocasiões. Apenas um estava faltando. Anotações especiais
Magic e @Kostyle. Boa ideia para o próximo ES.
Decidimos que mais intermediários e menos homens seriam mais lucrativos para o projeto. Agora pensamos de maneira diferente. Se você tem um orçamento pequeno, precisa contratar os especialistas mais caros. Se você, como o nosso, não tiver problemas de orçamento, poderá economizar com especialistas e transformar a Revisão de Código em uma batalha psíquica.
Pensamos que cumpriríamos os prazos trimestrais. Agora pensamos de maneira diferente. Em suma, para sempre, precisamos reescrever o projeto. E de preferência do zero. Espero que nosso cliente nunca saiba disso. Afinal, apenas recentemente tivemos uma magnífica formação de equipes)
Decidimos brincar com novas tecnologias nas quais tínhamos pouca experiência. Eles foram recomendados para nós. Claro que queríamos ganhar experiência. Agora, acho que seria melhor usar apenas as tecnologias em que tenho experiência.
Fornecemos estimativas com base em um dia útil de 8 horas. Na realidade, as estimativas devem ser feitas com base em um dia útil de 4 horas. Por que ninguém inclui chá, conta histórias interessantes, procura de um banheiro no navegador, fala ao telefone, correspondência, estuda novas tecnologias e, mais importante, disputas entusiasmadas dentro da equipe. Este último é provavelmente o mais inevitável e o mais caro. Embora, para ser honesto, para o Open Space você ainda precise jogar algumas horas. Conversas constantes reduzem terrivelmente a concentração. Bem-aventurado o cliente que entende tudo isso!
Nossas estimativas eram exaustivas e se transformaram em uma polêmica técnica tediosa. A eficácia dos comícios foi mínima. Mas encontramos uma solução: pizza deliciosa. Quando um cheiro delicioso irrita o nariz, uma pessoa começa a expressar seus pensamentos com mais clareza.
No começo, tínhamos um time pequeno, depois um time grande. O planejamento levou 2-3 horas. 30 minutos em pé. Pelo que eu respeito nosso pedido, é porque ele decidiu dividi-lo em muitos pequenos e alocar seu próprio mini pedido em cada um deles. Esta foi provavelmente a melhor decisão na história do nosso projeto.
Desde o início, não tivemos tempo para escrever testes. Depois de meio ano, chegamos à conclusão de que eles ainda precisavam ser escritos. Mas ainda não encontramos tempo para isso. Acúmulo de dívida técnica com alta prioridade acumulada. Não economize dívidas técnicas - isso é utopia. Ele sempre será.
Minhas conclusões subjetivas pessoais:
- Se seus desenvolvedores não entenderem para que serve o IOC for FrontEnd, provavelmente, quando entenderem, será tarde demais.
- Se seus desenvolvedores não entenderem por que o FrontEnd precisa de conhecimento de OOP, dificilmente seu código poderá ser suportado.
- Especialistas menos caros são melhores que os mais lucrativos.
- Se você tem um arquiteto, provavelmente precisará de mais um.
- Se você estiver vendo o MVP, conclua-o e altere o projeto.
- Se o MVP já foi gravado antes de você, não vá para este projeto.
- Se você cortar o MVP e não quiser sair, provavelmente mudará de ideia.
- Se você zapilili MVP e deseja que seu projeto sobreviva, reescreva-o do zero.
- Se você mostrar este artigo a um cliente, provavelmente será demitido.
- Se você trabalha com Agile, provavelmente você me entende.
É improvável que você evite todos esses problemas, mesmo depois de ler este artigo. Meu objetivo é mostrar que isso é inevitável. E não importa o quanto você tente, você nunca terá condições ideais. Então, esteja preparado para isso. E antes da demissão, você pode mostrar com segurança este artigo ao seu cliente. Que ele esteja moralmente pronto para isso.
PS: Maxim, se você já leu este artigo, sabe que tudo o que descrevi é completamente fictício e não tem nenhuma semelhança com o nosso projeto) Mas tudo isso não é importante, porque hoje estou saindo de férias. As primeiras férias em um ano de trabalho irregular meticuloso! (como lead FE).