Significado

Antes de mais nada, é importante taxar o que é a inteligência emocional, dado que há muita confusão em relação a isso para leitores mais superficiais do tema. O termo cunhado pelo próprio autor pode receber a definição resumida abaixo:

Refere-se à capacidade de compreender, gerenciar e utilizar as emoções de maneira eficaz, tanto em relação a si mesmo quanto aos outros. Essa habilidade envolve o reconhecimento e a compreensão das próprias emoções, a capacidade de lidar com elas de maneira construtiva e a habilidade de perceber e interpretar as emoções dos outros.

O significado é amplo e a execução é extremamente desafiadora. Mais do que isso, no contexto que iremos destacar neste artigo é importante entender como tal habilidade se combina com habilidades técnicas e QI (quoeficiente de inteligência). O livro destaca muito isso, indicando que, quanto mais alto o cargo da pessoa, mais capacidades de inteligência emocional são chave para um bom desempenho.

Características principais da inteligência emocional

• Autoconsciência
• Autogestão
• Empatia
• Habilidade social

Esta divisão em principais tópicos é de suma importância, visto que ajuda a isolar pontos fortes e fracos quando se faz uma auto-análise sincera de qual seu nível atual de maturidade no tema discutido. Inclusive, essa análise sincera é um dos pontos de destaque dentro do primeiro tópico acima, a autoconsciência, que se evidencia pela capacidade de entender suas limitações e quais pontos precisam ser mais trabalhados.

Inteligência emocional aplicada à liderança

Uma das narrativas destacadas na obra de Daniel Goleman é o fato de que o grande objetivo de um líder de sucesso é obter resultados. A questão é que da total inexperiência ao liderar até a entrega de resultados significativos existe um grande dúvida de como isso pode ser alcançado. Os especialistas não raramente dão conselhos baseados na experiência e conhecimento empírico. Estes, entretanto, por vezes não atingem o objetivo de desenvolver outros líderes eficazes.

Estilos de liderança e um ponto em comum

É importante citar que estilos de liderança diferentes podem alcançar bons resultados. Os estilos identificados pela obra são:

• Visionário
• Treinador
• Afetivo
• Democrático
• Modelador
• Coercitivo

Os estilos tendem a ser auto-explicativos, mas como a intenção do artigo é trazer reflexões e incentivar a leitura dessa obra de grande valia, vou destacar um estremo: é facilmente compreensível porque, dentro todos os estilos de liderança, o coercitivo é o menos eficaz em geral.

Coercitivo: uso da opressão ou da coação em determinada situação ou comportamento.

É bem provável que apenas a definição já seja suficiente para entendermos o poder nocivo que este estilo de liderança pode ter sobre o clima da organização, entre os liderados, e por consequência, para os resultados.

Ainda mais relevante é entender que os líderes que alcançam os melhores resultados não costumam depender de apenas um estilo de liderança. O que isso indica? Que é possível combinar estilos de acordo com o cenário entre os liderados e também no ambiente corporativo como um todo. O livro ainda traz uma bela comparação com tacos de golfe dentro de uma bolsa, e que o bom jogador costuma escolher o taco certo para cada jogada.

Entretanto, uma característica se faz presente em todos os jogadores desta partida: a inteligência emocional.

Segundo o estudo publicado pelo psicólogo David McClelland, da Universidade de Harvard, executivos que careciam de inteligência emocional raramente eram classificados como excepcionais em suas avaliações de desempenho e isso impactava diretamente no rendimento de suas divisões, que frequentemente desempenhavam em média 20% abaixo da meta.

Conexão

Uma atitude latente em líderes eficientes com origem na inteligência emocional é o interesse em criar conexões com seus liderados. A interrupção de uma atividade de grande importância na sua rotina de trabalho para uma boa conversa que cria conexão com um liderado pode ser encarada como inconveniente ou enriquecedora, a segunda opção costuma ser mais importante a longo prazo.

Quando tal característica é associada ao fato de que o humor das pessoas tem impacto direto no clima organizacional é ainda mais potente. Um líder eficaz procura criar conexões de forma que as oscilações naturais de humor dos seres humanos não sejam um empecilho para uma equipe altamente produtiva. É evidente então, que é muito mais difícil compreender os momentos dos liderados quando não há conexão.

Bases de apoio

Um passo de suma importância para a ascensão de um líder é criar uma comunidade de apoiadores. Líderes emergentes e consagrados quando sinceramente empenhados em prol da evolução de todos podem ser de grande ajuda. É evidente a que não podemos evoluir nossas habilidades atreladas a inteligência emocional sem o contato direto com as pessoas. Pessoas em quem confiamos removem de um ambiente de laboratório de ideias o constrangimento e a preocupação com os riscos.

Conclusão

Saber identificar, gerenciar e utilizar a seu favor as emoções é, cada vez mais, a chave para uma liderança de sucesso! Não é nenhuma novidade que a obra usada de alicerce para as colocações deste artigo pode ser de grande ajuda no desenvolvimento de novos líderes. A reflexão crucial para líderes em ascensão e estabelecidos reside na sinceridade autêntica em relação aos seus estilos de liderança e no reconhecimento do espaço para aprimoramento.

