Entre os diferentes padrões de projeto, o Strategy permite criar uma família de algoritmos, encapsular cada um deles e torná-los intercambiáveis, permitindo que o algoritmo varie independentemente dos clientes que o utilizam e facilitando a manutenibilidade do seu código. Se você está iniciando no mundo de padrões de projeto e qualidade de código, mas ainda não sabe bem como usar o Strategy, não se preocupe. Vamos te mostrar hoje o que é o Strategy, quando usar e como aplicar, com exemplos. Você vai perceber que este padrão é mais simples do que pensa e que ele pode te ajudar bastante no seu dia a dia. Confira! O que é o Padrão Strategy? O Strategy é um padrão de projeto comportamental que define uma família de algoritmos, garantindo que o algoritmo varie independentemente dos clientes que fazem uso dele. Com ele, você pode transformar um conjunto de comportamentos em objetos e então torná-los intercambiáveis. Hoje, iremos abordar somente o Strategy. Mas, além dele, existem outros padrões de projeto em Java, como por exemplo, o Composite e o Decorator, que são abordados no livro Padrões de Projeto da GoF, a Gang of Four - ou em português, Gangue dos Quatro, caso você tenha interesse em explorar mais o assunto. Ainda de acordo com a Gangue dos Quatro, no livro Design Patterns: Elements of Reusable Object-Oriented Software, temos a seguinte definição: “Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum para torná-la útil para a criação de um projeto orientado a objetos reutilizável […]”. Como funciona o Padrão de Projeto Strategy? Vamos entender como funciona o Strategy Design Pattern: imagine que temos um e-commerce e no carrinho de compras da loja podemos aplicar algumas promoções dependendo de vários fatores. Por exemplo, é possível aplicar uma promoção de acordo com o valor mínimo de compra, a quantidade de produto, frete grátis, entre outros. Neste cenário, podemos ter muitas variações de algoritmos dentro do carrinho de compras. Porém, ao fazer tudo isso dentro da classe de carrinho sem separar o algoritmo, provavelmente haveria várias condicionais IFS para checar em quais casos aplicar cada promoção, gerando diversas alterações da classe do carrinho. É aí que o Strategy entra, pois ele soluciona esse problema separando o algoritmo. Dessa forma, dentro do carrinho de compras, teremos um campo para linkar uma estratégia de desconto que será uma família inteira de estratégias. Ou seja, podemos separar o algoritmo da regra de negócio.   Quando devo usar o padrão Strategy? O padrão Strategy é muito comum no código Java e pode ser usado em situações em que o seu código terá muitas variações de algoritmo e condições, gerando uma corrente de IFs. Vale reforçar que não são todas as cadeias de IFs que precisam ser substituídas por um Strategy, apenas se as alterações forem frequentes a longo prazo. Este padrão ajuda a facilitar a manutenibilidade do código e tornar a potencial expansão do seu código mais simples e objetiva. Isso é possível através da descentralização da responsabilidade da manipulação de um objeto abstraído por uma interface e suas diferentes “estratégias” de implementação. Como aplicar o Strategy na prática? Agora que você já entendeu melhor o conceito do padrão Strategy e quando utilizá-lo, vamos sair um pouco da parte teórica e partir para a prática. Vamos visualizar um problema e refletir sobre ele para, então, testar a implementação do design pattern em questão. Exemplo de aplicação Strategy Java: O Problema Para entender melhor como aplicar o Strategy, imagine que existe um objeto Funcionario com suas propriedades e uma classe CalculadoraSalarial que realiza o reajuste salarial deste funcionário de acordo com sua performance durante o ano. Com um ENUM que existe dentro das propriedades do objeto Funcionario, mede-se a performance do colaborador. Veja no exemplo a seguir: Agora, imagine as seguintes regras de negócio: Se o funcionário tiver uma performance NEGATIVA no momento do cálculo, ele não deve receber reajuste salarial. Se o funcionário tiver uma performance POSITIVA no momento do cálculo, seu salário deve receber um reajuste com aumento salarial de 5%. Devido a lógica por trás do negócio, o ideal é não retornar um valor de reajuste “X” por padrão. Dessa forma, podemos criar uma exceção caso no futuro exista algum novo tipo de performance que esquecemos de implementar na nossa calculadora. Implementando o método reajustaSalario (no exemplo, utilizando Java), podemos chegar a um resultado parecido com o seguinte: O código acima está funcional. Porém, uma semana após a implementação, vamos supor que o time solicitou a criação de um novo tipo de performance: EXCELENTE. Nesta nova condição, o colaborador que conquistar a performance “excelente” recebe 10% de reajuste salarial. Sendo simples e direto, o ENUM seria implementado com mais um tipo, o “EXCELENTE”. Por último, a implementação do método reajustaSalario ficaria semelhante ao exemplo abaixo: É em cenários parecidos com este que o padrão Strategy é aplicado: onde o código pode facilmente se expandir criando uma corrente de IFs. No exemplo acima, estamos “pegando leve” ─ no mundo real, encontra-se IFs encadeados em uma frequência muito mais comum, muitas vezes em situações piores do que o nosso. Tudo isso prejudica a legibilidade do código e não é uma boa prática. E como podemos implementar o Strategy nesse caso? Existem diversas formas de se resolver um problema com Strategy, a maioria delas envolve a implementação de uma interface ou de uma abstração. No nosso exemplo, as coisas são bem mais simples graças ao nosso ENUM. Provavelmente, até agora, a nossa implementação de Performance foi a seguinte: A partir de então, ao implementarmos um método abstrato dentro do nosso ENUM, todos os diferentes tipos dentro dele exigirão uma implementação, causando erro em tempo de compilação caso essa exigência não seja atendida, obrigando o desenvolvedor a implementar o método. E, assim, podemos alterar a forma que a nossa calculadora retorna o reajuste salarial do funcionário. Isso facilita imensamente a leitura do código e sua manutenção, tornando ele mais simples. Este processo deverá seguir os princípios SOLID (cinco princípios da Programação Orientada a Objetos). Aproveite para ler nosso artigo sobre um dos princípios mais importantes do SOLID: Single Responsability Principle. Depois de aplicar o Strategy, basicamente, contanto que a regra de negócio fundamental não mude, não precisamos mais sequer tocar na nossa “Calculadora”. Como temos certeza de que o método retornaReajusteSalarial possui sua devida implementação dependendo do tipo de performance, garantimos, também, que não exista o cenário descrito anteriormente, onde o desenvolvedor esqueceu de implementar o cálculo do reajuste. É importante reforçar que esta não é a única forma de implementar o padrão de projeto Strategy, mas é um ótimo jeito de exemplificar como é mais fácil de implementá-lo no nosso código do que você imagina.  Opinião do Autor sobre o Padrão de Projetos Strategy Por mais que seja diversas vezes confundido por parecer complexo, o Strategy é bem mais simples de ser implementado do que parece e poderia muito bem ser mais visto no código de vários sistemas orientados a objeto. Durante o desenvolvimento, às vezes podemos acabar criando a ideia errada de que tentar aplicar Design Patterns consome muito tempo.  Na verdade, uma vez que você conhece e domina Design Patterns, eles só têm a agregar para a velocidade e elegância da sua solução. Os padrões de projeto facilitam o desenvolvimento e tornam a manutenibilidade e evolução do código mais simples. E você, já aplicou o Strategy em algum dos seus códigos? O que achou do deste design pattern? Deixe seu comentário!

