Como manter a consistência na arquitetura do aplicativo à medida que a equipe cresce?

Como o único desenvolvedor de uma startup, tive o luxo de poder tomar muitas decisões na arquitetura e nas estruturas de nosso aplicativo.

Avançando rapidamente 4 anos e uma aquisição depois, tenho uma equipe de 5 e muitas vezes parece o oeste selvagem. As pessoas que tomam qualquer decisão de design lhes agrada: número inteiro e enumeração para tipos de banco de dados em um local e cadeia de caracteres em outro, essa estrutura para um problema e, em seguida, uma estrutura diferente para o mesmo problema em outro lugar, etc.

Como faço para impor consistência? Parece importante para mim, mas os membros da minha equipe parecem se inscrever na metodologia "se funcionar, funciona".

Acho que grande parte da minha pergunta é: não é realista da minha parte esperar padrões como esse? Eu luto com a idéia de parecer um ditador que sufoca a criatividade, mas fazer o que eles querem parece não ser escalável.

O que te faz tão especial?

Minha CPU diz que funciona e eu quero ir para casa. Por que você está me incomodando?

Você pode lidar com essa atitude forçando todos a emitir solicitações pull. Mas agora os prazos estão chegando. Um código ruim pressiona os portões do seu castelo intocado e você finalmente cede à pressão. Ou você ganha apenas para encontrar todos que saem e ninguém usa seu castelo intocado.

Existem muitas ferramentas que ajudam com esse problema. Controle de fonte, revisões de código, padrões de codificação, etc. mas o coração e a alma do problema são suas opiniões subjetivas sobre o que é melhor, que devem ser vistas como relevantes. Para isso você tem que ganhar e manter o respeito deles. Faça isso e isso é muito mais fácil. Deixar de fazer isso e nenhuma ferramenta ou prática o salvará.

A melhor maneira de fazer isso é se comunicar cedo. Não me diga "não usamos seqüências de caracteres para nossos tipos de banco de dados nesta loja" seis meses depois de ter decidido sobre a idéia. Dizer-me que está enterrado na documentação há 2 anos não é justificativa para me deixar fazer isso.

Por qualquer motivo, você tem coisas importantes. Se você se importa com eles e tem razão, comunique claramente essas coisas antes, durante e imediatamente após a codificação de cada módulo.

O stalking de código é uma prática maravilhosa. Invista nas ferramentas e práticas necessárias para que você possa revisar o código alguns minutos depois de ter sido escrito. Emparelhe o programa e a ferramenta é simplesmente uma cadeira de convidado.

Por quê? Cada segundo que passa depois que eu escrevo o código aumenta exponencialmente o custo para alterá-lo. Isso porque minha memória do código tem meia-vida. Começo a esquecê-lo no momento em que minha bexiga exige uma pausa.

Reduza as coisas importantes para os princípios subjacentes. Em vez de me acertar com uma lista de 101 regras a seguir, dê-me os 10 princípios que violam, para que eu possa descobrir qual é a regra 102 por conta própria.

Permita-me impor minha própria visão, ajudando-me a ver a sua e nos daremos muito bem.

não é realista da minha parte esperar padrões como esse? Eu luto com a idéia de parecer um ditador que sufoca a criatividade, mas fazer o que eles querem parece não ser escalável.

Então não dite! Faça disso uma experiência positiva. Isso não é um absurdo hippie da nova era. É psicologia básica. Você está tentando modificar o comportamento humano. Aleatório e positivo é o mais reforçador (basta perguntar a Las Vegas). Se você for negativo, precisará ser consistente com o seu reforço. É uma dor inatingível. Seja positivo ao espalhar a sabedoria e pode ser casual sobre isso.

Eu sei de onde você vem, porque eu estive lá. Você tinha controle e agora se foi. Você quer de volta. Bem, supere isso. Agora você tem uma equipe. Eles não precisam ser controlados. O que eles precisam é de liderança. O que você precisa não é controle. É influência. Funciona melhor e é muito menos trabalho. Domine isso e relaxe. Isso deve ser divertido.

Faça o certo e você pode sair de férias e isso ainda funcionará. Quão? Não apenas sendo um líder, mas também fazendo com que os outros sejam líderes. Depois de instilar sua visão na equipe, eles podem trabalhar enquanto você estiver fora, simplesmente imitando o que está fazendo. Orientar os novatos e incentivá-los a intensificar e influenciar os outros também.

Sei que é difícil. Nós não entramos nessa profissão porque somos bons em lidar com pessoas. Nós nos comunicamos melhor com o código. Isso é bom. Basta fazê-lo rápido e com frequência. Mostre-me por que o seu é melhor. Ouça se eu disser que não é. Faça isso enquanto eu ainda estou pensando sobre isso. Eu amo codificar. Há poucas pessoas no planeta que eu posso falar sobre isso. Seja um deles.

Primeiro, peça às pessoas que mantenham coisas que não escreveram. É muito fácil para um desenvolvedor adquirir hábitos de usar estruturas e técnicas com as quais está acostumado. É chocante ter que alternar entre estruturas e metodologias. Se alguém é forçado a sair do seu próprio canto do código e experimentá-lo com tanta frequência, isso levará a algumas queixas e, esperançosamente, a uma discussão produtiva que pode levar as pessoas a querer padronizar alguma coisa.

