Oi Recentemente, fiz um relatório para os alunos sobre quais solavancos podem ser preenchidos com o desenvolvimento da web moderna. Como estão relacionadas as várias decisões que tomamos durante o processo de desenvolvimento, como a escolha da tecnologia afeta o tamanho da equipe, como o tamanho da equipe afeta as abordagens de teste, como as abordagens de teste estão relacionadas à estrutura de toda a empresa.

Acabou sendo algo como uma busca com uma escolha distribuída: de qual linguagem de programação escolher e para quem é melhor contratar uma equipe que tornará o produto mais útil de todos os tempos. Sugiro que você leia este post, escolha suas opções, complete a missão e discuta o que se tornou doloroso.

upd - adicionou algum texto ao kat.

Da ideia ao protótipo

Suponha que minha amiga Valera e eu decidimos fazer uma startup. Uber para X , ou algo assim. Reunidos em um bar, discutimos essa ideia, tópico interessante. Deve fazer. Três meses não dormiram, não comeram, não saíram de casa. Desenvolvido. Eles começaram e perceberam que ninguém precisava disso.

Tristeza. Vamos tentar de novo. Desta vez, estudamos o mercado, analisamos quais usuários têm necessidades, quais problemas. Fizemos algum tipo de protótipo completamente no joelho, de forma rápida e gratuita em duas noites. O protótipo decolou. Legal, siga em frente.

Escolhendo a Tecnologia

Agora podemos pegar e fazer uma grande aplicação de um protótipo, desenvolvê-lo. Mas, para isso, precisamos adotar uma abordagem mais séria à escolha das tecnologias que usaremos.

Linguagem

Em ordem. Qual idioma escrever? Você pode usar o funcional da moda: Haskell, Erlang, Lisp (muito na moda entre os avós com mais de 70 anos). Ou outro JS matador, que é muito legal, compilado no JS, possui todos os recursos necessários. Mas, provavelmente, não teremos ninguém para contratar em um ano, porque o próximo assassino JS não decolará e precisará reaprender novamente ou reescrever o projeto.

Tentativa número dois. Você pode pegar algo verificado pelo tempo. Por exemplo, PHP. Essa é uma boa linguagem, está na moda criticar às vezes, tem suas desvantagens, mas é fácil fazer lógica de negócios, é rápida o suficiente, dimensiona bem, você pode contratar pessoas a qualquer hora e em qualquer lugar. Mas ele não é muito produtivo. Portanto, precisamos de muito ferro ou escrever nosso próprio compilador, como o Facebook ou o VK.

Mais opções? Você pode pegar Perl, mas depois não haverá ninguém para contratar ontem. Mais?
Java Java é a norma. Como linguagem, não é muito, na minha opinião subjetiva, mas a JVM é uma ótima máquina virtual, está tudo bem, funciona rapidamente, mas ainda precisa de muito hardware. E enquanto escrevíamos em Java um construtor abstrato da fábrica de estratégias, em vez de criar recursos, os usuários foram para os concorrentes.

Tudo bem, ainda temos Python. Em princípio, está tudo bem. Mas rodamos o aplicativo em Python, ele usa um núcleo de 56, caso contrário ... está tudo bem. Ou você pode pegar algo moderno: Vá, Ferrugem, outra coisa. Mas eles são de nível muito baixo e apenas fazemos recursos por um longo tempo ... Ainda precisamos escolher um idioma. Seja JS no final, desça.

Banco de Dados

Base. JS sem uma base de documentos - dinheiro pelo ralo. As bases de documentos têm suas vantagens. Eles nos permitem desenvolver rapidamente protótipos, para não nos preocuparmos com o esquema, com os dados de salsicha. Há muitas vantagens, menos uma: mingau dos dados. Quando temos dez, vinte ou quarenta coleções em vez de três, quando tentamos colar algo bom e digerível delas sem a ausência de esquemas, torna-se cada vez mais difícil de fazer. Mais uma vez, criamos recursos por um longo tempo.