Introdução  Esse artigo visa explorar algumas técnicas para migrar o seu sistema monolítico para microsserviços baseado, principalmente, na obra de Sam Newman, o livro: Migrando sistemas monolíticos para microsserviços. Apesar de tentar consolidar os principais aprendizados extraídos do livro através dessa resenha, indico que, ao final da leitura, busquem se aprofundar no assunto através da obra original.  Entendendo melhor o contexto Primeiramente, precisamos entender os conceitos envolvidos, o que seria um sistema monolítico, suas vantagens e desvantagens, bem como o que é um sistema em microsserviços, vantagens e desvantagens. Sistemas monolíticos A palavra monólito pode ser conceituada como monumento ou obra constituído por um só bloco de pedra. Já um sistema monolítico, é aquele sistema único, este tem pelo menos três tipos: O de único processo (mais comum);O monolítico distribuído;E sistemas caixa-preta de terceiros. Sam Newman se refere àquele sistema de uma unidade de implantação, quando todas as funcionalidades de um sistema tiverem de ser implantadas em conjunto. Os sistemas monolíticos têm como vantagens: Subir rapidamente uma PoC ou MVP para validar um negócio ou produto;O ambiente de desenvolvimento fica mais simples quando a arquitetura é monolítica;Mais simples de testar, pois é possível testar a aplicação de ponta a ponta em um único lugar;Baixa comunicação entre redes;Topologia de implantação mais simples. Esse modelo também tem as suas desvantagens, como: Dificuldade de escalar;Por ser construído em um único código, se algo quebra, todo sistema pode ficar indisponível;Manutenção difícil dado o crescimento da base de código;Baixa flexibilidade sobre as linguagens de programação do projeto. Martin Fowler diz que: Aplicativos monolíticos podem ser bem-sucedidos, porém frustrantes – especialmente quando mais aplicações forem implementadas na nuvem. Ciclos de desenvolvimento são amarrados – uma mudança feita em uma pequena parte do aplicativo requer que o monolito inteiro seja republicado. Ao/]. longo do tempo ficará cada vez mais difícil manter uma estrutura modular, o que torna mais difícil fazer com que mudanças afetem apenas um módulo. Escalar requer escalar o aplicativo inteiro, não apenas as partes que requerem mais recursos. Microsserviços Sam Newman conceitua que microsserviços “são serviços que podem ser implantados de forma independente e são modelados em torno de um domínio”. A forma de comunicação entre eles também é importante, sendo através de redes. Assim, essa arquitetura de microsserviços tem como base vários microsserviços colaborando entre si. Uma das vantagens desses, os microsserviços são independentes de tecnologia, pois expõem as funcionalidades através de endpoints a serem consumidos através da rede, veja como um sistema distribuído. Outra vantagem e característica é eles terem implantações independentes. Dessa forma, você pode atualizar (alterar e implantar) um serviço sem ter que atualizar o restante do sistema, ou seja, esqueça a necessidade de orquestrar entregas múltiplas de múltiplos times para que seja tudo entregue em um pacote só. Lembrando que, para que isso seja verdade, devemos garantir um baixo acoplamento. Ao contrário de sistemas monolíticos, os microsserviços podem ser escalados independentemente. Essa vantagem pode auxiliar na distribuição adequada de recursos, redução de custos e muitos mais. Além disso tudo, como o domínio está encapsulado e externaliza suas funcionalidades por endpoints, eles podem ser reutilizados em várias aplicações. Citei algumas vantagens, mas não se limita a isso. Podemos trabalhar em paralelo nos serviços, incluir mais desenvolvedores para resolverem um problema sem que atrapalhem uns aos outros, reduzimos a complexidade cognitiva sobre o conhecimento de negócio e muito mais. É claro que vendi um sonho com várias vantagens, mas nem tudo são flores. O modelo tem seus desafios. Entre esses desafios, podemos citar a comunicação entre eles, ou seja, redes – temos que nos preocupar por exemplo com latências, falhas na entrega de pacotes. Outro desafio é a consolidação e leitura de logs para uma potencial depuração. Também tem o desafio de lidar com stacks variadas em diferentes serviços. Uma das discussões que sempre vem à tona é sobre o tamanho dos microsserviços. Este é um dos aprendizados do livro de Sam Newman – não se preocupe com o tamanho, ou número de linhas de código, mas sim com o negócio. No livro, ele foca em entender bem o domínio de negócio e por isso ele sugere a utilização de DDD (Domain-Driven Design). Não vou entrar no mérito de DDD, pois não é o foco desse artigo, mas com certeza vale muito aprofundar os estudos nesse tema. Técnicas para migração Antes de qualquer migração, é importante saber o porquê dela. O que você deseja alcançar com essa mudança, ter uma visão clara, pois essa mudança pode exigir um investimento significativo. Além disso, é normal demorar uma transição dessas, não é apenas questão da falácia do custo irrecuperável, mas as pessoas realmente esquecem o porquê de estarem fazendo o trabalho. Não menos importante, muitos dos benefícios alcançados com uma arquitetura de microsserviços podem ser alcançadas de outras formas, darei apenas um exemplo. O desejo de aumentar a autonomia das equipes é frequente, aumenta a confiança, motivação, liberdade e muitos outros benefícios. Como fazer isso? Um possível caminho é fazer com que diferentes equipes sejam responsáveis por diferentes partes do sistema. Nesse caso, um monolítico modular ajuda muito. Outra forma é identificar pessoas com maior conhecimento sobre determinadas partes do sistema e empoderá-las com a tomada de decisão sobre aquela parte. Mais uma forma de aumentar a autonomia pode ser adotando abordagens self-service para provisionamento de máquinas, ambientes, acesso a logs. Por fim, é importante saber quando não adotar microsserviços: Em domínios nebulosos;Startups;Software instalado e administrado pelos clientes;E quando não se tem um bom motivo! Mas digamos que você está convencido que o melhor caminho a ser tomado para você é realmente migrar o seu sistema monolítico para microsserviços. Vamos falar, então, de algumas técnicas. Aplicação strangler fig Essa é uma técnica muito vista na reescrita de sistemas. O padrão, inicialmente identificado por Martin Fowler, é inspirado em um tipo de figueira que germina nos galhos superiores das árvores. A árvore existente serve como um apoio para a nova figueira, que, se chegar nos estágios finais, será possível ver a árvore original morrer e apodrecer, restando somente a nova figueira. Olhando para software, a ideia é que o novo sistema tenha o suporte do sistema existente, permitindo coexistência, e que, ao momento que o novo sistema esteja pronto, possamos substituir o velho. Esse padrão é baseado em três passos: Identifique as partes do sistema atual que você deseja migrar – uma das formas de fazer isso é com uma análise de custo-benefício;Implemente a funcionalidade em seu novo microsserviço;Desvie as chamadas do sistema monolítico para o novo microsserviço. Diagrama baseado na figura 3.1 do livro de Sam Newman Chamo atenção para que, até a chamada para a nova funcionalidade seja feita, ela existirá em ambiente de produção, mas não estará tecnicamente ativa. Dessa forma, você tem tempo para desenvolver a nova funcionalidade até que esteja satisfeito com a nova implementação e gerenciamento do serviço. Uma das ideias aqui é separar o conceito de implantação de lançamento. Não quer dizer que a funcionalidade, por estar no ambiente de produção, ela realmente será usada pelos clientes. Isso te dá a liberdade de testar a nova funcionalidade em produção antes que ela seja utilizada. Outro ponto importante é que essa abordagem de migração gradual nos permite um rollback com muito mais facilidade. Composição de UI A técnica anterior estava focada numa migração no lado servidor, mas a interface de usuário também proporciona ótimas oportunidades. Imagine uma funcionalidade parte servida pelo monolito e parte servida por uma nova arquitetura de microsserviços. Uma das estratégias muito utilizadas nas migrações é a composição por páginas. Em vez de migrar tudo de uma vez, vão sendo atualizadas páginas, o que num momento de transição irá apresentar experiências distintas para os usuários quando utilizassem as partes novas do sistema ou site. Outra estratégia é fazer isso a partir da composição de widgets. No livro de Sam Newman, em um dos seus cases, a ideia foi pegar uma parte de um site, com desafios interessantes, mas que também não fosse a parte mais em evidência do sistema. A ideia era colocar algo no ar, aprender com a experiência e garantir que, se houvesse algum erro, não afetasse o core do sistema. O exemplo apresentado é de um sistema de viagens, o qual decidiram apenas pela implantação de um único widget que exibia os dez principais destinos de viagens definidos pelo novo sistema. Aqui, foi utilizada a técnica Edge-Side Includes, usando o Apache, onde um template foi definido em sua página web e um servidor web fornece o conteúdo. A composição de UI permite separar módulos distintos de UI que poderiam representar um formulário de pesquisa, um mapa, etc. A figura abaixo ilustra a ideia. Figura baseada nas figuras 3.20 3 3.21 do livro de Sam Newman Outro caminho, ao invés da composição de múltiplas páginas, foi o de aplicações single-page, tendo uma interface mais eficaz e que executa tudo num só painel. Aqui, a ideia é de uma composição de widgets. Houve tentativas de formatos comuns, uma dessas tentativas foi através da especificação de Web Componentes, mas a demora para que esse padrão ganhasse força fez com que as pessoas buscassem alternativas. Uma alternativa que tem ganho bastante força no mundo de frameworks Javascript como Vue, Angular e React é a de Micro Frontends. O termo Micro Frontend ganhou força em 2016 propondo a mesma ideia de microsservices que eram utilizados em backend, só que, dessa vez, para frontend. Os princípios que sustentam o microfrontend são: Ser agnóstico em relação a tecnologia;Cada serviço ser isolado e autocontido;Convencionar nomenclaturas para local storage, cookies e outros para evitar conflitos;Priorizar recursos nativos do browser ao invés de APIs customizadas;Construir um site resiliente e utilizável mesmo quando tiver problemas para carregar o código Javascript. Branch por abstração Anteriormente, falamos do padrão strangler fig, no qual intercepta chamadas no perímetro do sistema monolítico. Mas e se a funcionalidade que desejamos extrair estiver muito enraizada? Desejamos fazer mudanças sem causar problemas para o sistema e tão menos para os desenvolvedores que trabalham naquela base de código. Isso nos leva a querer fazer alterações rápidas com o objetivo de evitar perturbações. Normalmente, desenvolvemos código em branchs e, quando estas alterações estiverem prontas, fazemos o merge para a master. Quanto mais tempo essa branch existir, maiores serão os desafios para se fazer um merge. Então, a ideia aqui é conseguirmos desenvolver código de forma incremental, sem grandes perturbações e sem utilizar de uma branch de código de longa duração. A branch por abstração permite fazer alterações no código existente a fim de permitir que as implementações coexistam com segurança. O padrão tem 5 passos: Criar uma abstração para a funcionalidade desejada;Mudar as chamadas para que usem a nova abstração;Fazer a implementação da abstração com a funcionalidade retrabalhada, a qual chamará o novo microsserviço;Fazer a troca da abstração para que a nova implementação seja usada e,Fazer uma limpeza da abstração e remover a antiga implementação. Abaixo, tento ilustrar como seria cada uma dessas etapas. Imagine que temos um sistema fiscal que trata da NF-e (nota fiscal eletrônica), os títulos gerados, escriturações, ajustes, transferências, devoluções e por fim gerando uma apuração. O primeiro passo seria selecionar a funcionalidade a ser substituída e criar uma abstração. Um dos aprendizados de Sam Newman é tentar iniciar por funcionalidades com um baixo número de inputs e outputs. Logo, a NF-e e a Apuração seriam os últimos a serem escolhidos. Nesse exemplo, irei escolher a escrituração para iniciar a decomposição do nosso monolito em microsserviços. Passo 1: Cria abstração Passo 2: Usa abstração Passo 3:Cria outra implementação Passo 4: Faz a troca de implementação Passo 5: Faz a limpeza Conclusão Nesse artigo, falei de algumas técnicas para decompor o seu sistema monolítico, mas existem dezenas de outras formas. No próprio livro de Sam Newman ele mostra outras técnicas, como: Execução em paralelo;Colaborador decorador;Captura de dados modificados;Sem falar nas decomposições relacionadas a banco de dados, que nem foram citadas nesse artigo. Importante saber que, num projeto real, normalmente será necessário um mix de técnicas para ser bem-sucedido na decomposição de um sistema monolítico para microsserviços. Outro grande aprendizado foi de que não é preciso fazer uma migração dessas para se ter muitos dos benefícios de uma arquitetura de microsserviços, logo, tenha bem claro o motivo para fazer um trabalho desses. Lembre-se de que só é gerenciado aquilo que se mede. Então, esteja bem munido de indicadores para acompanhar o andamento do projeto e o sucesso dado os objetivos definidos. Por fim, entenda que é necessário envolver as pessoas num processo de migração desses, elas são fundamentais para o sucesso do projeto. Alinhe os objetivos, expectativas, apresente os indicadores e relembre estes de tempos em tempos.

