Minhas reflexões sobre Dev, até agora

Olá! Esse texto é algo que eu queria escrever acerca das minhas percepções sobre essa década que passou e que nos trouxe excelentes aprendizados. Gostaria de compartilhar com vocês alguns desses e coisas que eu considero relevantes para um profissional bem sucedido na área de TI. Separarei por tópicos para tornar a leitura mais fluida.

(Créditos da foto por Lorenzo Herrera em Unsplash)

Seja humilde

No universos de desenvolvimento/operações/infraestrutura existe uma série de tecnologias e técnicas das quais o usuário não conhecerá. Esse exercício de assumir que não sabe e que tem uma postura boa para aprender é excelente para se criar o hábito de evitar ser/agir como um rockstar.

Apesar de ser algo bem batido entre a sociedade de Dev, o exercício de assumir essa postura é algo bastante relevante e requer uma menção honrosa sempre que possível. Lembre-se: não se sabe tudo. Quem acha que sabe, realmente não sabe de nada. (Trocadilho besta. Perdão)

Entenda sua forma de aprender

Parece meio ridículo e metalinguístico, mas entender a forma como se aprende coisas é algo bastante meticuloso. O cérebro humano é uma máquina de padrões com um alto poder de se desconcentrar. É ridículo a forma como o cérebro se perde em seu contexto. Sabendo-se disso se faz necessário estar constantemente motivado e focado. Essa díade foco/motivação acredito que seja a chave para qualquer aprendizado.

Há pessoas que se viram bem fazendo tutoriais na internet. Há aqueles que trabalham com o StackOverflow (eu incluso), aqueles que contam com ajuda de tutores e aqueles que são seus próprios tutores. É necessário verificar a forma como você se mantém mais produtivo. Apesar de pessoas com ensino tutoriado terem condições de entrarem no mercado de trabalho (uma formação normal, com passo-a-passo e aquele rito de disciplinas), brilham as pessoas que adotam uma abordagem mais sistêmica do processo; costumo brincar que essas são orientadas à soluções.

Uma coisa por vez

