As opiniões expressas aqui são exclusivamente do autor. Se você discordar, deixe um comentário e deixe-nos saber sua opinião — respeitosamente, é claro. Suspeito que muita gente...

Esta é a primeira de uma série contínua de desenvolvedores expressando suas opiniões sobre vários tópicos no mundo da engenharia de software e ciência da computação. As opiniões expressas aqui são exclusivamente do autor. Se você discordar, deixe um comentário e deixe-nos saber sua opinião — respeitosamente, é claro.

Suspeito que muitas pessoas interpretarão este artigo como "gatekeeping". Embora eu possa entender essa perspectiva, eu me esforcei para fornecer uma visão honesta que reflete minha experiência ao longo dos últimos anos (principalmente startups). Também quero negar explicitamente que me concentrarei em fullstack em um contexto de desenvolvimento web. Eu apoio totalmente a noção de um engenheiro fullstack que nunca escreveu uma linha de HTML ou CSS, eles simplesmente não são o foco deste artigo. Sem mais delongas:

Se há uma coisa que ninguém no ecossistema de desenvolvedores pode concordar, é o que constitui um engenheiro fullstack. Ao longo do último ano de me ensinar webdev, encontrei muitos mitos e aprendi muitas coisas sobre o desenvolvimento de fullstack.

O que é um Fullstack?

Vamos começar com uma definição genérica, definitivamente não controversa de um engenheiro fullstack:

"Individualmente responsável pela engenharia das características de ponta a ponta de um sistema. Desde a experiência inicial do usuário até o backend code executado em servidores distribuídos."

Se você tem críticas sobre essa definição, bom. Isso porque a engenharia fullstack não é uma coisa real. Não há nenhum modelo científico que descreva o que é fullstack. Não há como medir se uma pessoa é mais um engenheiro fullstack do que outra pessoa. O único consenso em relação ao fullstack é que ninguém concorda o que é. Isto também deve deixar claro que qualquer outra coisa que você leu neste artigo é inerentemente opinião.

Por que Fullstack é tão romantizado?

Mesmo que não haja consenso sobre o que é um fullstack, todos parecem concordar que é algo que eles querem. Em sua defesa, a noção de fullstack é muito sedutora, e não tem nada a ver com programação. Fullstack é emocionante porque aborda um dos problemas mais inevitáveis ao construir coisas complexas:

"Não importa o quão bem você possa construir peças separadamente para algo, a sobrecarga da integração é quase sempre não-zero."

Integração pode significar muitas coisas, mas no mínimo inclui a comunicação exigida pelos componentes para se encaixarem. Em teoria, um engenheiro fullstack reduz a sobrecarga de integração para quase 0, pois eles controlam os componentes separados e, portanto, só precisam se comunicar consigo mesmos. Embora a comunicação não seja o único aspecto da integração, na minha experiência, a comunicação tende a ser o gargalo. Com essa compreensão da engenharia fullstack, uma única pessoa pode potencialmente ser mais produtiva do que duas, três ou até mesmo quatro pessoas (assumindo que a sobrecarga de integração não é desprezível). Especialmente do ponto de vista empresarial, o potencial de pagar uma pessoa um pouco mais para fazer um trabalho que anteriormente levava quatro é cativante.

Opinião Popular

Eu queria criar um modelo simples para um engenheiro fullstack baseado na opinião popular (mais média). Depois de ler sobre muitas opiniões diferentes online, cheguei à seguinte definição generalizada de um engenheiro fullstack. Um engenheiro fullstack é qualquer engenheiro capaz de executar todo o processo de construção de uma experiência web completa. Criei um modelo abaixo, que formaliza minha interpretação da opinião popular:

Um engenheiro fullstack viável mínimo (MVFE):

Usa controle de versão

Conhece HTML

Conhece O CSS

Tem uma forte compreensão dos fundamentos da programação

É confortável com o desenvolvimento de frontend JavaScript (outras línguas são uma vantagem, js é inegociável)

Entende sistemas distribuídos

Conhece pelo menos uma língua primária backend (provavelmente NodeJS, PHP ou Java)

É qualificado com pelo menos um datastore/banco de dados

Essa definição imediatamente levanta algumas questões como:

Isso inclui testes?

Isso inclui design?

Isso inclui operações?

No início, pode parecer que essas habilidades não são necessárias para a vida diária como um engenheiro fullstack. Mas lembre-se, o valor do fullstack vem da redução esperada na sobrecarga de integração. Embora as operações não sejam as mesmas que o desenvolvimento, há uma área de superfície compartilhada onde os dois são obrigados a estar cientes um do outro. Um engenheiro fullstack pode ser capaz de passar sem entender a infraestrutura e a arquitetura em nuvem ao nível da equipe devops, mas se eles não podem falar uma linguagem comum, seu valor potencial começa a diminuir. Se ainda não está claro, essa noção vai muito além das operações. Inclui qualquer aspecto do sistema (ou processo do produto) pelo qual o engenheiro fullstack é responsável e que precisa ser integrado.