Ok, vamos dar uma base relacional. MySQL, PostgreSQL ou Oracle, se você tiver dinheiro suficiente. Com bancos de dados relacionais, um dia você pode trabalhar e se encontrar no inferno com transações e armazenamentos. Isso não acontece necessariamente com o nosso projeto. Mas se isso acontecer, será impossível testar esses meandros da lógica. E mesmo que de repente alcancemos o limite vertical de nosso grande servidor gold no qual hospedamos o banco de dados, será bastante difícil separá-los. Fazemos recursos por um longo tempo.

Ok. Eles pegaram uma base, o ORM bateu na frente para facilitar a passagem de um SQL para outro. Algum dia (spoiler: nunca).

Arquitetura

Qual arquitetura levar? Os funcionários da Habré escrevem que os microsserviços são legais. Oleg Bunin diz: "tome microsserviços".

Se você começar com microsserviços, então, com uma probabilidade de oitenta por cento, os limites estarão errados porque eles não pensaram completamente no modelo de domínio e pouco entenderam onde cortar e onde não. Além disso, todos eles tomam microsserviços, os implantam em lotes em todo o cluster e, um mês depois, surge a pergunta: "Como posso testar isso agora?" Os serviços já funcionam na produção, mas não os testamos. Usando metodologias familiares (pirâmide de teste, testes de integração manual, testes de ponta a ponta), é difícil testar microsserviços. Portanto, estamos desenvolvendo recursos há muito tempo.

Ok, então vamos bater um monólito. Esta é a ideia certa para uma startup. Você pode viver com um grande monólito por muito tempo e sem problemas. Mas se decidirmos expandir bastante a equipe, devemos ter cuidado. O monólito é escalonado normalmente, enquanto os desenvolvedores têm 20, 30, 50. Além disso, a velocidade de entrega dos recursos diminui exponencialmente e perdemos usuários.

Por onde começar o projeto?

Tudo precisa ser lançado em algum lugar. 2018, a opção mais lógica para fazer isso na nuvem. Não corra na nuvem - os garotos vão rir. Mas, em primeiro lugar, existe a lei federal 152, que limita significativamente a escolha de provedores de nuvem que podem ser hospedados. Em segundo lugar, é muito fácil comprometer acidentalmente uma chave privada da sua conta no Amazon no Github, e alguém definitivamente vai gastar todo o seu dinheiro. E se isso não acontecer, em algum momento as tarifas da nuvem o estourarão.

Você pode alugar um data center. Talvez isso não seja tão eficiente em termos de recursos inicialmente, mas a longo prazo provavelmente será mais barato do que hospedar na nuvem. Mas aqui precisamos de pessoas que o apoiem. Na minha experiência, aqueles que amam e sabem como fazê-lo, realmente não gostam de se comunicar com todos os outros, por isso são organizados no departamento. E o departamento é separatismo. Quero dizer, será mais fácil trocar experiências dentro da equipe de administradores, mas no futuro isso pode não funcionar muito bem. Haverá perguntas com priorização de tarefas de outros colegas, com sincronização. Outros especialistas não saberão o que está acontecendo dentro do departamento que suporta nosso data center.
Em geral, o separatismo não nos convém. Logicamente, passamos à questão do recrutamento de uma equipe.

A equipe

Desenvolvimento

Digamos que descobrimos os idiomas, bancos de dados e onde hospedar o projeto. É hora de recrutar uma equipe. Você pode pegar alguns caras legais que resolverão todos os problemas: centenas de desenvolvedores, ninjas de back-end, você entende. Talvez dê uma carona. Mas, de fato, é provável que as estrelas convidadas:

• caras tóxicos que não farão nada e criarão uma atmosfera ruim na equipe,
• ou idealistas construindo pouco a pouco uma arquitetura impecável, colocando o ORM na frente de bases que você nunca precisa mudar ...