Aqui no grupo OLX a característica da inteligência emocional é muito valorizada e observada, seja em cargos de liderança ou não. Os gestores tomam a frente em identificar pontos de melhoria correlatos e instigar a evolução. Como em todo segmento de carreira, fica ainda mais importante a evolução neste aspecto à medida que almejamos assumir mais responsabilidades, principalmente quando seu objetivo profissional inclui gerir pessoas ou exercer influência técnica sobre uma equipe ou produto. Na minha recente atuação dentro da empresa este atributo tem sido instigado sendo que até mesmo a iniciativa de consultar a obra-base deste artigo saiu de uma conversa com membros do time.

Questões desafiadoras, como identificar o estilo predominante, avaliar a maturidade em inteligência emocional e explorar maneiras de incorporar diversos estilos conforme as circunstâncias, são trampolins para o crescimento. As respostas podem ser desconfortáveis, porém, a conquista da autoconsciência se revela indispensável para a evolução.

Eu me chamo Gabriel Muniz e sou Software Engineer no Grupo OLX. Será um prazer me conectar com você em alguma rede social. Adoro falar sobre tecnologia e outras amenidades como esportes 🏈 e doguinhos 🐶.

Quer saber mais sobre nossas oportunidades? Confira nossa página de carreiras!

Inteligência emocional no caminho da liderança: qual o real impacto? was originally published in Grupo OLX Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Para introduzir esse assunto, é importante fazer uma observação: nenhuma das atuações abaixo é mais ou menos importante do que outra, são apenas formas de atuação diferentes e ambas agregam grandes profissionais a nível técnico e organizacional.

Isto posto, vamos falar um pouco sobre duas das áreas possíveis de atuação de um desenvolvedor. E aqui não estou falando sobre divisões técnicas como: backend, frontend ou mobile. Sobre esse tema até tem alguns posts relacionados no meu Instagram. Aqui vou falar sobre duas principais formas de atuação de empresas no mercado de tecnologia e apontar as diferenças que notei no decorrer dos anos.

Conhecimento de negócio

Falando sobre empresas que desenvolvem os próprios produtos e apostam em investimento para que esses produtos tenham um sucesso no mercado e gerem receita, é muito importante que o desenvolvedor conheça as necessidades do negócio onde a empresa atua. Por exemplo, saber quais são os negócios ou os projetos mais importantes pra empresa naquele momento, qual produto gera mais receita e qual o grande investimento no momento para que a empresa dê um grande salto no futuro ou se mantenha estável. Para exemplificar de forma ainda mais específica, Digamos que a empresa que você atua tem produtos no setor de logística. Sendo assim, quase que por osmose você vai adquirir conhecimento no setor de logística. Entretanto, isto não significa que este conhecimento é o suficiente para você se destacar dentro da empresa e procurar um cargo de liderança. Se esse é o seu objetivo talvez seja necessário que você vá além do óbvio e procure entender iniciativas da empresa além dos escopo do seu time.

Autonomia técnica

Com base em minha experiência, observo que ao trabalhar em uma empresa que desenvolve seus próprios produtos, há uma maior probabilidade de se ter autonomia em decisões técnicas. Em muitos casos, é possível até mesmo participar de discussões que ultrapassam o escopo da equipe, influindo em fóruns de nível organizacional.

Por outro lado, em contextos de consultoria, vivenciei situações semelhantes, onde a equipe da consultoria é responsável por desenvolver uma feature ou melhoria necessária na aplicação. Contudo, existem equipes isoladas, que podem incluir membros de consultorias, possivelmente até da equipe em questão, mas que são gerenciadas por funcionários internos da empresa. Esses membros internos tendem a se envolver mais profundamente em decisões técnicas, como arquitetura e escolha de tecnologias a serem utilizadas.

É claro que mesmo um grande estigma de uma organização pode ser quebrado e as decisões podem ficar acessíveis a mais pessoas, o que vejo porém, é que em cenários de consultoria o caminho a ser percorrido até que um desenvolvedor tenha maior influência em grande escopo em geral é mais longo.

Essas distintas dinâmicas destacam a diferença de autonomia entre ambientes de desenvolvimento interno e de consultoria, evidenciando como a participação em decisões técnicas pode variar significativamente conforme o contexto organizacional.

Gestão do tempo

Outro aspecto que, com base em minha experiência, difere consideravelmente nas consultorias é a gestão do tempo, que tende a ser menos flexível. Isso significa que você trabalhará mais ou menos horas? Evidentemente que não! Isso varia muito de cenário para cenário. O que eu quero destacar aqui é que, em consultorias, muitas vezes, o seu trabalho é vendido por hora; portanto, o controle tende a ser mais detalhado. Em um cenário de desenvolvimento de produtos, o foco principal é que o software seja entregue dentro do prazo, conforme as especificações e com os objetivos de negócios atendidos como esperado, resultando na receita estimada sendo alcançada. Portanto, é possível que a gestão de horas trabalhadas seja mais flexível.