Em seguida, puxe solicitações e revisões de código. Nunca permita que o código seja mesclado com suas ramificações principais sem uma revisão de código primeiro. Qualquer um pode fazer isso. Novamente, quando alguém vê algo diferente do que teria feito, isso pode levar a discussão e trabalho em equipe a chegar a uma solução melhor. Também faz de todos um cuidador da base de código, o que (espero) leva as pessoas a se importarem com ela e com o estado do código que entra nela.

Por fim, faça discussões de design. Eles podem ser formais ou informais, mas tê-los. Deixe aqueles que querem participar façam isso. Discuta quais estruturas você deseja usar, os prós e os contras de enums vs ints, etc. Em seguida, tome uma decisão e documente-a em algum lugar (como um documento de padrões). Então você tem algo a apontar quando surgem problemas. Além disso, não tenha medo de revisitar uma decisão de padrões. A tecnologia muda (rapidamente) e suas necessidades em equipe e empresa também.

Ajude as pessoas a ver o que você vê e sente que elas têm interesse na qualidade do código. Em seguida, estimule suavemente as discussões para encontrar um padrão quando surgirem diferenças de opinião.

Realize revisões de código sempre que alguém desejar mesclar código na ramificação / tronco principal e manter as pessoas com esses padrões ao revisar o código.

E não quero dizer que apenas você deve executar as revisões de código. Todos devem revisar o código de todos os outros. Isso divulga o conhecimento sobre o sistema em toda a equipe, mas também cria uma situação em que Carol revisa o código de Bob e diz: "Vejo que você usou um número inteiro lá. Sempre uso uma enumeração". Eles descobrem as discrepâncias que você viu e, assumindo que se importam, perceberão que todos devem entrar na mesma página.

Os padrões aceitos e acordados surgirão, quando você os documenta e garante que as pessoas os sigam. Isso inclui itens como "enumerações no banco de dados para ..." etc. Você também pode incluir a documentação de quais estruturas usar, etc.

Onde possível, você pode escrever ferramentas / scripts para analisar automaticamente seus projetos e determinar quais padrões, ferramentas e abordagens o projeto está usando. Você pode fazer isso executando uma ferramenta personalizada como parte de uma compilação de IC.

Tenha a saída das ferramentas gravadas em um documento de 'scorecard', por exemplo, uma planilha do google com uma linha por unidade (por exemplo, por 'aplicativo' ou projeto ou API ou qualquer outra coisa), com colunas para as várias métricas / padrões seguidos. Isso dará às pessoas visibilidade sobre quais padrões existem, quão bem adotadas são, etc., e fornecerão alguma ordem ao caos.

Você também pode ter colunas atualizadas manualmente, mas boa sorte em mantê-las atualizadas: D

Além das respostas fornecidas, eu digo que você deve educar sua equipe sobre o que você espera deles como profissionais de desenvolvimento de software, a partir do momento em que eles estão entrevistando para ingressar na empresa.

1 - Crie e siga convenções da base de código

Essa é uma das medidas mais básicas e benéficas que você pode adotar para melhorar a qualidade do código. Como resultado das convenções a seguir, o código-fonte será uniforme em toda a base de código, reduzindo o esforço cognitivo para pesquisar e ler arquivos de código.

2 - Implementar arquiteturas de software claras

A base de código de um projeto de software que não segue um estilo arquitetural claro, qualquer que seja, deteriora-se gradualmente à medida que um código não estruturado é adicionado a ele, tornando-se mais difícil de modificar. Daí a importância de dedicar horas para o design e conservação de uma arquitetura de software adequada.

3 - Menos é melhor: Idiomas, Frameworks e Ferramentas

Com cada linguagem, estrutura e ferramenta adicionais que você introduz no seu sistema, há um custo operacional e de desenvolvimento adicional. Você sempre deve avaliar os custos de longo prazo de uma decisão tecnológica antes de resolver um problema de curto prazo. Evite tecnologias redundantes e tire o máximo proveito da sua pilha atual.

4 - Envolva sua equipe nas decisões de design do sistema

A maneira mais eficaz de criar um ambiente de conhecimento compartilhado é envolver a equipe em todas as decisões de design do sistema. Os benefícios são muitos:

• Os indivíduos se sentem valorizados e fazem parte da equipe
• Decisões importantes são contestadas por toda a equipe antes de serem tomadas
• Os pontos fortes e fracos do projeto do sistema são mais claramente entendidos por todos
• Cria um senso de responsabilidade coletiva e confiança

5 - A regra do all-in

Sou de opinião que os esforços para refatorar um design de sistema devem ser conduzidos até a conclusão (all-in), em vez de serem parcialmente concluídos. Há um grande risco de corroer o design do sistema se os desenvolvedores se sentirem livres para aplicar diferentes estilos de codificação e padrões de arquitetura localmente, sempre que acharem melhor.

A essa altura, se você implementou com êxito as sugestões anteriores, sua equipe provavelmente avaliará esse comportamento desonesto do desenvolvedor como não profissional e irresponsável.

Escrevi recentemente um post sobre este assunto. Você pode encontrar informações detalhadas sobre esses tópicos: https://thomasvilhena.com/2019/11/system-design-coherence