Como desenvolver em linguagem proprietária mudou a minha forma de desenvolver software
Fonte: https://undraw.co/illustrationsO que fazer quando o desafio da vez é aprender uma linguagem proprietária em um nicho específico e aplicá-la em um projeto real? Sem grandes fóruns, comunidades estruturadas, documentações robustas, libs ou variados exemplos de aplicações na internet. Trabalhar com essa configuração me fez repensar a minha forma de desenvolver software, aprender linguagens de programação, encontrar soluções e usar diferentes práticas desassociadas à tecnologias específicas.
DesafioQuase 2 anos atrás, vivenciei uma experiência imersiva na ThoughtWorks University, uma potente formação tanto de valores mas principalmente de excelência técnica. Ao retornar ao meu escritório de origem, ainda exalando ágil e boas práticas pelo poros, estava animada e ansiosa pelo meu primeiro desafio no qual pudesse colocar em prática esses aprendizados.
Idealizei diversas configurações de projetos, focada em tech stacks nas quais eu pudesse me desenvolver e adquirir profundidade técnica. Foi quando recebi a notícia de que havia um projeto muito adequado para as minhas habilidades, um projeto de linguagem proprietária (BrightScript) e ainda mais, para um nicho específico (Streaming), que é executada em um device específico (Roku) — ainda sem emulador.
Minha primeira reação foi tentar entender quais eram os desafios, as motivações de me alocarem nesse projeto, como eu podia contribuir e por quê era visto como adequado para as minhas habilidades. O que descobri é que o projeto estava começando, precisava de pessoas com rápido aprendizado para que houvesse transferência de conhecimento e que eu pudesse aplicar as boas práticas que aprendi no TWU.
Diante deste cenário, surgem duas perguntas:
Como aplicar novos conhecimentos numa linguagem que nunca vi na vida, com uma comunidade pequena e suporte limitado?Como me manter motivada a aprender e demandar tempo em uma linguagem na qual provavelmente não irei usar novamente?Para responder estes questionamentos, eu precisei fazer outro e respondê-lo primeiro: O que eu posso aprender com esse desafio?
OportunidadesA realidade do projeto me dava muitas oportunidades de aprendizado. Era um projeto recém iniciado, com um time pequeno, composto por pessoas abertas à discussão de novas práticas, com diferentes trajetórias e com um ponto em comum: desvendar os mistérios de BrightScript.
Além do primeiro passo que era aprender a sintaxe e as peculiaridades da linguagem, existiam algumas necessidades inerentes à construção do projeto: testes unitários, automatização de builds, criação de pipelines de integração e entrega contínua, preocupação com qualidade. Todos esses pontos eram portas abertas para novos conhecimentos que agregam muito à minha carreira, o diferencial era que eu não só precisava aprender como aplicar essas práticas, era necessário adequá-las às limitações da linguagem.
Foi um processo diferente das minhas experiências com linguagens populares no mercado. Por exemplo, se eu estivesse diante de um desafio no qual preciso escrever testes unitários em Java mas não sei como fazer isto: o meio mais simples seria fazer uma busca na internet e receber logo nos primeiros links a sugestão de um framework para criação de testes, o JUnit. Em uma linguagem proprietária, dependendo da sua popularidade e do quão grande e engajada é a sua comunidade, existe um fator que interfere nessa facilidade: o preço do pioneirismo. Nos víamos criando soluções nas quais não tínhamos referências externas para nos ajudar, trechos de código para comparar ou falhas e obstáculos já superados por outras pessoas desenvolvedoras que nos indicassem um caminho possível.
Um episódio que ilustra bem esse cenário é quando começamos a escrever testes unitários. Descobrimos que existe um framework de testes bem simples para BrightScript, com algumas opções de asserts e annotations baseadas no JUnit 5. Não sabíamos como criar mocks, stubs e nem como de fato testar as nossas classes e métodos. Foi depois de muita tentativa e erro e principalmente revisitando conceitos fundamentais de testes que chegamos em soluções que se adequam à nossa realidade:
Como testar uma classe X?
Entendemos que o arquivo de teste precisaria herdar da classe a ser testada para conseguir ter visibilidade dos métodos e realizar os asserts necessários.
Como criar mocks e stubs?
Criando uma classe que de fato imita a classe original, sobrescrevendo os métodos com os retornos esperados para validar estados ou contendo mecanismos para testar o comportamento esperado resultante das interações com a classe em questão.
Esse foi um exemplo dos vários cenários que vivenciei ao longo desse tempo de projeto e que me renderam vários aprendizados.
AprendizadosRealizar esse processo de ver um problema, pensar em uma solução, me aprofundar e entender os conceitos que estão por trás dessa solução para enfim trazer para a realidade do projeto me fez aprender com mais profundidade e mudou a minha forma de pensar o meu processo desenvolvimento de software.
Listei algumas das principais mudanças que essa experiência com linguagem proprietária trouxe para a minha forma de desenvolver software:
Valorizar os fundamentos de programação
Ao longo da minha carreira muitas vezes me peguei preocupada em saber X linguagem ou como usar tal framework e ao me deparar com uma linguagem desconhecida, com uma comunidade pequena, com limitações mais específicas precisei utilizar muito mais os fundamentos de programação para tomar decisões técnicas e criar soluções. Precisei pegar os conceitos que eu sabia, aprender outros, realizar experimentos e tangibilizar o conhecimento para este cenário específico, criando e dando forma onde não tinha nada pronto.
Percebi que conforme eu ia adquirindo essa base mais sólida, o aprendizado de novas linguagens se tornou mais fluido, dado que a base se mantinha, os meus esforços estavam concentrados em aprender a sintaxe, entender os paradigmas e peculiaridades da linguagem. Ao longo do projeto, utilizando destes benefícios, comecei a aprender Python para automatizar tarefas do dia-a-dia através de scripts e gradativamente esse conhecimento foi se expandindo para outros paradigmas.
Entender o funcionamento por trás das bibliotecas e frameworks
As libs e frameworks proporcionam às pessoas desenvolvedoras uma facilidade na construção das suas soluções, mas entender o que essa estrutura faz internamente também se mostrou um passo importante no meu processo de escolha de um framework e também como construo soluções em cenários em que eu não tenho como utilizá-lo.
Resgatando o exemplo da escrita de testes em Java, um framework comumente usado para criar mocks é o mockito mas o que o ele de fato faz? Quero utilizá-lo para que fim? Foi respondendo essas perguntas que chegamos ao ponto de criar uma solução que supriu a falta desse recurso.
Em pesquisas recentes, retornei para um link que tinha visto rapidamente no início do projeto, mas na época não tinha expertise técnica suficiente para prosseguir na investigação: Uma biblioteca de Mocks e Stubs para BrightScript chamada rMock. Esta lib faz uso do mesmo framework de testes unitários para Roku que incorporamos ao projeto e se mostra uma boa oportunidade para realizar uma prova de conceitos e usufruir das suas facilidades, apostando na melhoria contínua da nossa base de código.
Não me prender à linguagens mas entender o valor de saber pelo menos uma com profundidade
Atualmente estou lendo o livro “Fundamentals of Software Architecture” — Mark Richards, Neal Ford — recomendo bastante. Na parte introdutória, os autores mostram uma pirâmide chamada, Knowledge Pyramid (pirâmide do conhecimento) que ilustra muito bem os conceitos de Amplitude (o quanto eu sei) X Profundidade (o que eu sei). Este artigo de Neal Ford traz mais detalhes sobre esta temática. Em resumo, as duas imagens a seguir trazem uma pirâmide onde no topo encontram-se as coisas que sabemos e que precisam ser mantidas, no meio as coisas que sabemos que existem mas não temos conhecimento sobre elas e por fim na base, está o que de fato desconhecemos.
Todo conhecimento
Expertise deve ser mantidaA entrada nesse projeto foi viabilizada pela minha postura flexível com relação à linguagem de programação. Java foi a minha primeira linguagem na qual trabalhei por bastante tempo e naquele momento eu estava totalmente aberta a outros desafios e motivada a contribuir em qualquer base de código que me aparecesse. Esta postura contribuiu para expandir as minhas fronteiras de conhecimento mas foi a minha profundidade técnica em Java e posteriormente em Python que me fizeram reaproveitar conceitos e soluções e trazê-las para BrightScript. Outro ponto é que para manter a minha expertise nas tecnologias que eu já sabia, eu precisava me manter atualizada e investir tempo nisso, mesmo que por conta própria, dado que novas coisas são criadas o tempo todo.
Utilizar boas práticas de programação, principalmente em cenários “não propícios”
Algo que contribuiu para tornar mais agradável o desenvolvimento em BrightScript, em específico, foi o uso de boas práticas. Neste artigo detalho bem estas práticas que trouxeram paz para o nosso dia-a-dia mesmo que criar esse hábito tenha sido árduo no início. Ao mencionar cenários não propícios me refiro à situações que podem desencorajar ou requerer maior esforço para tornar essas práticas habituais. Não ter ferramentas para realizar testes, uma base de código bagunçada, processos de desenvolvimento engessados, por exemplo, podem representar obstáculos mas são em cenários como estes que o uso de boas práticas podem gerar grandes mudanças.
ConclusãoComo aplicar novos conhecimentos numa linguagem que nunca vi na vida, com uma comunidade pequena e suporte limitado?
A minha resposta é enxergar a criação de soluções para além de tecnologias específicas. Valorizando os fundamentos de programação, entendendo o funcionamento por trás dos frameworks e libs, investindo em profundidade técnica e convertendo os conceitos e práticas aprendidos em aplicações possíveis dentro das limitações da linguagem.
Como me manter motivada a aprender e demandar tempo em uma linguagem na qual provavelmente não irei usar novamente?
Estar em um projeto de linguagem proprietária requereu de mim rapidez no aprendizado, curiosidade, autonomia mas principalmente automotivação. Estar aberta a esta possibilidade e entender o que eu podia extrair, me moveu a revisitar rotineiramente as minhas motivações e pensar se o aprendizado adquirido vale o esforço realizado e principalmente, se conversa com as minhas aspirações. Isso me fez aprender novas coisas, mudar a minha forma de desenvolver software e ter atenção com a minha carreira.
ReferênciasKnowledge Breadth versus Depth
Fundamentals of Software Architecture
BrightScript Language Reference