Somos uma empresa de tecnologia criada em 1990 para desenvolver softwares de gestão para a Gestão Pública, Indústria da Construção e Justiça. O sonho que começou com uma conversa entre 3 amigos tornou-se realidade e hoje é vivenciado por quase 2.000 softplayers.   Com uma equipe robusta e cheia de vontade de inovar, garantimos mais eficiência em organizações públicas e privadas, incluindo prefeituras, grandes construtoras e o maior Tribunal de Justiça do mundo!  Nesse contexto, nossos profissionais de desenvolvimento tornaram-se especialistas em suas áreas de atuação. Porém, enfrentavam o desafio da comunicação entre as equipes. Se a equipe que desenvolve soluções para a Gestão Pública tinha problemas, era bem provável que uma pessoa de outra equipe pudesse ajudar. Mas, como elas estavam muito distantes e focadas em suas operações, a troca dificilmente acontecia.   A solução para o problema foi o “Proud Dev”, um evento criado pelos próprios desenvolvedores com o objetivo de conectar as pessoas e tornar de conhecimento geral as experiências, os problemas e as soluções de cada área.   No dia 02 de julho de 2019, os nossos devs se conheceram e fortaleceram a comunidade que faz a empresa acontecer através de palestras e debates técnicos.   O evento foi realizado com muita dedicação e desejo de continuar. O orgulho de desenvolver com propósito foi fortalecido e a expectativa para a edição de 2020 era grande, mas a pandemia causada pela COVID-19 desacelerou esse e outros planos. Nesse momento, as nossas equipes estavam 100% focadas em como garantir que os clientes continuassem trabalhando e adaptando-se ao modelo de trabalho remoto.  Mas, em 2021, vamos tirar o atraso! Com um comitê técnico totalmente dedicado em pensar trilhas, roteiros e palestras, agora o evento abre as portas também para outros profissionais de tecnologia e convidados dos softplayers. A proposta da edição deste ano é unir desenvolvimento, produto e negócios para o compartilhamento de conhecimentos, problemas e soluções do dia a dia na prática.  De forma totalmente online e gratuita, você pode fazer parte dessa história!  Para participar, fique de olho nos conteúdos de nossas redes sociais sobre o evento que contará com nossos especialistas e nomes como Rodrigo Branas, Elemar Junior e Klaus Wuestefeld.  Não perca essa oportunidade de se desenvolver e se conectar! 

