Olá, meu nome é Pavel e estou com pilha cheia no Mad Devs * aplausos *.No contexto de um grande número de artigos e materiais sobre o fato de que
as pilhas completas não são necessárias ,
as pilhas completas não existem ,
as pilhas completas são ruins , há uma opinião sobre
as vantagens de uma pilha completa em relação a especialistas especializados e por que
as pilhas completas são necessárias .
Eu queria deixar uma lista de links para outros artigos sobre pilhas completas no início do artigo, mas havia muitos deles, então me desculpe. Eu só quero dizer que há material suficiente sobre por que uma pilha cheia é boa e por que uma pilha cheia é ruim. E cada um deles é pelo menos 50% verdadeiro.
Provavelmente existem emoções e pensamentos pessoais que não afirmam ser o último recurso.
Como eu já disse, meu nome é Pavel, em breve fará sete anos desde que recebo dinheiro para programação. E durante todo esse período me chamei no currículo, em entrevistas e em outros lugares:
desenvolvedor de back -
end com conhecimentos e habilidades em Frontend e DevOps . De uma forma ou de outra, em uma carreira profissional, ele costumava trabalhar como back-end em projetos, mas nunca tinha medo da frente ou das operações. Portanto, ele orgulhosamente adicionou essas duas áreas à sua descrição. É verdade que, com o advento do Mad Devs, e tendo trabalhado em um dos projetos com nossa equipe do MadOps, removi o DevOps da minha descrição, porque agora acredito que não o entendo. Tudo em comparação é conhecido, como você sabe. Espero trabalhar um dia com os mesmos especialistas em front-end que me "convencerão" a remover o pós-script do front-end. O principal é não encontrar um back-end, o que forçará você a remover o back-end do currículo, caso contrário não restará nada.
Os argumentos mais freqüentes de especialistas que escrevem e acreditam que uma pilha cheia é ruim soam assim:
Sem imersão em nenhuma das áreas ,
você não pode ser um desenvolvedor sênior do Fullstack , especialistas
estreitos de alta classe ganham mais do que fortes pilhas completas , etc. E você sabe, eu concordo com eles.
Nos últimos meses, tenho trabalhado no projeto Peklo Tool, que usa Ruby no back-end, VueJS na frente e Go para implementar um gerador de texto.
E sinto os problemas:
- Eu sinto que esse código no Go pode ser melhor escrito e funcionará mais rápido ou usará menos recursos do sistema;
- Eu sinto que minha configuração do webpack pode ser configurada muito melhor, há muito lixo nela agora;
- Eu sinto que esse layout pode ser feito usando recursos modernos de CSS, SCSS ou usando PostCSS ou outras extensões;
- Eu sinto que o código nos trilhos pode ser otimizado para que menos consultas no banco de dados sejam feitas, por exemplo;
- Eu sinto que os índices precisam ser configurados humanamente no banco de dados;
- Eu sinto que esse Dockerfile precisa ser reescrito para que haja menos (ou mais) camadas;
- e assim por diante ...
Eu posso sentir tudo. Além disso, eu realmente quero fazer tudo. E, quando aparece um minuto livre, resolvo parcialmente pelo menos um desses problemas.
Você me pergunta:
por que você não usa imediatamente a coisa N neste local para que não ocorra esse problema?E responderei:
não conheço a coisa N, tão boa que posso aplicá-la rapidamente em um projeto em um determinado caso. Aproveito o tempo do desenvolvimento - leia o problema:
não há imersão completa .
E não vou mentir, porque o projeto em que estou trabalhando precisa de recursos. O PekloTool é uma ferramenta profissional para gerar campanhas publicitárias contextuais. A ferramenta é jovem, o desenvolvimento está em andamento há pouco mais de um ano, mas entrou em produção completa apenas alguns meses atrás. Como resultado, agora estamos fazendo todos os recursos úteis para esse produto.
Como sei que os recursos são necessários e que serão úteis? Muito simples
porque estou com pilha cheia . Eu vejo o projeto inteiro. Vejo os objetivos do projeto, vejo como ele funciona, vejo seus batentes, não apenas os técnicos sobre os quais escrevi acima, mas os batentes que os usuários verão.
E aqui chegamos ao ponto principal deste artigo: acredito que uma pilha completa moderna não deve ser apenas um codificador que pode executar backends, front-ends ou qualquer outra coisa. Fullstack é alguém envolvido no desenvolvimento de um projeto. Além das competências de back-end, front-end etc. A pilha completa deve ter um entendimento da área de assunto do projeto, conhecimento de UX / UI e até um pouco de marketing. O Fulstack deve saber como o projeto cumpre sua principal tarefa: ganhar dinheiro ou salvar o mundo. A pilha completa deve estar em um curto espaço de tempo com o "cliente" do projeto. Qualquer projeto tem um "cliente", se uma empresa de terceirização, é um cliente, em uma empresa de produto é uma parte interessada ou produto. O "cliente" deve ver na pilha completa o especialista com quem você pode consultar todas as questões relacionadas ao projeto.
No manual do recém-chegado Mad Devs (o mesmo documento que você deve ler no primeiro dia da empresa), há um item chamado: "Afinidade com o cliente" (por exemplo, "proximidade do cliente"). Descrevi a essência do termo no parágrafo anterior. Uma pilha cheia sempre deve colocar o chapéu do cliente; a opção ideal é quando o "cliente" realiza tarefas de sprint junto com uma pilha cheia. Ou seja, uma pilha completa entende o histórico da aparência de cada tarefa e não apenas resolve as tarefas que foram dadas. Acredito que se uma pessoa simplesmente executa tarefas e seu trabalho termina aí, mesmo que ele faça back-end, front-end, telefone celular etc., isso não é uma pilha completa. Este é apenas um back-end que pode executar front-end ou vice-versa.
Então, escrevo tudo isso, e o leitor pode ter dois pensamentos:
- que bobagem . Aqui cada um na sua. Se você pensa assim, provavelmente é um especialista restrito, então sua opinião é clara. Mas, se você estiver com pilha cheia, eu vou "fazer você feliz". Você perde uma enorme camada de atividades úteis que beneficiarão seu projeto e também a oportunidade de adquirir competências importantes que podem determinar o desenvolvimento de sua carreira;
- É assim que uma pilha completa deve aparecer no proprietário de um produto? Sim, você está certo. Com exceção de alguns pontos: o vendedor de produtos geralmente é o líder da equipe de todo o projeto. Não atribuirei qualidades de liderança a uma pilha completa. Isso é sobre outra coisa. Bem, o fornecedor do produto deve ser capaz de considerar o custo do desenvolvimento de um projeto; não é necessário ter uma pilha completa para pensar nas finanças relacionadas ao desenvolvimento. De sua posição, já existe dinheiro para o desenvolvimento. Obviamente, ele pode oferecer opções para reduzir o custo de desenvolvimento, mas apenas em termos percentuais ou qualitativos, e não quantitativos. Talvez alguns momentos estejam faltando para que o produto possa, mas posso, estou com a pilha cheia.
Há um outro lado da moeda que eu quero descrever. Isso é
triste O problema com as pilhas cheias é que elas estão sobrecarregadas. Isto é óbvio. Como regra, realizamos tarefas muito volumosas, recursos complexos. Ainda temos comunicação com o cliente para apresentar os recursos e tarefas que escrevi acima. Além disso, quando você vê todo o projeto de um ponto de vista técnico, geralmente trabalha com infraestrutura, arquitetura e outras coisas. Quanto mais informações, mais idéias e mais idéias, maior a chance de elas se tornarem realidade. Como resultado, você costuma pensar: talvez um banco de dados NoSQL, ou talvez GraphQL, ou talvez algo mais. É aqui que o emprego aparece por si só. Não estou falando do fato de que corro imediatamente para transferir tudo para o GraphQL condicional, mas às vezes você aceita algumas idéias menores e as implementa. Em suma, muito ocupado.
Você quer o que? Gostaria de experimentar uma nova biblioteca, estudar mais a configuração do IC do Gitlab, fumar algo interessante e relativamente novo para mim na frente, por exemplo, o Logux. Mas não há tempo, você é responsável pelo projeto. Não vou dizer que essa
tristeza , apenas tristeza. Por outro lado, recebo um grande burburinho: desde quando vejo críticas positivas de usuários; quando eles escrevem alegremente sobre um recurso por causa do qual você não dormiu por alguns dias; quando o número de usuários aumenta.
Concluindo, expresso a ideia de que especialistas estreitos e amplos têm suas próprias vantagens para o projeto, carreira, ambiente e desvantagens. Na minha opinião, descreverei vantagens e desvantagens profissionais específicas em um dos seguintes materiais, a menos que isso seja recebido calorosamente.
Fico feliz por estar no full-stack, porque esse é o trabalho que gosto, que não me importo de fazer no fim de semana e que faço com prazer.