O caminho das pedras de um desenvolvedor Full Stack

Esses dias eu parei um pouco para refletir: qual foi o caminho que segui para estar onde estou? Quais foram as pequenas pedras que tive que recolher para começar a criar um castelo?

Photo by Cederic Vandenberghe on Unsplash

Por mais que eu sinta que ainda esteja no alicerce, um castelo sem isso, nunca será um castelo. Então se parabenize sempre pelas pequenas pedras colhidas ou removidas do caminho, e isso é, a meu ver, o primeiro passo mais tátil de qualquer caminho que seguirá em sua vida.
Irei separar algumas pedras que julgo necessárias serem colhidas:

Tenha uma boa base (Prática!):

Ter uma boa base, não significa que você precisa saber a fundo sobre tudo, seja generalista e entenda onde começa e onde termina cada camada. Eu sei que no começo pode parecer bastante confuso, mas isso vai separar o joio do trigo, e te tornará não só um profissional melhor, mas uma pessoa com um senso crítico mais preciso.

O que eu quero dizer com isso tudo? Que para ser um desenvolvedor Full Stack é necessário saber quais pilares de arquitetura uma aplicação moderna segue. Onde começa e onde termina a responsabilidade do back-end, do banco de dados, do front-end, aplicações das metologias de Experiência de Usuário (UX), testes, formas de comercializar (Deploy), etc.

Quando eu digo para ter uma boa base prática, significa que nessa etapa não adiantará se afundar em livros, pois talvez eles te deixem mais confuso. Ler artigos é um ótimo caminho a seguir, pois desperta a curiosidade em alguns termos e temas, e a curiosidade, nesse árduo caminho de recolhimento das pedras, é essencial.

Um exemplo prático: estude banco de dados, nem que seja genericamente. Aprenda um pouco sobre modelagem de dados, e construa queries, na prática. Isso te deixará um pouco mais crítico em como você modela suas entidades, e, na prática, vai te permitir dar um passo a frente para entender a próxima etapa.

ORM(Object Relational Mapper) ou Mapeamento de Objetos Relacionais:

De nada vai valer pular diretamente para a segunda etapa na parte de relacionamento de entidades se não entender como construir uma constraint, ou um índice.

Ao se deparar com dezenas de anotações (recurso utilizado pelos frameworks para demarcar entidades, relacionamentos e ações), pode não entender quais são as responsabilidades daquela camada. Existem alguns frameworks ORM, como Hibernate(Java) ou Doctrine(PHP), ambos têm suas especificidades, mas tentam atacar o mesmo objetivo: velocidade no desenvolvimento, para não precisarmos ficar construindo queries na mão.

Escolha um de sua preferência, que se aplique à sua linguagem de programação, e comece a criar aplicações, mesmo que usando o Getting Started destes frameworks, isso vai te ajudar a compreender melhor como funciona um ORM, provavelmente se não fizer isso por conta própria, o mercado te empurrará a isso.

Restful Api’s:

Anteriormente era comum vermos páginas que implementavam JSP ou PHP, fazendo renderizações do lado do servidor (*Server Side Rendering), porém com o tempo, isso foi caindo em desuso, talvez até pela vinda das SPA’s (Single Page Applications).

Então, o que costuma-se fazer hoje em dia são requisições para uma aplicação e, com o retorno, são manipuladas as páginas para uma melhor apresentação. O lado bom disso é que a sua aplicação passa a não depender mais de uma linguagem específica, e sim de um contrato, contratos são bons, independente se estiverem no lado do front-end ou back-end, eles deixam os processos mais definidos, e com uma quantidade menor de acontecimento de bugs.

*Não confunda Server Side Rendering com a técnica atual para SEO’s (Search Engine Optimization), para melhorar indicadores de carregamento e tempo de renderização de página. O caso descrito é quando você realmente apresenta partes do seu site de uma forma condicional, e o Server Side entrega uma página “picotada” para o Client Side.

Conceitos de back-end:

Conheça as particularidades da linguagem que escolheu, isso não significa que precisa conhecer extremamente a fundo, mas conheça o ambiente utilizado, principalmente o mais famoso. Isso significa que se você escolher Java, por exemplo, é bom conhecer conceitos básicos, melhores aplicações das estruturas de dados, e o que o mercado utiliza de bibliotecas e frameworks, como SpringBoot, Hibernate, Guava, etc.