https://open.spotify.com/episode/5leslsZoPVvcfucIXPga9C?go=1&sp_cid=65617f9945b6dafa4bd6df3d4f755a20&utm_source=embed_player_p&utm_medium=desktop Como é o impacto da tecnologia em diferentes gerações? No nosso primeiro bate-papo, convidamos duas pessoas de gerações distintas para debater sobre o impacto da tecnologia na sociedade. Uma delas é Moacir Marafon, um dos Sócios Fundadores e Presidente do Conselho da Softplan. Para fazer um contraponto, também recebemos Thiago Mathias Simon, um Desenvolvedor Júnior que, com apenas 19 anos, ingressou na empresa através de um programa de capacitação que é resultado de uma parceria entre a Softplan, o Senai SC e a ACATE. O host dessa conversa é o Guilherme Brasil, que a partir de hoje irá conduzir, mensalmente, debates que vão ampliar a sua visão sobre como os recursos atuais têm transformado a vidas das pessoas. A conversa foi muito proveitosa e falaremos sobre os principais pontos dela nesse artigo. A relação de cada convidado com a tecnologia Cada um dos convidados do bate-papo viveu a questão da tecnologia de uma maneira diferente, visto que nasceram em gerações totalmente distintas. Marafon teve seu primeiro contato com a tecnologia em uma matéria de introdução à computação no curso de Engenharia Civil. Quando se formou na faculdade, ele comprou uma calculadora Casio programada com 1700 bytes de memória, onde fazia programas e gravava os cálculos. Conforme Marafon adentrava no universo da tecnologia, ele se apaixonava e queria desvendá-lo ainda mais. Logo depois, ele foi trabalhar no Governo do Estado e encontrou um minicomputador com uma linguagem de programação Basic Comercial. Como autodidata, Marafon evoluiu sua experiência de programador e se encantou com essa área. Por isso, resolveu voltar para a Universidade Federal de Santa Catarina e fez parte da primeira turma de pós-graduação do curso de Ciências da Computação. Quando terminou, seu sonho de empreender no mundo da tecnologia ficou mais forte e acabou conhecendo dois parceiros que, juntos, criaram a Softplan. Diferente de Marafon, Thiago nasceu em um contexto digitalizado, no qual já existiam computadores em casa. Com isso, ele teve o convívio próximo com a tecnologia desde muito cedo. Com nove anos de idade, por exemplo, Thiago já tinha aula de operador de computador de forma EAD (ensino a distância). No ensino médio, o jovem iniciou o curso técnico em Desenvolvimento de Sistemas, que foi seu primeiro contato efetivo com a parte de programação. Hoje, com apenas 19 anos, ele trabalha na Softplan. Pode-se concluir que a tecnologia esteve presente em todos os momentos de sua vida. Thiago afirma que, atualmente, é difícil imaginar ir para algum lugar sem ter um celular do seu lado. A diferença geracional interfere no avanço da tecnologia? Durante a conversa, tivemos o privilégio de ter a perspectiva de diferentes gerações para analisar essa pergunta. Marafon, que se enquadra no começo da geração X (nascidos entre 1960 e 1980), expôs características marcantes da sua época. Entrou no mercado durante uma das maiores crises econômicas do Brasil, na qual as pessoas vivenciavam uma grande dificuldade para trabalhar na área de suas graduações. Para ele, a geração X é caracterizada por dar muito valor ao emprego e à estabilidade. Consequentemente, não era aconselhado a se arriscar, já que mudanças poderiam ser perigosas. Mas Marafon acredita que sua geração pode levar tais características e, juntamente com as gerações mais novas, gerar criações tecnológicas bem-sucedidas. Thiago, que faz parte da geração Z (nascidos entre 1995 e 2010), acredita que a diferença geracional interfere no avanço da tecnologia, mas não necessariamente de uma forma negativa. Ele observa a tecnologia como algo indispensável. Uma empresa que não possui um espaço virtual para ter um posicionamento, acaba tendo dificuldades de se comunicar e conectar com seu público, sobretudo jovens. A tecnologia vai evoluindo justamente por conta das diferenças geracionais, em que cada indivíduo com sua experiência apresenta ideias distintas e inovadoras que se complementam. Ao discutir esse tema e analisar a velocidade dos avanços na tecnologia, Guilherme, host do podcast, de forma resumida exprimiu sua opinião na seguinte frase: ‘’Essa convivência de várias gerações freia a velocidade, que já é exorbitante, da evolução tecnológica.’’ Regionalização do uso da tecnologia Cada vez mais, há um aumento do número de pessoas que se conectam à internet no Brasil. Para um país que possui desigualdades sociais visíveis, essa é uma notícia agradável de analisar. Certamente, ainda existem áreas onde não há acesso a internet. De modo geral, o país tem garantido a acessibilidade do mundo digital com uma velocidade rápida. A pesquisa TIC Domicílios, realizada pelo Centro Regional de Estudos para o Desenvolvimento da Sociedade da Informação (Cetic.br), mostra que o uso da internet no Brasil cresceu em 2020, passando de 74% para 81% da população, o que representa 152 milhões de pessoas. O aumento foi representativo, mas os 29% que ainda não tem acesso não podem ser esquecidos. Por isso, é responsabilidade dos governantes tornar o mundo digital próximo de toda a sociedade. O Presidente do Conselho da Softplan expôs, como exemplo, a sua vivência com a situação de regionalização do uso da tecnologia. Seus familiares vivem no interior de Santa Catarina, onde a questão do acesso a internet está, hoje em dia, sendo superada. As crianças, desde muito cedo, já sabem utilizar smartphones e computadores. Algo positivo, já que isso é resultado da democratização do acesso a internet. A riqueza da convivência de gerações distintas Quando diferentes tipos de gerações trabalham de forma unida, certamente há benefícios para uma determinada empresa e, além disso, pode gerar avanços na tecnologia. Analisar perspectivas distintas é fundamental, pois sempre há uma outra maneira de fazer algo ou de enxergar a solução para um problema. O debate entre as gerações é muito proveitoso. Quando se pensa em profissionais mais jovens, ideias como criatividade, energia, agilidade, praticidade estão quase sempre relacionadas. Juntando essas características com uma geração antiga, que é mais experiente, não tem como o resultado dar errado. Gostou do conteúdo? Ouça o bate-papo completo. Nele falamos de outras questões relacionadas ao que trouxemos neste artigo.