Isso absolutamente não é uma regra, já atuei em uma empresa de produtos onde era necessário fazer o apontamento de horas em dois softwares diferentes e ambos precisavam ser mantidos rigorosamente iguais.

Conclusão

As duas vertentes de trabalho são de extrema importância para o mercado de tecnologia e tem em seus meandros algumas diferenças bem interessantes que podem casar com o perfil profissional e objetivos de alguém mais do que com outro. A ideia de apontar as diferenças tem dois objetivos:

• Contar a minha experiência e estimular outros a falar das suas, visto que devem existir cenários que vão completamente na contramão do que eu vivi até hoje;
• Dar uma prévia para desenvolvedores que tiveram experiência apenas em um dos lados da moeda, talvez dando insights legais para o seu futuro.

Com o intuito de manter o artigo curto e não tedioso listei apenas 3 aspectos, porém tenho alguns outros em mente, então é provável que haja parte 2. Alertas e correções são sempre bem-vindos. Suas experiências mais ainda, obrigado por ler.

No cenário de desenvolvimento de software, o mundo mobile é uma jornada desafiadora que atrai cada vez mais desenvolvedores a cada dia que passa. Com a crescente ubiquidade dos dispositivos móveis, criar aplicativos para plataformas como Android e iOS tornou-se uma habilidade altamente valorizada e um campo fértil para inovação tecnológica.

O foco desse artigo é falar com quem já tem experiência no desenvolvimento de software em alguma outra ponta dos sistemas, seja frontend web ou backend. Portanto, se você está iniciando na área e já pretende engrenar no mobile talvez alguns tópicos não fiquem claros para você.

Nos anos que atuo no desenvolvimento de software já atuei durante um bom tempo como dev Android e também backend (as vezes nas duas frentes paralelamente). Neste período percebi que há algumas diferenças tecnológicas e de processo muito comuns que talvez um desenvolvedor que esteja pensando em estudar alguma tecnologia mobile não saiba e que são de suma importância. Sem mais delongas, vamos a elas:

1. Publicação em produção

É o primeiro item aqui justamente porque vejo que é a questão mais recorrente que custa a ser entendida nas integrações entre times mobile e outros que são especializados em backend ou outras coisas.

De modo muito superficial o fluxo de publicação em produção de um software moderno é algo como:

• Escreve código -> publica em ambiente de testes -> realiza testes e correções -> publica software em produção -> Finish

Já no caso da publicação de apps móveis seria mais ou menos isso para um app que seja coordenado para lançamentos faseados (prática bem comum).

• Escreve código -> lança versão para testes -> realiza testes e correções -> publica versão em produção para uma parte da bases de usuários -> aguarda aprovação da loja de aplicativos -> verifica se não houve algum novo crash ou problema crítico -> aumenta a porcentagem de usuários que receberão a nova versão -> segue acompanhando -> publica para toda a base de usuários -> Finish

Além desses passos a mais também depende em geral de que os usuários permitam que a nova versão seja instalada no seu device, ou é necessário que o update seja forçado para que todos recebem, ainda assim depende de configurações dos dispositivos. Isso implica em pensar muito bem os lançamentos e repensar muito funcionalidades com informações fixas, porque uma mudança de url pode significar uma nova versão e esse fluxo todo se iniciando por descuido.

2. Preocupação do diferentes dispositivos

Indiferentemente de plataforma, seu aplicativo móvel vai ser executado em dispositivos com diferentes tamanhos de tela, versões do Sistema Operacional e com diferentes configurações de hardware. Evidentemente que nesse caso se você for para o lado do Android isso é ainda mais abrangente.

Quando trabalha com backend os clientes acessam seus recursos através de alguma forma de exposição dos seus serviços, seja cloud ou on premise. Uma consequência disso é que fica na sua mão ou do seu time/empresa o controle do ambiente onde o código é executado. Já no desenvolvimento mobile isso não é uma verdade, fazendo com que você precise pensar mais em:

• Compatibilidade de bibliotecas com as versões do S.O;
• Configurações remotas do aplicativo (ex: remote config ou feature flags no próprio backend);
• Compatibilidade das suas interfaces com o usuário com diferentes tamanhos e resoluções de tela.

É evidente que para todos esses pontos existem ferramentas e bibliotecas que ajudam o desenvolvedor, a questão é que algumas preocupações vem acompanhando a nova ponta do software na qual você atua.

Esses são apenas dois pontos que vejo nos anos trabalhando com olho nos dois espectros. Existem muitos mais, comenta aqui quais você percebe e me segue no instagram.

Esta é a parte dois de um artigo que já escrevi há algum tempo. Decidi escrever uma continuação porque recentemente mudei de empresa e de equipe. Nesta nova equipe eu fui muito bem recebido e decidi anotar alguns pontos que achei muito interessantes da parte deles. Muitos desses pontos podem ser naturais ou pensados, mas fizeram muita diferença no meu onboarding.