Onde a opinião popular fica aquém

É minha experiência que o MVFE acima é bastante incomum. O perfil descreve uma pessoa com habilidades que exigem milhares de horas para dominar, mas que não participa do processo holístico de tomada de decisão. Por natureza, o valor de um engenheiro fullstack decorre de sua capacidade de tomar decisões unilaterais competentes (decisões sem pedir permissão a ninguém). Tenho certeza que há pessoas que se encaixam principalmente no MVFE, mas aposto que eles são poucos e distantes entre si. Você provavelmente poderia resumir minha visão sobre o MVFE como:

É muito impraticável se tornar um engenheiro completo sem entender o quadro geral.

Na minha opinião, o valor de um engenheiro fullstack é principalmente derivado de sua capacidade de projetar sozinho, arquitetar, executar e operar todo um sistema de ponta a ponta. Supondo que isso seja possível, elimina quase completamente a sobrecarga de integração.

A Realidade da Engenharia Fullstack

Em muitos aspectos, a engenharia fullstack fica mais difícil a cada dia que passa. Por natureza, um engenheiro fullstack tem que ficar versado em uma lista de lavanderia de tecnologias independentes, mas altamente interrelacionadas. Essas tecnologias (CSS, HTML e JavaScript, por exemplo) são desenvolvidas em semi-isolamento, resultando em conceitos redundantes e terminologia que você é obrigado a aprender. Outro fator que contribui para a complexidade do fullstack, é a adoção generalizada de sistemas de gestão de pacotes de terceiros, como o NPM. Antes de plataformas como npm existirem, as melhores práticas e padrões evoluíram mais lentamente, o que significa que era muito mais fácil acompanhar. Agora parece que uma nova estrutura "melhor" é lançada todos os dias, e embora os benefícios da troca sejam geralmente mínimos, a comunidade tende a ser polarizada e julgador sobre aqueles que não usam o mais recente e maior. os pacotes npm também tiveram o efeito de tornar suas dependências muito menos unificadas. No passado, as coisas podem não ter sido tão atualizadas e modernas, mas as interfaces eram muitas vezes muito mais uniformes. Hoje em dia, você acaba precisando de dez pacotes em vez de um, e todos eles usam sua própria sintaxe e terminologia específica de domínio.

Só para ficar claro, o NPM permitiu que o ecossistema webdev florescesse e crescesse de uma maneira que poucas tecnologias têm. Isso não significa que devemos ser ignorantes ao seu custo, e há um custo.

Um perfil prático de um engenheiro fullstack

Agora que estamos na mesma página sobre os objetivos e implicações da engenharia fullstack, é hora de propor um perfil para um engenheiro fullstack mais realista. O objetivo deste modelo é abordar as preocupações que tive com o perfil "Opinião Popular", especificamente no que diz respeito à área de potencial integração.

Engenheiro Fullstack realisticamente Viável (RVFE):

Todas as coisas listadas no perfil "Mínimo Viável (MVFE)".

Justificativa: Todos os itens listados no MVFE são requisitos básicos para a construção de um aplicativo web moderno. Pode ser possível construir sites se você está carente de habilidades no MVFE, mas definitivamente não aplicações web.

Entende as necessidades dos negócios e dos clientes.

Justificativa: Em uma equipe tradicional, entender as necessidades e, posteriormente, traduzi-los em entregas geralmente recai sobre a organização do produto. Embora seja possível construir algo que você não entende pessoalmente o valor, isso afeta diretamente sua capacidade de fazer chamadas de julgamento rápidos e decisões sobre essa coisa. Por outro lado, se você está construindo algo com o qual você realmente se identifica, ou pelo menos entende, você estará equipado para tomar decisões empáticas e pragmáticas. No meu modelo fullstack, cada lugar onde você tem que se integrar externamente reduz sua eficácia. Se você não entende as necessidades do cliente e o valor do negócio, você precisará estar se integrando o tempo todo.

Entende o papel do marketing e como ele coexiste com a engenharia.

Justificativa: Existem alguns aspectos deste item específico. Eu não estou alegando que você precisa ser um guru de marketing para fazer fullstack, apenas que você precisa entender como a engenharia e o marketing coexistem. Especificamente, você deve entender a importância e o papel da análise e estar familiarizado com o processo de integração de serviços como o Google Analytics na frente do seu site. Há inúmeros lugares onde marketing e engenharia são obrigados a jogar bonito Aqui estão apenas alguns:

Implementação e relatórios sobre testes A/B e Canário

Integrando conceitos de funil de vendas como conversões, impressões, chamada à ação (CTA), etc. no produto

Entender como o design, o layout e a capacidade de resposta impactam os conceitos acima

Tem forte gestão de projetos e tempo.

Justificativa: Se já não estava claro, a autossuficiência é um aspecto fundamental da engenharia fullstack. Embora o benefício potencial da autossuficiência seja enorme, ele também vem com algumas realidades infelizes. Uma dessas realidades é que quanto mais você é responsável, mais difícil será para os outros gerenciarem seu tempo para você. Este soa especialmente verdadeiro para mim, como eu conheço algumas pessoas que seriam realmente brilhantes engenheiros fullstack. Mas como eles não têm a autodisciplina e as habilidades de gerenciamento de tempo, provavelmente não é algo que daria certo para eles.

A gestão de projetos é crucial porque é uma das formas mais claras e concisas de se comunicar com sua equipe. Isso o torna responsável e dá aos seus gerentes, parceiros e outras partes interessadas visibilidade sobre seu progresso. Por último, mas obviamente, não menos importante, força você a planejar e estruturar seu trabalho. Mesmo que você não siga uma metodologia de desenvolvimento, você ainda deve estar planejando tudo com antecedência.

Tem uma compreensão sólida do design (pelo menos o suficiente para trabalhar com designers)

Racionalidade: O design é tão essencial para o processo completo que eu quase poderia argumentar que engenheiros fullstack deveriam pelo menos ser designers medíocres. No mínimo, um engenheiro fullstack deve estar confortável com práticas modernas de design e ferramentas. Quanto menos você souber sobre design como um desenvolvedor fullstack, melhor você deve estar em traduzir requisitos/especificações de design para o resultado exato especificado. É por isso que eu realmente acho que é mais fácil apenas aprender design como um desenvolvedor fullstack, pois lhe dá muito mais margem de manobra durante o desenvolvimento para fazer compromissos. Lembre-se, você não precisa ser um artista para aprender design. Mesmo apenas entender o básico da tipografia, teoria das cores e espaçamento será um longo caminho.

Pode projetar, arquitetar e implementar sistemas de software de ponta a ponta.

Racionalidade: Se há algum aspecto de fullstack que as pessoas podem concordar, é que os engenheiros fullstack escrevem software. Eu diria que todo desenvolvedor (fullstack ou não) deve se esforçar para entender a lógica que eles estão implementando e não apenas passando pelas moções.

Além disso, muitos engenheiros fullstack lutarão com a visibilidade. Se você adotar um processo de arquitetura adequado, tornará muito mais fácil para os outros ver suas intenções sem ler o código fonte. É ligado diretamente à gestão de tempo/projeto, pois o arquiteto adequado também é um planejamento explícito.

Está familiarizado com as melhores práticas do CSS, adições modernas e bibliotecas.

Justificativa: Isso anda de mãos dadas com o requisito de design. No mínimo, você deve estar confortável o suficiente com css para traduzir deterministicamente qualquer mockup de design prático em uma representação escalável e funcional. Quanto mais familiar você estiver com css, mais fácil sua vida será.

Na maioria das vezes, aprender CSS é apenas memorizar um monte de palavras-chave. Existem alguns conceitos, como flexbox e grade, que você deve se familiarizar incrivelmente. Basicamente qualquer site (um responsivo nisso) no mundo pode ser construído com flex ou grade. Eu também recomendo estar confortável com bootstrap e bibliotecas de design de materiais. Eles podem muitas vezes aumentar a velocidade de desenvolvimento, e muitos empregadores lhe dão pontos por conhecê-los.

Conhece pelo menos uma estrutura de aplicativo de uma página (SPA) (e se apenas uma, ela tem que ser React)

Justificativa: "Comentaristas neste post":

E o homem do JS? Frameworks são apenas uma conspiração do "Big JavaScript" para controlar tudo.

Eu também, gostaria de poder viver em uma comuna onde cultivamos toda a nossa própria comida e fornecemos nossos próprios recursos. Infelizmente, moro na Área da Baía e o aluguel é caro. Embora as comunas possam estar bem jogando fora estruturas, se você planeja/precisa trabalhar em uma empresa fazendo frontend/fullstack ou qualquer coisa no meio, você provavelmente estará usando React. Mesmo que você não esteja usando React, a pessoa entrevistando você sabe React e isso é mais do que suficiente para conseguir o emprego.