Conhecer o que o mercado usa, facilitará encontrar soluções para os problemas que tiver, e materiais para estudar mais profundamente algumas técnicas. Construir uma aplicação simples vai te ajudar a tirar algumas dúvidas que não sabia formular muito bem, e também ter momentos de “A-haa! É assim que isso funciona!”.

Conceitos de front-end:

Muitas pessoas acham que front-end é apenas aquilo que faz muitas pessoas chorarem, chamado CSS, mas não, não é.
Um bom profissional de front-end entende, ou pelo menos tenta entender, muitas coisas relacionadas a esse ambiente: tipografias, design, cores, combinações, acessibilidade, usabilidade, frameworks, consumo de API’s, etc.

No geral, tenha uma boa base, estudando HTML semântico, nem toda empresa se importa, mas se entrar em uma dessas que se importa, e colocar uma <div> no lugar de uma <section>, irão ficar muito chateados com você. Mas isso também acostuma, pois, uma boa pessoa desenvolvedora nunca entregará nada sem antes bisbilhotar códigos já existentes da empresa.

Para ser um bom “front-ender”, estude os conceitos básicos, que vão te levar além, quando for enfrentar as dezenas de milhares de frameworks que virão. Ter bases sólidas de CSS te ajudará a estilizar e sobrescrever qualquer FrameWork que utilizar. Entender bem de HTML irá te ajudar a criar laços de construção de template nos frameworks de SPA.

Entender bem ES6 vai te entregar, além de um belo design de código, coesão no que está querendo dizer nos códigos, e também vai te ajudar a utilizar os frameworks do mercado, como Angular, Vue, React, etc. Saber bem Javascript nunca é desperdício, aprendi isso quando comecei a utilizar Cypress de uma maneira repentina.

IDES e utilização de atalhos:

Eu sei que isso é natural, e com o tempo, é inegável que vamos nos ambientar com as IDE’s que estamos utilizando, mas no começo, separe um tempo e digite no Youtube: “Melhores formas de utilizar o VSCode”, “Atalhos matadores no Eclipse” ou “Meu Android Studio queimou meu processador, como resolver”.

Despenda um tempo para aprender um pouco mais sobre as ferramentas que irá utilizar. Muita gente já utilizou alguma ferramenta de uma forma errada, ou não teve um bom aproveitamento da mesma, e já foi em algum fórum falar que tal ferramenta é ruim. Quando for falar que algo é ruim, tenha bastante propriedade disso. Muitas pessoas que falam que faca sem ponta não presta, é porque nunca precisaram dela na ausência de uma chave de fenda…

Conceitos de UX:

Trabalhamos para humanos, não para máquinas. Seu gestor é um humano que oferece produto para pessoas, se agradar seu chefe, talvez estará agradando quem paga para ele, e talvez isso também lhe traga algum retorno no futuro. No geral, a experiência do usuário vai mais além do que os nossos olhos enxergam.

Ela começa do seu posicionamento, compila por seu código, e transpila na sua entrega. De uma forma simplista: se você se preocupa em se comunicar bem, deixar tudo muito bem definido, cria testes na sua aplicação, se importa com quem vai utilizar, e entrega isso fora do papel, você já tem muitas chances de deixar o usuário feliz.

Não tem como agradar a gregos e troianos, mas entender sobre alguns conceitos da área de Experiência de Usuário, pode te trazer alguns insights de como deixar as coisas mais equitativas ao usuário, principalmente se o seu trabalho for construir API’s.

Ainda temos um pouco de falta de compreensão em achar que quando se fala de UX, estamos falando de tela. Estamos falando de “tela” quando estamos na área da UI (User interface), porém uma interface, pode ser um caderno, um quadro negro, ou elementos dispostos de forma “X” em uma superfície.

Não podemos esquecer que ao criar aplicações, estamos entrengando alguns métodos, onde os próprios desenvolvedores viram usuários do nosso código, então o tempo gasto para uma boa definição do uso, demonstra um apreço a usabilidade.

Testes:

Valorize aprender sobre testes. É uma das etapas mais difíceis. Se já entrou em desespero de “Meu deus, como vou fazer um Mock dessa Classe?”, sabe o que eu estou falando.

Entender de testes é ótimo, mas o foco principal é enfatizar a valorização dos testes. Um código sem testes não está entregue, segundo vários escritores que foram entrevistados para o livro CleanCode.

Crie testes unitários para assegurar aqueles micro-fluxos, e integrados para contemplar os comportamentos conjuntos. Testes EndToEnd, que dependem da aplicação inteira de pé, sem controlar o estado dela no código, são uma maravilha para rodar antes de um deploy e ter segurança que não quebrou nada no Sprint caótico.

No geral, um desenvolvedor que está habituado a enxergar os testes como parte da entrega, já leva em consideração o tempo e o esforço dos testes embutidos na sua tarefa. Conhecer metodologias como TDD (Test Driven Development), poderá mudar um pouco a sua visão sobre os seus fluxos de desenvolvimento.

Tenha um repositório de anotações:

Uma pessoa que eu admiro muito, tem toda a sua carreira profissional anotada no EveryNote. Qualquer coisa que eu pergunto para ele: “Will, como eu faço isso?” Se ele não sabe, ele sabe onde procurar.

Assim, com o decorrer das nossas entregas, vão ficando aquelas experiências marcadas, então se um dia eu me esquecer de como fazer algo, é bastante provável que eu vá procurar aquela classe que realizei o commit há um tempo. No geral, anotações nunca são demais, e elas podem ajudar outras pessoas, sendo inclusive o que eu estou tentando fazer aqui.

Faça networking e não foque apenas na sua área:

Não adianta ficar trancado no quarto e não conversar com ninguém. Um conhecimento não repassado, é um conhecimento perdido. Perceba que muito do que aprendemos, é adquirido em conversas, artigos, filmes, etc. Tudo passou na mão de alguma pessoa, você pode tentar evitar o mundo, mas nunca conseguirá evitar o consumo de algo produzido por um ser humano.

O Networking é bom para você ter outros conhecimentos, pois nem só de Tech vive o homem, saiba aproveitar cada área que lhe for apresentada, e transforme isso em combustível para protagonizar mudanças em sua vida. Um curso de Teatro irá te ajudar a se soltar mais em reuniões, ver filmes irá te ajudar a quebrar o gelo no Uber rachado com o colega que não conversa muito, e por aí vai.

Se o projeto está finalizado, entregue-o (Deploy):

Criar um projeto inteiro e não mostrar para o mundo é sacanagem, né? Se concluiu, coloque-o na nuvem. Não importa se é uma página simples em PHP, a parte divertida é você conseguir acessar fora do seu Localhost, e enviar para a sua mãe. No geral, muitas coisas mudaram com a vinda do Docker.

Antigamente era muito mais complicado você encontrar algumas hospedagens que suportassem TomCat, e era bem chato fazer deploy de WAR com PuttyFTP. Hoje tem Google e Amazon com um bom suporte para, efetuar a publicação de uma aplicação, e também gerenciar e aplicar a escalabilidade da mesma. Aprenda alguma dessas tecnologias, mais uma vez, se não aprender por conta, o mercado irá decidir por você, assim como decidiu por mim.

Conclusões:

Escrevi algumas dicas que eu gostaria de ter lido quando eu comecei. Compreender esses links com essas Buzzwords, e ir atrás, faz com que possamos sair do zero e ter um norte de como começar a construir uma carreira. Isso é uma forma que consegui transparecer o que os anos de estudo e programação na prática me fizeram observar o que eu poderia ter focado mais, e a conclusão é: a generalização para uma futura especialização.

Hoje eu tenho me especializado muito mais em front-end, com um pezinho em UX e o outro em gestão de pessoas, e é bastante difícil encontrar um profissional que tenha bons conhecimentos e saiba se expressar bem, então comece pelos conceitos básicos, e não se esqueça de treinar bem a sua comunicação, seja ela escrita ou falada.

Se leu até aqui, ficam os meus mais profundos e sinceros agradecimentos a você. Se consegui ajudar pelo menos uma pessoa, meu tempo já foi muito proveitoso.

Se cheguei até aqui foi porque me apoiei no ombro dos gigantes.
Isaac Newton