Fullstack - por que é legal ou como aproveitar o trabalho

Recentemente, sérias batalhas eclodiram em Habré nos comentários ao artigo de Fulsteki - estes são eternos MIDLs. Não siga esse caminho se não quiser sofrer

Tentarei expressar meu ponto de vista de que a pilha cheia é muito legal e por que é bom seguir esse caminho.

Talvez o texto abaixo ajude alguém a embarcar nesse caminho, e talvez vice-versa, a proteja de mentes frágeis. Em geral, bem-vindo ao gato.

** AHTUNG! Tudo o que se segue não é a verdade última e é a minha visão subjetiva (deste mundo).

Para começar, vamos definir os termos que serão discutidos abaixo como estando no mesmo campo de informações, porque o conceito de fullstack é diferente para todos (assim como a divisão em Junior / Middle / Senior e outras tabelas de classificação).

A opinião mais comum é que o fullstack é um desenvolvedor que, em uma pessoa, pode trabalhar em um projeto completamente por conta própria, de trás para a frente.

Alguns de vocês podem dizer: “Bem, na minha equipe, o meio pode”, o que (para dizer o mínimo) está incorreto na maioria dos casos. Se o desenvolvedor front-end puder consertar / adicionar algo no código de suporte, se aprofundar nas consultas ao banco de dados, isso ainda não é uma pilha completa.
Afinal, o desenvolvimento do projeto não é apenas um código de entrada e saída, mas também está construindo / configurando / suportando infraestrutura para o produto resultante. Não basta escrever código, ele ainda precisa ser feito para funcionar no objeto. E o objeto pode ser um VPS de 5 dólares com LAMP por padrão e redes em nuvem como AWS / Azure ou até sua própria infraestrutura, onde vive um hardware bastante real, desde servidores / estações de trabalho a roteadores.

Portanto, não estamos falando de "fullstack-dev", mas de "fullstack-em geral". O que pode puxar uma pessoa do projeto do estágio de negociações para o estágio de assinatura do ato de conclusão.

Não vou torcer os dedos, listando o que um especialista em fullstack deve ou não saber, porque esta é uma lista extremamente vaga. No final, alguém consegue enviar e promover "projetos de uma ferramenta", digamos em Java com NoSQL, mas hoje não falaremos sobre isso.

Então, como se tornar um desenvolvedor fullstack, você precisa se tornar um fullstack ou é melhor seguir na direção de um?

Resumidamente, repasse os pontos negativos mais na superfície.

Contras

Provavelmente o menos óbvio - aceite como um fato de que você sempre ( sempre ) será inferior a desenvolvedores altamente especializados em tudo - desde a posse das ferramentas e tecnologias mais modernas até a qualidade do código. Se você é ambicioso, sempre quer estar na vanguarda do progresso, quer dobrar os dedos e olhar para os outros como uma merda - o fullstack não é o seu caminho.

Encontrar um emprego para o fullstack é muito mais fácil do que para um desenvolvedor de uma tecnologia. Mas encontrar um emprego bem remunerado ainda é mais difícil. Paradoxo, hein? No entanto, na grande maioria dos casos, esse é o caso (a menos que, é claro, desejemos usar a pilha completa como pilha completa, e não como um “programador Java”). Onde as pessoas pagam muito desde os primeiros dias / meses de trabalho, geralmente elas não precisam de "um aparador, um ceifador e um cara" - aí você precisa de mais um equipamento bem lubrificado em um mecanismo comum que faça exatamente uma tarefa e faça bem, como o timlid disse . Obviamente, há exceções, mas não existem tantas quanto gostaríamos.

Trabalhar em um capacete implica a finitude de recursos. I.e. você não pode implementar um produto de software verdadeiramente grande. Mesmo se houver conhecimento suficiente, não haverá tempo suficiente. Você não poderá lançar um jogo matador (pequenos desenvolvimentos independentes são bons, mas não é sobre eles), o sistema operacional ou o Mega-Office-XXL. Muitas vezes, as pessoas se esgotam se tiverem empreendido um projeto muito grande sem calcular suas forças. Se você gosta de fazer jogos ou participar de grandes projetos (geralmente internacionais) ou até os extremos, receba um bom salário logo após uma universidade (2-3 anos de trabalho ativo) em qualquer área - você também não está aqui.

Você tem que estudar o tempo todo. Constantemente. Muito. Para coisas diferentes. Se você se lembra dos anos de estudo com um calafrio, as conferências e os seminários on-line não gostam de você, se você não está pronto para passar horas lendo megatons de lixo informativo, procurando partículas úteis, se você está aborrecido com as tecnologias que precisa , independentemente de seus desejos e preferências - você não precisa do caminho do fullstack. Você precisa entender (e aceitar) que algum Zen é necessário aqui. Você apenas precisa se afastar do que está acontecendo, o que não é com todos.

Nunca se esqueça de que uma pessoa é, de fato, um gado de tarefa única, mas você precisará emular constantemente os modos de multitarefa (idiomas diferentes, ambientes de desenvolvimento diferentes, abordagens diferentes, mas os conceitos de "código de gravação" e "infraestrutura de implantação" são diferentes). Acredite, no começo é muito difícil e leva a baixa velocidade e muitos erros.

