Desenvolvimento Full Stack
O termo desenvolvedor full-stack está sendo usado com mais frequência recentemente. Particularmente em discussões sobre estrutura de equipe, requisitos para recrutamento ou para inferir a pura grandiosidade de um indivíduo.

Quando vejo esse tipo de declaração em um currículo ou ouço alguém se descrevendo como full-stack, várias perguntas vêm à mente:
- O que você quer dizer com desenvolvimento full-stack?
- Sobre qual pilha você está reivindicando o domínio?
- Quão extenso é o seu conhecimento para cada um dos elementos? Quão cheio ele precisa ser?
- O desenvolvedor full-stack é uma coisa real? Eles realmente existem?
- Se existem, por que são úteis?
- Full-stack é outra maneira de dizer Jack of all trades, mestre de ninguém?
Fundo
Antes de entrarmos nos detalhes, vale a pena definir o que pretendemos desenvolver e entregar.
Afirmar ser um desenvolvedor full-stack para uma PoC em execução em seu laptop é sem dúvida uma descrição justa, pois você é a única pessoa que desenvolve todas as partes dessa solução. A escala é muito pequena e o impacto de um design ou desenvolvimento inadequado é muito limitado. Fundamentalmente, você está provando um conceito, não entregando um serviço, desde que funcione para uma hora de demonstração para o CIO, tudo bem.
Se definirmos a solução como um sistema de produção que lida com dados de clientes ao vivo e produz insights/dados que impulsionam a geração de valor de negócios, a situação é diferente e o impacto de erros de codificação ou más práticas é muito maior.
Para os fins desta postagem, consideraremos um sistema que processa grandes quantidades (10s de GBs por dia) de dados reais de clientes (incluindo PII) e fornece serviços comerciais importantes com pelo menos 2 9s de disponibilidade.
Por que os desenvolvedores full-stack são valiosos?
Colocando de lado a existência de tais pessoas, os benefícios que elas fornecem são evidentes. Eles são capazes de projetar, construir e executar uma solução sem nenhum suporte externo; isso significa que todos os workshops de design demorados e propensos a erros, integrações de componentes, ciclos de teste e transferências de operações são amplamente eliminados. Não há necessidade de agendar uma reunião, ou pior, uma série de reuniões, entre a segurança, plataforma, banco de dados, operações, … SMEs porque você é capaz de projetar, construir e executar a solução. Um pequeno número desses desenvolvedores semelhantes a deuses (g pequeno) é capaz de entregar o trabalho de uma grande equipe multifuncional e, devido à eliminação da sobrecarga de transferências, a entrega também é muito mais rápida e menos propensa a erros.
Então, com base nesses benefícios claros, por que não há mais equipes compostas por essas pessoas em todas as organizações de TI? Por que as empresas não estão recrutando e treinando ativamente para construir essas equipes ninja? É porque equivalentes de desenvolvimento de Batman ou Tony Stark realmente não existem?
Para responder a essas perguntas, precisamos ver como é uma pilha (muito) simplificada.
pilha simplificada

Estou deixando a infraestrutura da plataforma de fora para fins de simplificação.
Olhando para os elementos acima, é óbvio que ser um especialista em cada camada será um desafio. No entanto, assumindo que não preciso saber TUDO em cada camada, posso reduzir o conhecimento necessário e ainda ser considerado full-stack? Tomando o aplicativo Front-End como um domínio de exemplo, poderíamos remover facilmente o Android e o iOS e focar apenas em um canal da web e talvez refinar ainda mais e dizer que é limitado ao React, como isso ajuda?
Com base em nosso escopo reduzido, o que preciso saber sobre aplicativos da web React?
Bem, em primeiro lugar, você precisará entender como os aplicativos de página única funcionam, especialmente os princípios básicos necessários para criar, depurar e executar um aplicativo da web e as ferramentas associadas, por exemplo, npm, webpack, gerenciamento de conteúdo, react devtools, diretrizes de UX, …
Você também precisará estar muito familiarizado com a funcionalidade fornecida por terceiros, por exemplo, material UI, redux, bootstrap, … e uma solução de gerenciamento de pacotes, como npm (incluindo o gerenciamento de vulnerabilidades de segurança — normalmente uma consideração do DevOps, consulte as notas posteriores).
E quanto ao desempenho, por exemplo, tempo para a primeira pintura de conteúdo, tempo para interação, tempo de bloqueio, … Devo adotar uma arquitetura de aplicativo da Web progressiva e/ou service workers para ajudar? Você precisará entender os fatores de desempenho e como os vários padrões principais podem ajudar a utilizar ferramentas para dar suporte à análise, por exemplo, React DevTools ou Lighthouse.
Acessibilidade é uma obrigação para todos os aplicativos, independentemente de o aplicativo ser entregue interna ou externamente. Como faço para garantir a conformidade com as diretrizes WCAG?
Em resumo, apenas na camada Front-End é muito para saber e, sem dúvida, isso é mantê-lo leve. As camadas restantes não são diferentes e, em muitos casos, a complexidade aumenta. E para piorar as coisas, os padrões e princípios arquitetônicos, as melhores práticas e estruturas NÃO SE SOBREPOSTEM .
Então, supondo que eu tenha conseguido enfiar os padrões, padrões, melhores práticas e habilidades práticas para cada camada em minha cabeça sem explodir, o que mais eu preciso saber? Existem recursos de suporte necessários?
Recursos de suporte
Ao lado da pilha de tecnologia, há vários recursos de suporte necessários para projetar, construir, entregar e executar todos os componentes da solução.