Fale do passado

Para quem está começando em um novo time, principalmente quando se trata de um negócio com o qual a pessoa ainda não teve contato, é muito importante saber o que aconteceu no passado da equipe ou do produto no qual se está trabalhando. A ideia não é que você conte todo o histórico dos últimos anos ou décadas (em caso de empresas ou produtos mais antigos). Porém, é importante avaliar quanto de contexto é necessário para que a nova pessoa possa começar a desenvolver o seu trabalho de uma forma consciente. Normalmente na área técnica, grandes decisões ou mudanças de estratégia da empresa vem acompanhadas de impacto no código, na arquitetura ou na organização dos times. Explicar por que certas coisas funcionam de certa maneira pode ser muito útil.

Importante: não se prenda a cada mínimo detalhe, procure deixar o novo integrante do time a vontade o suficiente para que, se você esquecer de algo, ele mesmo questione.

Mantenha um ambiente leve

É normal passar por momentos de pressão no trabalho e começar em um novo time pode causar grande apreensão. É por isso que um bom ambiente dentro do time pode ser muito importante para quem está chegando. Normalmente, isso faz com que a pessoa se sinta mais à vontade para dar suas opiniões, tirar dúvidas e com certeza a torna mais engajada e produtiva.

Faça elogios

Todo novo membro de um time passa por um período de adaptação e é muito natural que neste momento a pessoa esteja mais focada em ouvir do que compartilhar, mais em obter contexto do que dar suas sugestões, mesmo que tenha uma boa bagagem. Por isso, tente observar os pontos positivos do seu novo colega de time e comente isso com ele.

Um detalhe que considero importante: mesmo em pequenas entregas iniciais que seu novo colega fizer, fale do que gostou e seja positivo, ainda que você saiba que ele tem experiência para entregar muito mais num futuro próximo.

É claro que feedbacks construtivos serão muito importantes e devem ser dados com clareza, mas notar e falar sobre pontos fortes trará um grande ganho, até mesmo na confiança do seu colega nesse novo contexto.

Peça feedbacks

Observação: eu gostaria de ter encontrado outra palavra para usar aqui, já que sabemos que a palavra feedback é uma das figurinhas carimbadas do corporativês que é motivo de piada na internet, e que eu particularmente acho bem engraçado. Mas não encontrei, então vamos lá.

Na parte um deste artigo eu falei sobre como achava bem importante que os colegas mais antigos no time fossem acessíveis. Vejo que parte disso é por deixar muito claro que você tem pontos fortes e fracos e que todos estão no mesmo barco. Não vejo forma melhor de fazer isso do que pedir que seu novo colega fale sobre o que acha da sua atuação assim que se sentir confortável para tal. Não pressione, mas comente que gostaria de saber como ele vê o seu trabalho e se existe algo que você poderia melhorar em qualquer aspecto, inclusive na ajuda a novas pessoas.

Certamente existem muitas outras coisas a se fazer quando se recebe um novo integrante na equipe, e talvez bem mais importantes do que as que comentei nestes dois artigos. Estes são apenas aspectos que me ajudaram e eu gostaria de replicar com outros.

O que mais você acha importante? Conta pra mim.

É necessário?

Toda nova tecnologia, framework ou biblioteca tem prós e contras. Você vai casar com os prós, mas está pronto para casar com os contras? Está apto a entender como mitiga-los? Por isso é de grande importância saber se é realmente necessária a aplicação de uma nova forma de resolver um problema. Pode ser que um método já conhecido, estável e fácil de implementar seja mais do que suficiente.

É confiável?

Tecnologias emergentes são realmente empolgantes! Mas é importante frisar que algumas delas não tem uma longa vida. Um exemplo que pode ilustrar isso é o do AngularJS (a Superheroic JavaScript MVW Framework, segundo seu próprio site oficial). A famosa pesquisa anual de tecnologias mantida pelo StackOverflow traz dados interessantes sobre ele. Note as imagens abaixo.

Percebeu? O Angular.js aparece em posições muito diferentes nesse intervalo de seis anos, caindo muito. Além disso, o contexto nos ajuda a perceber que boa parte dessa utilização se deve a manutenção de legados. Um índice complementar pode nos ajudar:

Note que este gráfico mostra que 78,99% dos desenvolvedores temem o framework, enquanto apenas 21,01% amam. Não é a toa que a legenda do gráfico aparece logo abaixo dele no screenshot, ele realmente é o pior avaliado na relação amor/medo. Uma possível relação de causa e efeito pode ser estabelecida pelo próprio Google te-lo descontinuado e criado uma nova ferramenta totalmente diferente, mesmo que tenha um nome semelhante (o que lembro de ter causado estranheza na época).

Em suma, talvez boa parte dos sistemas que adotaram ferrenhamente a tecnologia tem um legado desagradável para manter ou até mesmo já investiram na reescrita deles utilizando outras ferramentas. Será que uma avaliação mais criteriosa poderia ter impedido isso? É interessante refletir no assunto.