No final ... sim, estamos desenvolvendo recursos há muito tempo. Outra opção é pegar garotas e garotos comuns, que apenas escrevem código, fazem bons recursos. Mas se você pegar muitos desenvolvedores não muito experientes, com diferentes formações, eles podem escrever código em um estilo diferente, fazer as coisas de maneira diferente e, com um tamanho suficiente da equipe, todos ficarão confinados, todos terão chaves nas solicitações dos outros. Não é muito eficaz. Como isso pode ser resolvido? O chefe pode ler todo o código. Eu posso ler todas as pull-quests, e meu amigo e co-fundador, Valera, então a relerá pela segunda vez (por precaução, você nunca sabe). É claro que isso não aumenta e todos os recursos estão sendo produzidos lentamente.

Uma opção mais correta é definir um estilo de código para a empresa. Para muitos idiomas, ele já existe e você pode simplesmente segui-lo. Ou, se alguém realmente quiser, você pode pegar um já pronto e puxá-lo um pouco, e depois olhar para as solicitações de puxar e dizer que a chave não está lá, ela deve estar de acordo com o estilo do código. Você não pode argumentar com esse argumento, mas, na realidade, não é muito melhor que a versão anterior, de qualquer forma, estamos criando recursos lentamente. A opção correta para todos os idiomas modernos é verificar isso automaticamente.

Ok Marcamos desenvolvedores, código fig. Mas começamos a liberar recursos na produção e precisamos, de alguma maneira, garantir que os rolemos sem bugs, para que nada caia conosco.

Garantia de qualidade

Podemos dizer que não precisamos de especialistas em controle de qualidade. Muitos fazem isso, às vezes funciona. Mas nem todos os desenvolvedores gostam de escrever testes. Eles podem ser entendidos. E é melhor motivá-los a escrever os testes, mas a realidade é cruel: os testes de unidade não detectam todos os erros. E se algum desenvolvedor não gostar de escrever testes e ainda assim começar a escrevê-los, provavelmente serão testes de unidade.

Além disso, ainda existem abordagens quando você minimiza o tempo médio entre falhas em vez do tempo médio para se recuperar. O tempo médio entre falhas é quando um especialista em controle de qualidade diz: "não lançaremos, tenho um talento ruim, haverá bugs, vamos lançar em duas semanas". E o tempo médio de recuperação é quando você rola alguma coisa, imediatamente vê nas métricas que algo está quebrado e, após dois minutos, tudo foi revertido, corrigido e tudo está bem. Mas, para reverter o projeto em dois minutos, você precisa cobrir tudo com métricas normais, e isso nem sempre é trivial. E se as métricas estiverem em um estado deplorável e lançarmos uma versão ruim, podemos descobrir isso depois que todos os usuários nos deixarem para os concorrentes.

Outra opção: ainda faça um departamento de controle de qualidade. Você se lembra: o departamento não é muito bom, é separatismo, não nos convém. O separatismo pode ser resolvido com a ajuda de equipes multifuncionais. Sim, eles resolvem o problema de nosso administrador estar separadamente, os testadores são separados.

Mas eles criam outros problemas. Como desenvolvedores, testadores e todos os outros membros de equipes multifuncionais começam a se comunicar mais dentro de suas equipes e resolver problemas anteriores, eles se comunicam menos com seus colegas em suas funções: outros revisores e testadores, eles começam a reinventar a roda, fazem as mesmas coisas em paralelo, isolamento entre equipes. Furador de sabão: houve um separatismo, tornou-se outro.

Como resolver isso? Comunique-se com colegas em grupos de hobby. Em algum lugar é chamado de guildas, em algum lugar é comunitário. Se escalarmos a equipe com equipes multifuncionais para que elas não se tornem independentes, simplesmente organizaremos um círculo de fãs de back-end, linguagens funcionais, segurança ...

Sumário

De fato, nem tudo é tão ruim. Você pode encontrar uma saída para qualquer situação, encontrar uma solução. Talvez não seja o ideal, mas o mais adequado nessa situação com um mínimo de problemas. Um compromisso é sempre possível.

E, no entanto - tudo isso é interessante. É interessante resolver problemas que alguém já resolveu; novos problemas são ainda mais interessantes para resolver. É interessante compartilhar conhecimento.