As coisas mudam rapidamente na indústria de TI. Novas tecnologias e versões surgem quase que diariamente e para acompanhar essa revolução tecnológica sem perder a excelência dos produtos entregues, as empresas estão realizando grandes investimentos em testes de software.   A ampla variedade de aparelhos, redes e plataformas acarretam um árduo trabalho humano nas empresas de tecnologia, que visam melhorar a experiência dos usuários através de testes de software.   Estes testes são manuais e repetitivos, e infelizmente podem ficar comprometidos devido a prazos curtos e dias exaustivos. Isso pode ser uma das causas do início da indústria de testes automatizados.  É nítido que cada dia mais as empresas estão buscando qualidade nos produtos /software, e podemos viabilizar mais agilidade por meio do uso de scripts automatizados. E mais do que nunca, hoje em dia temos um leque de opções de ferramentas de automação de teste, que nos auxiliam a produzir códigos cada vez mais robustos e eficientes.  O termo automação é amplo e carrega sentidos diferentes, algumas pessoas pensam que estamos falando de teste unitário, outros o veem como um script de teste funcional de regressão e ainda há o conceito de teste de desempenho, estresse e segurança. No entanto, temos que entender que todos realmente são scripts, mas a diferença está no objetivo do teste a ser executado.  O objetivo principal do teste automatizado é reduzir ao máximo o esforço de teste manual, com um conjunto mínimo de scripts, gerando mais credibilidade, otimizando a mão de obra humana, dando rapidez nas execuções e liberando a equipe para dar mais foco em assuntos estratégicos no projeto.   Os testes funcionais automatizados, por sua vez funcionam como um robô que simula a ação humana, abrindo o navegador, ou aplicativos móveis, realizando interações e inserindo valores nos campos, clicando em botões nas telas e comparando com os resultados esperados.  Os principais benefícios dos testes automatizados são:  Os testes automatizados levam menos tempo para serem executados do que os testes manuais: Os testes manuais podem ser lentos, principalmente quando há inúmeros deploys. Os testadores devem ler o procedimento, entender os cenários e executar uma ação manual, como digitar um comando ou pressionar um botão e ainda, registrar os resultados. Todos esses procedimentos podem ser substituídos por testes automatizados, permitindo que os testes sejam concluídos em um intervalo de tempo ideal. Os testes automatizados são menos sujeitos a erros do que os testes manuais: Cansaço, estresse, pressões do dia a dia e trabalho repetitivo podem levar a erros humanos. O teste, quando automatizado elimina essa possibilidade trazendo credibilidade as verificações de resultados esperados, pois o robô segue os passos definidos e não pula execuções. Os testes automatizados podem ser executados sem qualquer interação do usuário: Outra vantagem dos testes automatizados é a possibilidade de programar o disparo automático da execução dos scripts, sem a necessidade de uma ação humana. Permitindo por exemplo um teste diário do conjunto “x” de cenários, e até mesmo testar o comportamento do sistema em horários e dias alternativos, como sábado e domingo. Os testes automatizados podem ser executados em paralelo: Enquanto um testador humano só pode fazer uma coisa por vez, os robôs de automação podem simular vários testes ao mesmo tempo. Com testes automatizados bem arquitetados podemos verificar diferentes funcionalidades, em diferentes navegadores e sistemas operacionais, todos executados em paralelo e de maneira isolada. Os testes automatizados podem criar relatórios de teste bem elaborados: Os testes automatizados podem fazer mais do que o próprio teste. Eles também podem automatizar coisas que são normalmente feitos manualmente após a conclusão do teste. Neste caso, a criação de um relatório de teste automatizado que indica tudo que passou, falhou ou não foi executado. Além disso, o teste automatizado pode gerar evidências como prints e vídeos em tempo real de execução.  Dos benefícios mostrados acima, considero dois como os mais importantes: a eficiência e a precisão.   A eficiência dos scripts de testes automatizados são a chave mestre para agregar valor ao processo de teste manual. Ajudam a ganhar vantagem sob prazos curtos, pouca documentação e constantes interações.  Já a precisão, podemos considerar como a joia do processo automatizado, pois a padronização dos códigos proporciona resultados precisos e ajuda bastante para manter a qualidade do software.  Por isso devemos analisar juntamente com a equipe e saber as funcionalidades que devemos investir em automação, para garantirmos entregas mais rápidas e eficientes de qualidade aos clientes finais. 