Qual o custo?

Neste ponto não destaco apenas o custo financeiro, que obviamente é um fator quando você pensa em inovar. Mas um custo que não pode ser negligenciado é o tempo para que sua equipe possa tomar posse de maior conhecimento da tecnologia adotada e entender profundamente quais as melhores abordagens e estruturas para certa tecnologia.

Se esse tempo não for investido, mesmo uma grande ideia pode virar sucata ou algo ainda pior

Qual a abordagem?

É possível que a nova tecnologia coexista de forma fácil com as ferramentas já existentes dentro da sua empresa? Caso não seja o caso, qual a complexidade de tornar isso possível? É necessário descartar um grande volume de trabalho já feito para que a nova tecnologia seja encaixada no quebra-cabeças? Isso se paga? Há justificativas técnicas para tal?

Um exemplo que pode ser de ajuda é o do desenvolvimento Android. Há algum tempo os desenvolvedores utilizavam a linguagem Java para desenvolvimento de aplicativos para o Sistema Operacional do Google. Mas em 2017 a Google anunciou o suporte ao Kotlin para as aplicações Android. Infelizmente, muitos devs (por certa má vontade ou desinformação) achavam que precisariam jogar fora aplicações inteiras ou reescrever tudo para que fosse possível aproveitar os benefícios da linguagem. Uma rápida leitura na documentação já seria suficiente para entender que as linguagens poderiam coexistir e interagir entre si de forma simples. Em 2018 foi até mesmo publicado um guia de interoperabilidade entre as linguagens na documentação do Android.

Este é um caso que em geral trouxe muito mais prós do que contras. Caso fosse diferente, uma má estratégia poderia trazer muitos problemas.

Seu time compra a ideia?

A tecnologia vai reinventar o negócio mas as relações humanas continuarão a ser a chave para o sucesso. — Stephen Covey

A frase acima, do autor de Os Sete Hábitos das Pessoas Altamente Eficazes define bem a importância desse tópico. Toda e qualquer grande decisão, inclusive técnica, vai precisar de apoio do time para que possa ser colocada em prática e ter sucesso. Seu time compra a ideia e entende que os prós são valiosos em relação aos contras? Excelente! Você vai ter apoio deles. Não é o caso? Analise os porquês. Será que não entenderam a fundo a necessidade? Será que eles estão adotando um ponto de vista mais conservador pelo histórico do sistema ou da empresa? Talvez eles apenas estão tendo uma visão mais realista que você do problema a ser resolvido. Responder a essas perguntas de forma sincera é bem importante para chegar ao melhor resultado possível.

Conclusão

Ser inovador e investir em novas ferramentas é inspirador, mas como toda decisão precisa ser tomada de forma consciente e fria. Isso é importante para não sufocar ideias excelentes e não criar um grande Frankenstein para o seu time ter que cuidar depois.

Há muito mais pontos que pessoas com ampla experiência podem trazer sobre o assunto e por isso a melhor forma de aprender é estar aberto a isso.

Fique à vontade para apontar falhas no texto ou questionar opiniões!

Seguindo com mais um recurso de Kotlin para desenvolvedores Java, o primeiro post já tem algum tempo e você pode ler aqui.

Extension Methods

Se você já mexeu em algum momento com C#, que como muitas linguagens C-Like não tem grande curva de aprendizagem, já viu isso, então vamos lá.

Os métodos de extensão são bem auto-explicativos, eles adicionam funções a classes que originalmente não as tem. Considere o cenário onde pegamos as informações de um produto de certa fonte de dados, talvez uma API, e precisamos converter de forma fácil. Aqui o método getProduct da classe ProductDataSource fará o papel de retornar esses dados sem tratamento.

Note o código abaixo, nele fazemos a conversão do response para uma entidade e formatamos o campo titleAndDescription da forma esperada.

O método de extensão toEntity nos ajuda a fazer isso usando o modelo:

modificador de acesso (opcional) + tipo a ser extendido + . + nome da função

Dessa forma a chamada para o método na linha 14 acontece como se a classe contivesse essa função em si. Note que a extensão pode receber um modificador de acesso, aqui private, tornando-a acessível apenas no contexto da classe.

Importante citar que para acessar as propriedades do objeto no qual o extension method foi chamado usamos o this, o que pode ser mais necessário quando o código do método for mais complexo. Caso não seja, como vimos no exemplo acima, pode ser omitido.

Abaixo o método de teste validando o formato dos dados:

Um ponto de atenção é que trata-se de um exemplo simples pra demonstrar a feature, com um olhar minimamente crítico dá pra ver que essa conversão não seria facilmente testável enquanto unidade já que está privada e é chamada internamente no código do método getProduct

Algo muito comum em projetos escritos em Kotlin é criar arquivos específicos para extensões de um mesmo tipo.