Estou fazendo a leitura de um livro sobre cultura DevOps chamado “The DevOps Handbook — How to Create World-Class Agility, Reliability, and Security in Technology Organizations— por Gene Kim, Jez Humble, Patrick Debois, John Willis (https://www.amazon.com.br/dp/B01M9ASFQ3/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1) e o mesmo fala, bastante sobre a forma como devemos construir software recentemente, de maneira ágil e escalável.

Aparenta ser feio o que eu vou dizer, mas “faz”. Não importa se mal-feito, mal otimizado. Entregue. Claro… Há ressalvas. Mas em suma os sistemas, a depender de sua criticidade, suportam bem códigos não otimizados. Pessoas com alguns problemas de humildade, e ou que se sentem forçadas a serem melhores e mais performáticos, tendem a paralizar em situações onde a entrega é iminente. Isso dá margem para as síndromes do impostor e CIA.

Entenda “mal-feito” um programa não otimizado. Entenda “mal-feito” como algo que funciona sem ser uma bomba relógio, algo que possui lógica, mesmo que esta não seja a melhor alternativa. Que esteja bem escrita (a qual a sintaxe esteja legível); que esteja versionada. Um arquivo de versão e um changelog são mandatórios. Um código que pode evoluir (vulgo não ser descartado em sua totalidade).

Teste seu projeto

Já sabemos a importância dos testes Unitários e de integração. Queria deixar essa menção honrosa aqui para esse tipo de atividade por conta de que é um assunto divisor de opiniões; aquela coisa de que “todo mundo sabe que é o certo a se fazer, mas que ninguém faz”. Eis alguns pensamentos sobre isso:

Testar código é uma tarefa difícil: principalmente quando se cria aplicações à moda “caralha” (ouvi esse termo, inicialmente por meio de um amigo do trabalho: abraço, Lucas!): um código monolítico, com funções de múltiplas competências, fora de padrões de projeto usuais. Para estes casos é necessário pensar em uma aplicação como um dispositivo da vida real: componentes em que você possa testá-los individualmente, não uma invenção cheia de fios soldados, como um grande bolo amorfo de funcionalidades. Acho que eu consegui explicar o ponto. =P

Até mesmo código que é de difícil teste, como o estado de uma máquina (apesar de que este é bem mais fácil, por meio do test kitchen, do serverspec e CIA), ou um código de um programa para microcontrolador, por exemplo (neste caso não existe hardware suficiente pra rodar uma rotina de teste. Na real, precisaria ser construído um outro hardware pra testá-lo [mas se o hardware de teste falhar, caro Watchmen?]).

Certa vez vendo umas palestras sobre TDD (Test Driven Development) o cara falava, de maneira agressiva, que era um divisor entre amadores e profissionais quem sabia desenvolver orientado à testes. Acredito que é bom ter humildade para aceitar aquilo como uma provocação e correr atrás de aprender.

Caso não tenha o feito ainda, recomendo ler o “Código Limpo” e estudar se a tecnologia que você usa recentemente suporta testes. Se sim, pegue um exemplo e comece a fazer. Não se importe se seu código ficar cheio de prolixidades. Inicie.

GIT é essencial

Não sabe o que é isso? Favor, páre o que você está fazendo e vá estudá-lo. Até este ponto, todos nós sabemos da importância de versionamento de código. A ferramenta passou a ter uma ressignificação ao longo do tempo, passando a não só guardar código, mas código de qualidade (por meio de processos de integração contínua) até definições de infraestrutura no seu meio micro (por meio da gestão de configuração, dentro de máquinas) e do macro por meio de gestão de infraestrutura em si, como o terraform, como principais exemplos.

(Recomendo, caso tenha ficado curioso sobre automação de infraestrutura, conferir um video de introdução do Terraform provido pelo Linux Tips: https://www.youtube.com/watch?v=lrAycU7_XnQ)

Inglês e a importância da documentação oficial

Uma vez estava conversando com um amigo filósofo, em um desses eventos de prática de conversação em inglês em Curitiba/PR, falávamos sobre a importância do pensamento e de que como conseguíamos nos expressar à respeito estava intríssecamente ligado à linguagem. Tá… Onde quero chegar? A linguagem é como uma estrutura onde você pode transportar idéias. Traduzí-las para um outro idioma é feito uma pintura de uma pintura: você consegue ver a imagem, mas a definição perdida pode guardar ideias interessantes do pensamento do autor, além de ser algo trabalhoso e, tecnicamente, lento. Ele me falou que se você quisesse entender o pensamento de Nietzsche, por exemplo, que você o penssasse em alemão.

Onde quero chegar? Infelizmente o nosso ferramental é íntimamente dependente da lingua inglesa. Todos os dias desenvolvedores de todo o mundo criam e fazem manutenção de bibliotecas de modo a impactar o máximo de pessoas possíveis. Com isso eles acabam usando o idioma padrão entre o meio que é o Inglês.

O treino do inglês é algo feito sob demanda e de maneira constante. Existem toneladas de conteúdos disponíveis por aí. Sintam-se à vontade para buscar.

A documentação oficial, como o nome sugere, é uma forma como os desenvolvedores pensaram em “ensinar” como utilizar suas ferramentas. Manter-se ligado ao que os desenvolvedores querem dizer no tempo que eles estão produzindo os conteúdos, é excelente. Isso o prepara para um próximo ponto, que é se manter atualizado com o mercado de desenvolvimento.

Mantenha-se atualizado! 1 mês? Defasado!

Uma das coisas que eu já escutei, ao longo da década, foi que ser Desenvolvedor era uma tarefa bem difícil, dado a grande quantidade de assuntos que ele deveria estudar para se manter “atraente” para o mercado. (Com exceção dos tiozões do Cobol. Brincadeira)

Com novas tecnologias, novos desafios surgem e novos problemas também. Esse eterno prelúdio de estudar/desenvolver/implementar forma o profissional. Você pode ter um “carro-chefe”, como ser bom em Python, mas antes de mais nada, você é um resolvedor de problemas. Ferramenta certa para o momento certo (humildade sempre. rs)

Mudamos a forma como pensamos sobre aplicações. Cada vez mais pessoas migram de PCs para celulares como sua fonte principal de conteúdo (não é uma informação nova). O que é novo é que empresas e startups querem aumentar sua agressividade por meio de um deployment contínuo, agregando valor rápido ao usuário final, sem maiores sacrifícios. Aqui entra o teste mencionado acima. Precisamos aplicar pipelines de Integração e Entrega contínuas para que isso seja possível e você receba aquela versão do teu software enquanto dorme, por meio de atualizações automáticas do seu device).

Isso é tão latente que a menina dos olhos do mercado da vez é o “SRE”, ou formalmente usado pelas recrutadoras como “Engenheiro DevOPS” (https://landing.google.com/sre/). Com mais e mais pessoas trabalhando de maneira descentralizada e com times menores e mais enxutos, um grupo de pessoas precisa entender o todo, coordenar o todo e entregar isso para o usuário final. Foi-se o tempo de instalar as coisas em VPS e ter controle total sobre as máquinas, hã? Mas quem está apto a pagar uma fortuna com Heroku?

Containers são o futuro; esqueça o Docker!

Ah, containers! Uma excelente ferramenta divisora de águas no cenário de tecnologia. Não é perfeita, está sofrendo várias transformações, mas sem dúvidas é algo que está transformando a forma como vemos e produzimos aplicações.

Por meio de containers todas as aplicações se tornam agnósticas, reproduzíveis em qualquer plataforma, estáveis o bastante para rodar em locais como um Debian Server ou um CentOS, e serem portáveis.

Este tópico renderá um post à parte, mas vou logo adiantando: Docker implementa tecnologias de containers, mas não é o único! Mindblowing?

Caso sim, vem comigo!

Com a adoção do recente Fedora 31, o mesmo perdeu o suporte, por padrão, da engine do Docker, devido a adoção do novo CGroups. Isso me fez abrir a mente para novos motores de conteinerização, que não demandam de um daemon ou de rodar containers como root (problema antigo). Podman e Buildah caíram na mesa como uma boa alternativa para ser estudada. Em breve aguarde material sobre eles.

Faça amigos: eventos de tecnologia!

Pessoas que trabalham com T.I. têm seu tempo bem alocado ao estudo e desenvolvimento de soluções. Não é via de regra, mas boa parte destes mantém vidas solitárias de estudo e implementação (meu caso). Isso é preocupante quando se precisa estar atento as novidades, ao mercado e suas demandas.

Boa parte dos eventos possui caráter introdutório, logo use-as para entender o que estão falando sobre. Entre uma palestra e outra, procure cumprimentar o apresentador e faça perguntas. Não esqueça de que, quanto mais simples possa parecer a sua, mais interessante possa vir a ser para o público.

Isto abrirá novas portas para projetos, parcerias, emprego: quem sabe? =)

Por meio desses eventos que eu descobri uma brilhante iniciativa o qual eu faço parte, chamada CodeForCuritiba. (https://www.codeforcuritiba.org/)

Só fazendo um pequeno jabá, é um grupo de cientistas de dados, desenvolvedores, jornalistas que querem aprender algo novo e mudar a forma com a gestão pública é feita, melhorando e tornando-a cada vez mais transparente.

Projetos Opensource: ganha-ganha entre dev e comunidade

Trabalhar/enganjar-se em um projeto opensource é algo estimulante. É um canal para se fazer novos amigos e por em prática aquela tecnologia que estava sendo estudada, mas que não sabia como iria implementar por não ser necessária na atual conjuntura.

Um ambiente opensource é um local para se utilizar as melhores práticas, além do que várias empresas incentivam seu uso, como Travis, o próprio Github, Google cloud entre tantos outros.

Se você é dono de empresa e gostaria de ser bem visto na comunidade, possui ferramentas que não são a sua atividade fim e gostaria de ter o desenvolvimento acelerado pela comunidade, por quê não abrir suas ferramentas?

Assimile o 12 factor app no seu dia-a-dia

Com o crescimento de projetos cada vez mais dinâmicos e robustos, surgiu a necessidade de se padronizar a forma como estes são desenvolvidos, focando no escalonamento horizontal. Sabe-se que projetos crescem em tamanho. Se, bem sucedidos, escalam em demanda e esta precisa ser projetada de maneira sustentável.

Mas como como assim, sustentável? Um projeto bem elaborado precisa ser pensado de modo a dosar os esforços entre projeto e escopo, de modo a garantir uma evolução, sem abrir mão da economia de recursos. Explico: suponha que você monte um sistema que tenha o foco em velocidade. Você pode optar por desenvolver o projeto inteiro dentro de um banco de dados por meio de stored procedures. Isto lhe garantiria desempenho, mas lhe custaria bastante no que se diz respeito a evolução e escalabilidade do projeto, pois forçaria a se manter um banco de dados parrudo, com altíssima disponibilidade e processos de evolução maçantes, pesados e com alto risco de outtage.

Como uma possível solução se imagina criar serviços cada vez menores, de escopo mais reduzido, mas com alto rendimento. Onde entra a ideia dos microsserviços: isto não é novidade.

A novidade é como se pensar em microsserviços cada vez mais agnósticos de infraestrutura e com uma alta adaptabilidade para suportar tecnologias cada vez mais otimizadas: de container stateless à serviços “Serveless”, como Amazon Lambda.

Para isso se faz necessário “pensar” em uma arquitetura que seja Cloud Native. A 12Factor App é um excelente ponto de partida de modo a orientar sua aplicação para operar em modo de aplicação como serviço: https://12factor.net/pt_br/ (Também posso fazer uma discussão à respeito em uma postagem futura)

Conheça o GNU/Linux à fundo: sempre dá tempo

Apesar do ecossistema Microsoft estar tendo dias gloriosos com suas ferramentas, APIs e cada vez mais facilidades para desenvolvedores, é no GNU/Linux que os usuários encontram seu ambiente final para desenvolvimento de projetos de fundo de quintal à mainframes.

Segundo o site HostingTribunal (https://hostingtribunal.com/blog/linux-statistics/#gref, acesso em 5 jan 2020), o GNU/Linux, em 2019, era o sistema operacional que:

• Rodava em 100% dos supercomputadores do mundo;
• Possuía 23, dos 25 melhores sites do mundo rodando a plataforma do pinguim;
• rodava em certa de 96,3% dos servidores de todo o mundo;
• rodava em 90% de todas as infraestruturas de nuvem do mundo; praticamente todos os melhores hosts o usam.

Praticamente em todas as empresas que eu trabalhei, os processos seletivos sempre recaem sobre conhecimentos específicos nesse sistema operacional. A bola da vez é tentar sair da zona de conforto e buscar usá-lo no dia-a-dia. Servidores são bons e estáveis, mas é no uso diário, como máquina Desktop, que você se tornará fluente. A cada troubleshooting, a cada nova tecnologia, o seu horizonte acabará se expandindo.

Lembro-me bem ao utilizar servidores Debian antigos com rc.d até ingressar nos novos com system.d, facilitando o processo de desenvolvimento (apenas para ilustrar um exemplo). Ao se tornar íntimo dessas tecnologias o desenvolvedor passará a sempre se manter atualizado, entendendo os movimentos que a comunidade GNU/Linux faz e se sentindo cada vez mais confiante a usar, e, quem sabe, propor melhorias.

Apesar de eu ser bastante parcial, recomendo a distro Fedora (https://getfedora.org/pt_BR/). Para os mais aventureiros, recomendo instalar a versão “Silver Blue”, onde o sistema é todo imutável. (Mais um novo possível post)

Concluindo

O mercado está mudando de maneira cada vez mais acelerada. Entender o padrão e entrar no ritmo das engrenagens fará com que o profissional sempre se mantenha atraente para ele, possuindo ganhos cada vez mais expressivos. Como uma bom argumento, que rende um outro post à parte, está a possibilidade de um trabalho a nível global: mudar de país, sonhar alto, viver experiências novas.

Eu posso ter sido muito incisivo em meus raciocínios, dado minhas percepções e visão limitada. Certamente não terei abrangido outras realidades. Caso você tenha se enquadrado nisso, por favor, deixe-nos saber aí nos comentários desse post! Ficarei muito feliz em poder melhorar e criar um conteúdo com mais acurácia.

Nos vemos em breve!