Apesar de ser uma linguagem que está no mercado desde os anos 90, ela possui várias vertentes, várias abordagens e vem se atualizando e se adequando aos novos cenários. Além disso, muitas empresas usam Java como stack principal de desenvolvimento, o que torna o mercado de trabalho cheio de oportunidades para quem domina a linguagem. Antes de qualquer coisa, você precisará ter um ambiente instalado em sua máquina para trabalhar com Java. O básico é uma JDK (Java Development Kit) e uma IDE (Integrated Development Environment). Bem, é ai que você começa a sentir quão amplo Java é. Existem, basicamente, dois tipos de JDKs: a Enterprise e a Open. Desde que a Sun Microsystems foi adquirida pela Oracle, em Janeiro de 2010, a Oracle vem trabalhando em um perfil mais fechado e corporativo do Java, alinhado com os seus valores enquanto empresa. Para uso não comercial, o Java Enterprise é livre para uso apenas em sua versão mais recente. No entanto, dado a grande comunidade Global do Java, hoje temos também a Open JDK, fork do projeto principal da JDK durante sua versão 8, mantendo todos os princípios do software livre. E qual delas você deve escolher? Depende da sua necessidade. Acredito que, se você está começando no mundo Java, a melhor opção é a versão mais recente (stable) do Open. Essa é a que possui o maior número de features, com maior número de pessoas interessadas e discutindo sobre os problemas em torno dela. Além disso, por ser desenvolvida pela comunidade, a comunidade em si apoia em seu uso, que se mostra um caminho muito mais fácil que aprender totalmente sozinho.   A JDK  Em termos práticos, para instalar a Open JDK, você pode acessar este link e baixar a versão correta para o seu sistema operacional. No caso da opção pela JDK da Oracle, acesse este link e baixe a versão correta para o seu sistema operacional. Depois de baixado o instalador da JDK, instale em seu sistema como um programa normal. Em alguns sistemas e instaladores, o Java já se configura automaticamente para uso. Para confirmar isso, abra um terminal e digite java –version . Caso a instalação tenha se configurado corretamente, você deverá ter uma saída com o número da versão que você instalou, conforme exemplo a baixo:  Caso não tenha nenhum tipo de resposta ou resposta como “comando não encontrado”, você precisa adicionar o diretório “bin” dentro do diretório de instalação do Java ao path do seu sistema operacional. Isso varia muito de sistema para sistema. Nesse caso em específico, sugiro que busque diretamente sobre a sua necessidade em um buscador da internet.  A IDE  Uma vez feita a configuração de sua JDK, é possível realizar a escrita de artefatos Java diretamente em editores de texto, bem como sua compilação e execução em prompts de comando. Porém, a fim de facilitar o trabalho com Java, existem ferramentas chamadas IDEs (Integrated Development Environments) que agrupam ferramentas e funcionalidades destinadas ao uso com linguagens de programação. IDEs tendem a ser flexíveis e aceitar diversas configurações e plugins para atender diversas necessidades e linguagens de programação distintas. No caso do Java em específico, a IDE mais tradicional de todas é o Eclipse. O Eclipse já vem com uma série de ferramentas básicas configuradas para uso, como ferramentas de depuração de código (execução linha a linha, permitindo visualização de valores de variáveis em tempo real e simulação de execução de trechos de código) e versionamento de fontes (como GIT, SVN, vss, etc). O Eclipse pode ser baixado aqui. Além disso, em algumas de suas distribuições, é possível baixar junto a JDK a qual é configurada automaticamente por ele. Vale ressaltar que o próprio Eclipse possui várias versões. Durante sua instalação, ele questiona sobre o seu uso. A distribuição mais completa é a Java EE for web developers (e a que recomendo a instalação), pois permite diversos tipos de desenvolvimento com Java. É óbvio que, se o seu objetivo for algo muito específico dentro de Java (como desenvolvimento para dispositivos embarcados), essa versão não lhe atenderá e outra versão do Eclipse necessitaria ser baixada.   Porém, não se prenda ao Eclipse. IDEs dinâmicas como o Visual Studio Code estão crescendo na comunidade de desenvolvimento, pois permitem desenvolver em mais de uma linguagem com precisão, exigindo apenas esforço maior de configuração no início de seus projetos. Porém, tem maior versatilidade em projetos de maior complexidade e de diversas linguagens de programação distintas.   O Workspace  A instalação de IDEs em seu sistema operacional segue a instalação como de qualquer programa. No primeiro acesso, ela tem, por costume, pedir um diretório que será seu workspace (área de trabalho). O workspace, assim como as configurações internas da IDE, tende a ser de escolhas pessoais de forma a organizar todos os seus artefatos e projetos que você irá desenvolver. Pense a respeito e crie metodologia própria, pois não existe situação mais confusa que ambiente de trabalho desorganizado.  Considerações Tendo a IDE instalada, basta criar seu novo projeto ou clonar um repositório remoto, criar seus artefatos. Enfim, as portas de desenvolvimento em Java estão abertas. Basta explorar! Vale ressaltar que esse artigo é um pequeno recorte do grande mundo de desenvolvimento de software.  Para ver mais artigos muito interessantes sobre o universo do desenvolvimento, fique de olho aqui neste mesmo blog. Até uma próxima!  Fontes e Sugestões  Como instalar uma Open JDK no Windows. Como instalar o Visual Studio Code no Windows para trabalhar com Java