Em C#, por exemplo, essa funcionalidade é disponibilizada utilizando a palavra reservada this no último parâmetro do método. A forma da escrita do código é trivial, o que realmente é legal é a flexibilidade que isso pode dar, isolando pequenas tarefas e facilitando a implementação rápida de uma função numa classe pré-existente.

Se eu dei alguma canelada nesse artigo (o que é bem provável) por favor me corrija, e obrigado por ler.

Algo que vejo com muita frequência na área de tecnologia, sobre tudo entre os desenvolvedores, é que boa parte da motivação em seguir buscando especialização e se aprofundando cada vez mais na área é usar a tecnologia para resolver problemas realmente complexos. Entender coisas profundas de um sistema de larga escala e utilizar novos conceitos para resolver problemas é de fato algo muito empolgante. Tenho certeza que o olho de boa parte dos devs que está lendo brilhou quando lhe foi apresentado AQUELE projeto e a temática principal era como escalar, como desenvolver, como estabilizar e como entregar com qualidade um sistema de forma automatizada e moderna. Eu mesmo já me empolguei mesmo sabendo que é só um exemplo fictício.

E quando a conversa é outra? Talvez você mesmo já deu aquela dispersada quando o foco do seu projeto ou equipe durante algum tempo era apenas entender uma necessidade de negócio e atende-la de maneira simples, sem muito glamour. Pegar a funcionalidade e expandi-la para permitir o acréscimo de um fluxo alternativo, uma integração a mais ou só para que o usuário no fim tivesse mais detalhes ou mais conforto. A nível técnico você não foi muito exigido, a solução era óbvia. Bastava implementar e aparar arestas. Nessa posição, sua reação vai depender do que você presa mais, é claro. Aqui vou partir da premissa que seu pensamento está alinhado com o parágrafo inicial, você tem sangue no olho quando desafiado tecnicamente. Isto posto, você pode se fazer algumas perguntas cujas respostas vão te ajudar a fazer o melhor trabalho possível naquele contexto.

A base é de qualidade?

O coração de todo sistema é sua funcionalidade, suas regras, seus comportamentos. E tudo isso é código. Por isso, uma ideia é analisar se essa base de código está executando todo o necessário da melhor forma possível ou existe margem para evolução. É importante ser cauteloso nesta análise. No dia-a-dia você vai perceber pontos de melhoria, o que não significa que você poderá simplesmente começar a trabalhar nesses pontos, mas mantenha eles no radar. Saiba escolher suas batalhas e, sempre que possível, use a regra de escoteiro.

As limitações são realmente intransponíveis?

Uma ideia é analisar se as limitações técnicas do projeto ou time realmente são realmente linhas que não podem ser movidas. Talvez seja possível entender com pessoas-chave se certa iniciativa para melhorias técnicas já foram tomadas no passado, se foram descartadas por algum motivo específico ou se você pode sugerir novas coisas. Mesmo em cenários onde a necessidade de grandes tarefas técnicas parece não existir, algumas práticas podem ser adotadas para o melhor desenvolvimento do próprio time, tanto na escrita do código, revisão ou entrega.

Estou sendo megalomaníaco?

Ambientes onde fazer o básico de forma eficiente é todo o esperado podem despertar em você a necessidade de fazer coisas simples de forma mais complexa, mesmo que essa não seja a melhor escolha. Criar grandes estruturas para satisfazer sua necessidade de se desafiar pode se provar um grande erro. Por isso, talvez seja mais interessante analisar a cada acréscimo no seu sistema se esse instinto não está servindo apenas para criar um legado mais complexo que futuramente pode apenas levar a mais tempo de manutenção e menor produtividade. Um exemplo disso é utilizar muitos patterns sem saber qual o grande ganho nisso. Lembre-se: Keep It Simple Stupid!

Como andam meus planos de estudo?

É evidente que quando você precisa aprender coisas novas e aplica-las diretamente no seu ganha pão, no seu trabalho, seu desenvolvimento provavelmente será mais veloz. E isso é fantástico! Entretanto, no cenário que estamos considerando isso talvez não seja uma grande necessidade. É aí que pode ser ainda mais útil você se manter ativo em buscar novos conhecimentos e tentar aplica-los na prática, mesmo que seja em projetos pessoais, contribuindo com projetos open source ou mesmo aproveitando aquele freela que apareceu do nada.

Conclusão

Como mencionado no início, essas são algumas coisas que eu passei a fazer com o decorrer do tempo quando me via em contextos semelhantes a este. O que absolutamente não torna nada um mar de rosas, mas me ajudou a me sentir melhor. A frustração de se ver em um cenário que você não gostaria não vai desaparecer magicamente, mas pode ser melhor administrada para que você tome boas decisões e siga fazendo o melhor trabalho possível.

Kotlin Coroutines é, já há algum tempo, um tema bem comum para desenvolvedores Android. Traz uma forma mais simplificada e limpa para lidar com rotinas assíncronas.