E, finalmente, sempre existe o risco de ser refém da situação e parar de se desenvolver se o local de trabalho não envolver nenhuma escada na carreira. E muitos milhares de trabalhadores potencialmente excelentes estão tristemente sentados em pequenas mesas, sem fazer absolutamente o que queriam há dez anos. Sim, eles podem fazer isso no Windows Server, no * nix, talvez em Java e Python, eles suportam alguns ofícios em C #, há muito tempo o "portal corporativo" foi escrito em PHP + JS, mas não há mais tarefas, tudo é depurado no escritório, tudo funciona.
E vale a pena passar da fronteira em 35-40 anos, quando o conservadorismo incorporado às pessoas é incluído, multiplicado por esse pântano aconchegante, que finalmente leva a uma espécie de “mala sem alça”. E quebrar esse círculo vicioso se torna mais difícil a cada ano. Desconfie de tal condição, porque uma barba e um suéter crescem ainda mais rápido do que os de especialistas estreitos que escrevem a mesma coisa há 10 anos.

Talvez filmes de terror suficientes para hoje, vamos falar sobre os profissionais

Você pode fazer qualquer coisa. Bem, ou quase. De um site corporativo a um aplicativo móvel. Afinal, você não está limitado a 1-2 tecnologias. Você pode até construir seu micro-império em uma única intranet.

Se você trabalha no fullstack há muito tempo (e o mais importante - com sucesso), pode liderar com facilidade a equipe de desenvolvimento. Torne-se um arquiteto. Aqueles que estão na vanguarda de qualquer grande projeto.

Se você é introvertido e mal-humorado, adora carros e não gosta de pessoas - ganhe dinheiro em um site remoto. Liderando vários projetos de lazer, você pode ganhar um bom dinheiro sem gastar a coragem de se comunicar com a equipe.

Se você gosta de se comunicar com as pessoas, possui um idioma suspenso (ou treinado) (ou é apenas um introvertido astuto com força de vontade) - pode ganhar mais dinheiro penetrando na alma do cliente.

Deve-se entender que você nunca ficará sem trabalho. Se você é o fullstack correto, deve usar o meio de qualquer tecnologia. E mesmo na "mão intermediária sênior" (é quando o Google não assume a liderança da equipe nas ruas, mas em um projeto mais ou menos sério - é fácil).

E, finalmente, algumas dicas simples e óbvias (infelizmente, nem para todos e nem sempre). Vou me concentrar conscientemente na base de código, não na infraestrutura, para não entediar os leitores.

Dica um. Não deixe seu orgulho prevalecer sobre você . Isso é muito importante. Tome como certo que existem pessoas que fazem algo melhor que você. Aprenda com eles, se possível. A abordagem "vocês são uma merda, mas eu sou uma pilha cheia, eu posso fazer tudo" está errada na raiz e muitas vezes atinge não apenas a vaidade, mas também a carteira. Se você se ama e dinheiro - siga este conselho.

Dica dois. Uma ou duas vezes em alguns anos, seria bom trabalhar em uma equipe de especialistas restritos. Isso aprimora muito a habilidade, porque a tecnologia não fica parada, mas corre na velocidade de uma locomotiva, e especialistas estreitos tentam estar na moda. Se houver essa oportunidade - não perca, aprenda muito, encontre muitos gargalos em seus projetos antigos e não os permita em novos.

Dica três. Não procure aprender TODO o YaP. Em primeiro lugar, é simplesmente impossível e, em segundo lugar, não é necessário. Use em seus projetos tecnologias bem estudadas, aquelas nas quais você é verdadeiramente "signor". Você precisa estudar novos materiais nucleares (pelo menos para o desenvolvimento geral), mas deve aplicá-los em projetos reais somente depois que eles se tornarem realmente claros para você. Tão diretamente quanto as linguagens e como, com qual qualidade elas podem ser usadas, quais benefícios podem ser obtidos com a troca, digamos, de Java para Kotlin ou Scala. Se você não entender os benefícios, o idioma ainda não amadureceu ou (provavelmente) você mesmo. A abordagem "dê duas semanas para ler pontos e vou escrever sobre essa merda" é uma abordagem ruim.

Dica quatro. Se você observar o código do seu desenvolvimento há 1 ou 3 anos e não quiser corrigi-lo, provavelmente terá uma crise, como a de um desenvolvedor (ou um código ideal em todos os aspectos, o que não acontece). Tente a dica 2.

Dica cinco. Desde o início do caminho, desenvolva uma base de clientes. Construa sua autoridade. Você e seus desenvolvimentos devem saber. Não importa se você trabalha na empresa ou é freelancer em um site remoto. Se você não tiver dificuldades em se comunicar com as pessoas, não deixe de se comunicar com o cliente. E duplamente necessário - para se comunicar diretamente com quem precisa trabalhar com seu produto. Assim, você será muito mais capaz de pensar na arquitetura do projeto futuro.

Dica sete. Meça ferramentas e tarefas. Não atire de canhão em pardais. Não há necessidade de implantar uma infraestrutura local com blackjack e garotas com baixa responsabilidade social por um "site corporativo" de uma página, apenas porque. que você pode personalizá-lo. E você também não precisa arrastar estruturas JS de 5 MB para este site (apenas porque pode fazê-las).

Não é necessário arrastar de trás para frente o que o local é na parte de trás. Pelo contrário, não. Lembre-se, se você repentinamente tiver muletas em um projeto cujas especificações técnicas não foram alteradas 100.500 vezes durante o desenvolvimento, significa que você mal projetou a arquitetura. Se possível, corrija-o; caso contrário, considere isso nas tarefas a seguir.

Conselho do oitavo. Defina prioridades corretamente. Lembre-se de que sua tarefa é tornar o produto, em primeiro lugar, conveniente e o mais confiável possível. Mesmo se você tiver um senso de beleza hipertrofiado, a beleza deve ser trazida por último.

Ufa Talvez isso seja suficiente para começar.

Obrigado a todos pela atenção.

Ah sim, eu quase esqueci ... Vamos começar!