Há, obviamente, uma tonelada de problemas com o atual ecossistema JS, especialmente em torno de estruturas e dependências. Dito isso, não vou cortar meu nariz para irritar meu rosto. Problemas com o ecossistema à parte, eu nem quero voltar a escrever HTML de baunilha (pela mesma razão que eu não quero escrever aplicativos web em ASM). Além disso, eu adoraria ouvir alguém explicar por que o templating do lado do servidor é melhor do que um SPA? Além do desempenho (porque é quase um não-problema em 2019 com dispositivos modernos), eu sinto que as pessoas gostam de templating do lado do servidor porque é o que eles estão acostumados. Como alguém que veio a este espaço recentemente, a rota spa é muito mais amigável.

Familiarizado com conceitos frontend específicos do domínio (HTTP, CORS, etc.)

Racionalidade: Isso é verdade para engenheiros fullstack e frontend. Eu acho que você poderia teoricamente escrever frontends que nunca se comunicam com um servidor, mas isso seria uma vida muito chata. Além de solicitação/respostas, há um monte de outros cruft específicos de domínio que você deve saber. É honestamente bobagem que as implementações modernas não tenham abstraído essa bobagem, na maioria das vezes você não precisa tocá-la.

Tem fortes habilidades SQL e NoSQL.

Justificativa: Depois de construir um número razoável de aplicativos fullstack, você certamente encontrará situações em que um único modelo de armazenamento de dados simplesmente não é suficiente. Embora eu tenha ficado completamente impressionado ao ver o quanto alguns engenheiros vão abusar dos bancos de dados noSQL para evitar usar uma alternativa relacional. Em quase todos esses casos, acabou sendo mais trabalho para os engenheiros e muito mais complexo do que a alternativa relacional. Há muitas opiniões dogmáticas sobre SQL vs. NoSQL, e a realidade honesta é que ambos são importantes e têm seu lugar. Não deixe que não compreenda ficar no caminho de tomar a decisão certa para suas circunstâncias.

Confortável com devops.

Racionalidade: Com a maioria dos aplicativos modernos, onde e como o aplicativo é executado pode ter um enorme impacto na maneira como o aplicativo é arquitetado. Encontrei-me com alguns engenheiros que acreditavam que deveriam ser completamente desconectados das operações. Embora esta seja uma fantasia agradável, na realidade, engenharia e operações estão inerentemente entrelaçadas. Mais do que isso, não ser capaz de fazer a ponte entre os dois ou limita o que você pode potencialmente construir ou faz o que você constrói uma bagunça em potencial.

Dependendo do tipo de aplicação fullstack que está sendo construída, saber que as operações podem ser tão simples quanto entender as implicações que a execução no Firebase tem em seu código. Por exemplo, no Firebase você pode usar firebase.config() em vez de process.env. Eu classificaria esse nível de compreensão como "ops aware", o que basicamente significa que você pode não ser capaz de fazer as operações sozinho, mas você entende as implicações das escolhas que são feitas. No mínimo, um dev fullstack deve ser operações conscientes. Embora, eu diria que é muito difícil ser um engenheiro confiável fullstack e não ser pelo menos em um nível de devops júnior. Seria muito difícil arquitetar corretamente um aplicativo distribuído se você não sabe quais são as políticas de escala para o servidor em que ele estará sendo executado.

Experiência com testes em todos os níveis (unidade, integração, ponta a ponta, UI, estresse, A/B, Azul-Green, Canário)

Justificativa: Se um engenheiro fullstack é esperado para possuir o software de aplicativo, ou eles precisam estar envolvidos nos testes, ou não haverá testes. Mesmo que você tenha a equipe de testes mais incrível viva, não há como eles testarem rapidamente e efetivamente uma aplicação que ninguém explica para eles. Por essa razão, os engenheiros fullstack devem pelo menos estar confortáveis explicando o comportamento do sistema em um contexto relevante para a equipe de testes. Praticamente falando, se o engenheiro fullstack não está pelo menos escrevendo os testes da unidade, você provavelmente já perdeu muito valor do engenheiro fullstack de qualquer maneira. Se eles não estão escrevendo, significa que outros engenheiros tiveram que gastar tempo para entender o código e, em seguida, escrever testes (reduzindo assim o valor do engenheiro fullstack) ou não houve nenhum teste. Obviamente ambas as opções são ruins.

Conclusão

No final do dia, cada pessoa terá uma definição ligeiramente diferente de engenharia fullstack. Mesmo que pudéssemos fazer o mundo inteiro concordar, haveria um novo termo tão ambíguo no dia seguinte. O perfil proposto acima é um produto das minhas experiências pessoais e do que aprendi com os outros. Eu adoraria ouvir críticas sobre aspectos que as pessoas discordam para que eu possa continuar a melhorar meu entendimento.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.