Para dar contexto é importante lembrar que esta é uma temática de suma importância no contexto mobile, visto que não podemos travar completamente a tela do usuário e suas interações quando precisarmos executar uma rotina em segundo plano.

É evidente que o primeiro contato com um código já escrito ou a criação do seu primeiro fluxo que utilize a biblioteca vai ser com a utilização do método launch ou withContext, uma suspend function e setando algum escopo para executar a função definida. Aqui vamos definir de forma simples alguns conceitos envolvidos.

Coroutine Scopes

O escopo é um conceito que ajuda a gerenciar a execução das coroutines. Define que ciclo de vida elas devem seguir com base no seu fluxo para o aplicativo. Seguem os dois principais:

• ViewModelScope: pode ser acessado numa viewModel usando a propriedade viewModelScope e é limpa quando a viewModel for limpa;
• LifecycleScope: é cancelado por padrão quando o lifecycle é destruído;

Job

Nada mais é que um gerenciador de coroutine. Cada coroutine criada retorna uma instância de job para um escopo.

Dispatcher

Como se pode presumir pelo nome despacha o job para a linha de execução correta, sendo elas:

• Dispatchers.Main: usado para execuções rápidas que estejam atreladas a UI;
• Dispatchers.IO: feito para tarefas como escrita/leitura em disco ou operação de rede;
• Dispatchers.Default: trabalho intensivo de CPU que não permaneça muito tempo em espera (sleep)

TestDispatchers

Nome bem intuitivo de uma implementação de CoroutineDispatcher para testes. Dá a possibilidade de executar na sua suite de testes as tão honoráveis suspend functions através do método runTest. Mais ou menos como destacado abaixo.

Mais sobre os tipos de TestDispatchers você pode encontrar na documentação.

Conclusão

É claro que aqui apenas arranhamos a superfície. Além disso, você ainda vai encontrar bibliotecas como RxJava sendo utilizadas para operações assíncronas em muitos projetos. Também vai perceber que entender as bases de qualquer tecnologia ajuda muito a perceber gaps e possíveis melhorias em qualquer implementação.

Sobre RxJava li um artigo bem interessante recentemente com uma comparação simplificada, vale a leitura.

Eu gosto bastante de coroutines, acho que tem uma cara muito familiar para quem já trabalha com kotlin e mantém seu viés de simplicidade, além de ter uma documentação abrangente. Também acho interessante fugir de uma pilha grande de callbacks que outras bibliotecas costumam trazer.

Deixo o espaço aberto para opiniões e também correções (sempre acabamos deixando inconsistências e equívocos aqui e ali).

Objetivo

Esse padrão busca fornecer uma casca, ou “rascunho” para uma implementação, criando comportamentos na classe template que podem ser aplicáveis a todos os cenários e deixando outros por responsabilidade de quem a implementar.

Exemplo

Para explicar o funcionamento deste padrão podemos usar um exemplo.

Digamos que uma num sistema bancário você vai tratar um fluxo que faz pagamentos de diversas formas: pix, boleto, TED e etc.

Não é bem assim que a banda toca na vida real, mas para exemplificar, digamos que em todos esses meios de pagamento existe uma função que é exatamente igual para todos e outras que dependem muito da forma de pagamento escolhida, como criar um mecanismo legal pra isso?

Neste exemplo, vamos considerar que o método que pode ser reaproveitado entre os meios de pagamento é o de debitar o saldo de quem está pagando (DecreaseBalance), os demais vão ser com base na forma escolhida.

Pensando nisso, note o código abaixo:

Veja, no primeiro bloco de código criamos uma classe abstrata que possui dois métodos abstratos, ou seja, precisarão que uma classe concreta extenda deles e crie seu comportamento. Já o método DecreaseBalance não é abstrato e possui uma implementação padrão.

Note também que o método Execute agrupa as chamadas necessárias neste fluxo.

No segundo bloco, podemos ver a classe ExecutePixPayment herdando da classe abstrata e implementando o comportamento dos métodos TransferValue e NotifyReceiver.

No terceiro bloco podemos ver a classe Program executando o método Execute, e abaixo a sequência da execução dos métodos conforme o esperado.

Podemos dividir estes padrões em vários escopos, tais como: padrão criacional, estrutural e comportamental. Mais detalhes sobre a definição de GoF podem ser encontrados no livro Padrões de Design: Elementos de Software Orientado a Objetos Reutilizáveis (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides). Entrando primariamente nos padrões criacionais temos um padrão muito útil e que nos auxilia a tornar nosso código facilmente testável. Vamos a um rápido exemplo de aplicação do padrão builder.

Builder Pattern

O padrão builder auxilia o desenvolvedor (como o próprio nome sugere) na criação de objetos complexos step by step, ou propriedade a propriedade. Vejamos um problema claro que pode ser resolvido através do padrão:

