O que aprender: um passeio pela história da computação
Olá!
Um problema que acomete muitas pessoas desenvolvedoras que eu conheço é um certo medo e uma ansiedade gigantesca para "se manter atualizado(a)" na área de tecnologia. Em alguns casos, gerando até síndrome do impostor ou o fatídico medo de estar perdendo algo, popularmente conhecido como FOMO (em inglês, fear of missing out).
Um dos remédios mais eficazes para ajudar a diminuir essa angústia é estudar os fundamentos da forma correta, como se aprofundar em arquitetura e estrutura de dados. Com esse conhecimento que não muda, você se torna um profissional mais preparado para lidar com as mudanças comuns da área de tech. Lembrando: o framework da moda pode até mudar, mas o paradigma interno que ele usa é o mesmo desde a década de 70. Aqui vale mencionar alguns exemplos: no momento que escrevo, algumas tecnologias que são tidas como vanguarda em tecnologia são: hotwire (que replica um paradigma de mandar HTML em requisições cliente-servidor que já existia no Java na década de 90) e gRPC (que é de 2016, mas a ideia original de RPC é da década de 80).
Dado que a última novidade não é tão novidade assim… agora você pode respirar.
Com isso dito, fica a pergunta: então, de fato o que é importante?
Confesso que esse artigo demorou para sair justamente porque eu não tinha conseguido encontrar uma forma de explicitar as mudanças da área de tech em perspectiva, de forma estruturada e que fizesse sentido.
Sinto que eu ainda não consigo, mas, para isso a gente recorre ao trabalho de outras pessoas na internet para obter inspiração.
Gostaria de recorrer a história para elencar as técnicas que resistiram ao teste do tempo e tentar argumentar a favor da minha seguinte percepção: apesar da aparência de inovadora, no que realmente importa, a área de tecnologia é bem conservadora e toda a ansiedade para atualização é uma urgência artificial, gerada a partir de observações que partem de premissas tóxicas (como a percepção que é preciso saber tudo para ser uma boa pessoa desenvolvedora) e comparações injustas de si mesmo com outras pessoas.
Meu argumento basicamente se resume a essa imagem (que encontrei por acaso no Linkedin):
Se tiver ruim de ver a imagem, abra a imagem em uma nova guia que vai dar para dar Zoom.
Vou comentar brevemente por década para facilitar o acompanhamento.
Década de 50: Algumas dessas linguagens são usadas até hoje em nichos, como COBOL para aviação, bancos e varejo e Assembly para sistemas embarcados e similares. FORTRAN ainda é usado em algumas bibliotecas de cálculo de física em alguns nichos mais científicos. Porém, se você não trabalha nessas áreas, você não precisa se preocupar com isso. O único ponto aqui que resistiu ao teste do tempo é: entender o mínimo como Assembly funciona te faz uma pessoa desenvolvedora melhor. E acho que só. Porém, há profissionais experientes que acham que a talvez não seja mais tão necessário. A dica aqui é: tem coisa mais importante que essas linguagens para você aprender primeiro.
Década de 60: Linguagens como BASIC e Simula serviram de base para algumas outras que usamos até hoje. Porém, não tem necessidade de explorar isso a fundo pensando em utilidade para o mercado atual. Porém, os conceitos popularizados nessa época são fundamentais até hoje em dia, como: orientação a objetos, modularização e separação de componentes, bibliotecas, arquitetura de software e o conceito de arquitetura microkernel, por exemplo. Todos esses conceitos são usados ativamente até hoje, portanto, entram na lista de necessários.
Década de 70: Desse período, muita coisa resistiu ao teste do tempo, como o conceito Event-Driven (indispensável para sistemas distribuídos hoje em dia), TCP/IP, Internet, SQL e Pipes and Filters (usado em todos o utilitários do Linux), Modelo Entidade-Relacionamento (Sim, o MER da faculdade), o conceito de Client/Server, Model-View-Controller e Containers. Ou seja, tudo que você precisa saber para ser Pleno em qualquer empresa hoje em dia é dessa época.
Década de 80: Sobrou pouca coisa que ainda se usa, como RPC (na forma de gRPC), a web em si (na forma de sites usando www), C++, Design by Contract, que é importante para a confecção de integrações e é a única técnica que eu já vi funcionar para evitar que um time de front-end fique dependendo de um time de back-end entregar a API para começar a desenvolvimentos das interfaces, por exemplo. Além disso, o conceito de CQRS tem suas raízes no conceito de CQS, que surgiu nessa época. Além disso, tem uma ideia intuitiva de usar o encapsulamento para isolar componentes que eu nem sabia que tinha um nome e surgiu aqui, que é o conceito de Responsibility Driven-Design.
Década de 90: Pode não parecer, mas já se passou 30 anos que boa parte das técnicas que são consideradas o padrão hoje surgiram, como: IoT, UML, HTML, SOLID, Java, Javascript, Design Patterns, o conceito de arquitetura em camadas e Python. Felizmente, algumas bizarrices não são mais tão comuns de se encontrar por aí, como Corba, SOAP e EJB (que eu aprendi na faculdade em 2012 e nunca precisei usar, ainda bem).
Década de 00: Apesar de já fazer pelo menos 10 anos, agora que estamos usando algumas técnicas como profissionais da indústria e aos poucos algumas técnicas estão se tornando exigência no mercado, como: REST, JSON, Domain Driven Design, Arquitetura Hexagonal, Devops (na forma de Continuous Integration/Delivery), CQRS e Microservices. Ou seja, é só isso que você precisa aprender de fato atualmente, porque é disso que consiste o que está sendo usado na maioria dos projetos atuais.
Década de 10: GraphQL e gRPC não se aplicam a tudo. Clean Architecture também não resolve tudo. Apesar de não estar no desenho, eu gostaria de frisar dois importantes: Docker e Kubernetes. A única coisa que eu vejo que está na vanguarda e que é obrigatório são essas técnicas. Porém, dê uma olhada nessa imagem:
Nem todas as empresas precisam desse nível de complexidade em sua arquitetura para construir software de qualidade. Se você quer trabalhar com essa arquitetura, corra atrás de aprender essas ferramentas, mas no seu tempo e sem se cobrar excessivamente por saber tudo, pelo seguinte motivo: você não precisa saber tudo! Geralmente pessoas desenvolvedoras trabalham em time e é o time que chega nas soluções, é possível contribuir em um time sem saber 100% sobre tudo.
Se você precisa muito de um caminho das pedras para ao menos direcionar os estudos, aqui você encontra um material ordenado de várias sub-especialidades da tecnologia que podem te ajudar, tem back-end, front-end, qualidade e até banco de dados! Espero que ajude a diminuir a vontade abraçar o mundo :)
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