Arquitetura e Engenharia SW
Conjunto básico de habilidades para dar suporte ao projeto arquitetônico em todas as camadas, criando uma boa implementação em qualquer linguagem/framework
- SÓLIDO (Responsabilidade única, Aberto/Fechado, Substituição, Segregação de interface, Inversão de dependência)
- 'illities' reusabilidade, manutenibilidade, portabilidade, extensibilidade, …
- Escala horizontal e vertical
- estrutura de codificação
- Exploração madeireira
- Revisões de código
- …
Cada uma das camadas e componentes dentro de cada camada (ignorando o Front-End de uma perspectiva de canal da Web, pois é implementado pelo navegador ou normalmente fora de nosso controle, pois é do lado do cliente) na pilha simplificada acima requer consideração cuidadosa de uma perspectiva de segurança por exemplo
- APIs : TLS, DDoS, autenticação e autorização, CORs, política de segurança de conteúdo, …
- Microsserviços : TLS (incl MA), controles de acesso, gerenciamento de segredos, validação de entrada do usuário, …
- Dados : controles de acesso, criptografia em repouso, gerenciamento de chaves, grupos e sub-redes de segurança de rede, …
- Plataforma (adicional) : segurança de rede, configurações de componentes fixos, por exemplo, ChefInspec
Todos os desenvolvedores precisam de habilidades básicas de teste, não há desculpa para não poder testar seus próprios recursos. E em um ambiente de pilha completa, isso significa todos os componentes do diagrama acima.
Compreender e ser capaz de aplicar os diferentes tipos e fases do teste (sem corrigir o seu próprio dever de casa):
- Funcionais e não funcionais
- Caixa preta x caixa branca
- Unidade, integração, sistema, aceitação do usuário, regressão, fumaça, …
Desenvolver e manter pipelines de Integração Contínua e Implantação Contínua
Os principais facilitadores do CICD geralmente são criados por uma equipe centralizada/dedicada, mas todos devem ser capazes de atualizar e manter os pipelines, no mínimo. (Sim, eu sei; se você tem uma equipe DevOps, não está fazendo DevOps, mas muitas organizações fazem)
Utilizando ferramentas como:
- Jenkins, Travis CI, Spinnaker
- GitHub, Bitbucket
- Sonarqube
- Zaproxy
- Veracode, Snyk
- Docker, Âncora, Porto
- …
Se ignorarmos a abordagem “você constrói, você executa”, os requisitos de um desenvolvedor full-stack em relação às operações são significativamente simplificados
O foco precisa estar na construção de seu aplicativo para ser operável. Incluindo todos os ganchos de diagnóstico necessários, logs de eventos e um livro de execução para que uma equipe de execução seja capaz de fazer a triagem e potencialmente resolver problemas sem precisar da ajuda da equipe de desenvolvimento
Obviamente, a responsabilidade pelos recursos acima provavelmente será baseada em como sua organização é gerenciada - talvez o desenvolvimento seja estritamente apenas teste de unidade ou todos os testes sejam realizados pela equipe scrum, com exceção dos testes de segurança. Mas se você puder assumir o desenvolvimento da API e o gerenciamento do pipeline CICD sem precisar do suporte de outras pessoas, economizará muito tempo.
Assim como nas camadas da pilha de tecnologia, o escopo dos recursos de suporte necessários para reivindicar o status de pilha completa é vasto.
Conclusão
Eu acredito que o verdadeiro desenvolvedor full-stack seja um mito (em grande parte) e tem sido desde que a pilha foi além de executar o assembler em um 6502 na década de 1980. Não se engane pensando que obter um front-end funcionando conversando com algumas APIs escritas em Node rodando no nó K8 significa que você é um desenvolvedor full-stack.
Esses indivíduos são míticos não apenas devido à profundidade de conhecimento e experiência que precisam ter em diferentes domínios técnicos, mas também porque esse escopo está sempre aumentando - todos os anos há grandes desenvolvimentos em tecnologias e padrões em cada um dos domínios, mantendo-se atualizados. até hoje é muito, muito difícil.
Além disso, esses indivíduos geralmente vão pedir mais dinheiro do que a maioria das organizações de TI pode pagar, mas se eles realmente estiverem completos, valerão a pena - como diz o anúncio.
Proponho que o melhor que você pode esperar alcançar é o domínio do domínio escolhido (uma camada específica com uma pilha de tecnologia limitada dentro dessa camada) e, na melhor das hipóteses, competência e consciência de sua falta de conhecimento em outras áreas.
A melhor maneira de uma equipe ser bem-sucedida não é tentar recrutar ou treinar desenvolvedores full stack, mas sim criar domínios, por exemplo, front-end, back-end, banco de dados, etc. a pilha será limitada) com conhecimento sobreposto/cruzado em outros domínios com interfaces, padrões, melhores práticas e estruturas muito claros para dar suporte ao desenvolvimento de alta qualidade. Se os indivíduos são capazes de abranger vários domínios no nível de especialista, isso é ótimo, mas, em minha experiência, isso é realmente uma exceção.
Comentário bônus:
O que você precisa saber para ser “mais” bem-sucedido como desenvolvedor de ciência de dados (observe o uso da palavra desenvolvedor aqui, em vez do termo cientista de dados - presumo que você já seja um bom cientista de dados? E se não for, eu não posso ajudá-lo lá!). Se definirmos esse desenvolvedor como alguém que pode desenvolver em cada uma dessas áreas, mas é um especialista na parte de ciência de dados*, ou seja, meu objetivo reduzido acima, a industrialização da pilha mais ampla é algo que um engenheiro de aprendizado de máquina faria… para outro momento.
*em nossa pilha simplificada, podemos dizer que o modelo vai no bit de microsserviços… mais ou menos