public class User
    {
        private string PASSWORD_PATTERN = "[0-9]+";

        public Guid Id { get; }
        public string UserName { get; set; }
        public string FullName { get; set; }
        public Profile Profile { get; set; }
        public string Password { get; set; }

        public User(string userName, string fullName, string password, Profile profile)
        {
            if (IsValid(userName, fullName, password, profile))
            {
                Id = Guid.NewGuid();
                UserName = userName;
                FullName = fullName;
                Password = password.ToMd5();
                Profile = profile;
            }
        }

        private bool IsValid(string userName, string fullName, string password, Profile profile)
        {
            return ProfileNotNull(profile) && IsValidUserName(userName) && IsValidFullName(fullName) &&
                   IsValidPassword(password);
        }
    }

Perceba que o construtor chama um método de validação que passa por todas propriedades da entidade.

Como podemos testar a criação dessa entidade? Veja o exemplo de teste unitário.

public class UserTest
{
  [Fact]
  public void DeveCriarUsuarioComNomeDeUsuarioCorreto()
  {
    var user = new User("joaoSilva", "João da Silva", "1234", new Profile());
    Assert.Equal("gabrielMuniz", user.UserName);
  }
  
  [Fact]
  public void DeveCriarUsuarioComNomeCompletoCorreto()
  {
    var user = new User("joaoSilva", "João da Silva", "1234", new Profile());
    Assert.Equal("João da Silva", user.FUllName);
  }
  
  [Fact]
  public void DeveCriarUsuarioComNomeCompletoCorreto()
  {
    var user = new User("joaoSilva", "João da Silva", "1234", new Profile());
    Assert.Equal("905669063311D8A17BD6958CD353EEDD", user.Password);
  }
}

Podemos executar testes unitários em cima do construtor, porém será que eles fazem sentido?

Notou? Quando executamos um teste unitário DeveCriarUsuarioComNomeDeUsuarioCorreto, por conter uma validação dentro do construtor da entidade, a criação percorre também validações que em nada tem a ver com o nome de usuário. Ou seja, é um teste unitário que foge o princípio de testar a menor unidade possível de código, certo? Como podemos resolver esse problema através do padrão builder? Vamos refatorar a entidade para propiciar isso.

namespace PostsApp.Domain.Factories
{
    public class UserBuilder
    {
        private string PASSWORD_PATTERN = "[0-9]+";

        private User _user;

        public UserBuilder CreateUser()
        {
            _user = new User();
            return this;
        }

        public User Generate() => _user;

        public UserBuilder WithFullName(string fullName)
        {
            _user.FullName = fullName.Length <= 50
                ? fullName
                : throw new InvalidUserException("Nome completo deve ter no máximo 50 caracteres.");
            return this;
        }

        public UserBuilder WithUserName(string userName)
        {
            _user.UserName = userName.Length >= 10
                ? userName
                : throw new InvalidUserException("Usuário deve possuir ao menos 10 caracteres.");
            return this;
        }

        public UserBuilder WithPassword(string password)
        {
            _user.Password = Regex.Match(password, PASSWORD_PATTERN).Success
                ? password.ToMd5()
                : throw new InvalidUserException("Senha não atende os critérios de segurança.");
            return this;
        }

        public UserBuilder WithProfile(Profile profile)
        {
            _user.Profile = profile ?? throw new InvalidUserException("Usuário não possui perfil vinculado.");
            return this;
        }
    }
}

Melhor, não? Agora temos cada método With construindo pequenas frações da entidade, facilitando os testes de unidade e nos ajudando a validar apenas o necessário em cada teste. Vamos refatorar os testes? Segue:

namespace PostsApp.UnitTests
{
    public class UserTest
    {
        [Fact]
        public void DeveCriarUsuarioComNomeDeUsuarioCorreto()
        {
            var user = new UserBuilder()
                .CreateUser()
                .WithUserName("gabrielMuniz")
                .Generate();
            
            Assert.Equal("gabrielMuniz", user.UserName);
        }

        [Fact]
        public void DeveCriarUsuarioComNomeCompletoCorreto()
        {
            var user = new UserBuilder()
                .CreateUser()
                .WithFullName("Gabriel Silvano Muniz")
                .Generate();
            
            Assert.Equal("Gabriel Silvano Muniz", user.FullName);
        }

        [Fact]
        public void DeveCriarUsuarioComSenhaCorreta()
        {
            var user = new UserBuilder()
                .CreateUser()
                .WithPassword("1234")
                .Generate();
            
            Assert.Equal("81DC9BDB52D04DC20036DBD8313ED055", user.Password);
        }
    }
}

Veja, agora quando executamos o teste DeveCriarUsuarioComNomeDeUsuarioCorreto validamos apenas a criação do nome de usuário e assim sucessivamente.

É claro que este não é o único benefício da utilização deste padrão e ele pode/deve ser utilizado em conjunto com outros padrões que soam como música ao resolver determinados problemas. O próximo padrão de criação que vamos abordar será o factory method. Então até lá!

IMPORTANTE: Tome muito cuidado com a febre do patternite. Nem todo padrão é aplicável ou saudável para seu código em qualquer situação, é importante ter uma análise sincera do que é realmente necessário.