Autor: magoolation

Este artigo foi publicado em 2018. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera!

Não é novidade para ninguém, principalmente por vocês estarem lendo meu blog, que a tecnologia evolui mais rápido que Pokemon em evento especial e com isto novas linguagens, frameworks, metodologias, hardware, software, etc.

Mas algo que me incomoda muito, principalmente quando vamos procurar por materiais introdutórios as novas tendencias é que eles são criar para “matar um problema que temos com as tecnologias atuais”.

Não quero tomar partidos aqui mas as brigas “SQL x NoSQL”, “Micro Serviços x Monolitos”, “PWA x Aplicativos”, “Bots x Apps”, etc. etc. inundam events, timelines, artigos e tudo mais como se uma coisa anulasse totalmente a outra.

Em primeiro lugar é sempre bom ter boas referencias, ou seja, não cair no conto dos “influenciadores de palco”, sim me baseei nos “empreendedores de palco”, que não tem nenhum projeto entregue utilizando o que pregam em palestras, que só se apoiam em cases e dados dos outros, e querem te levar a usar o que. Ele diz em pró de vender uma consultoria, a qual irá fazer com que voce trilhe o caminho sozinho, e na verdade que voce apareça como case de sucesso no seu próximo slide.

Quando lemos ou falamos com pessoas sérias sobre o tema vemos que eles falam exatamente o contrário. Sobre Micro Serviços será que sua aplicação já está madura a ponto de voce saber que ela deve ser quebrada? Afinal voce não começa hoje um sistema pensando em dividi-lo sem saber como ele ficará.

Quando falamos de persistencia pessoas sérias falam de “persistência poliglota”, ou seja, nossa aplicação sabe falar com diferentes repositórios d dados, cada um com responsabilidades diferentes baseadas nas capacidades que. Aquela tecnologia oferece, de modo a trazer valor cada vez mais rápido pra estes dados.

Veremos cada vez mais partes de aplicativos partindo para os bots ou interfaces conversacionais, ou como já vimos em alguns apps de investimentos aplicativos que simulam esta interface apesar de ainda ser um aplicativo com fluxos como qualquer outro, traremos cada vez mais inteligência analisando o comportamento de nossos usuários e sim teremos versões mais leves, provavelmente PWAs para trechos específicos de nossos aplicativos para que nosso usuário tenha uma experiencia “light” de qualquer lugar.

Gosto de pensar que quando leio um código antigo meu e penso: nossa teria sido melhor ter feito assim ou assado, que. Depois que eu o escrevi vivenciei tantas novas experiencias que fica fácil falar isto, e difícil até mesmo imaginar que er possível se fazer tanta coisa sem os recursos que temos hoje, mas que se tomei aquela decisão era porque naquele momento fiz o melhor que era possível, e continuando aplicando isto até hoje.

É como dizem: “Se a juventude soubesse ou se a velhice pudess
E!”.

Até a próxima!

Este artigo foi publicado em 2018. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera!

Quando iniciamos nossos estudos de Orientação a Objetos aprendemos que classes e objetos possuem dados e comportamentos.

Isto é sim verdade, mas da forma que. Isto é listado, os exemplos e tudo mais parece que a parte mais importante são os dados, mas será que isto é verdade?

Dando um passo atrás devemos lembrar sempre que ao modelar uma classe devemos ter em mente o contexto onde ela será utilizada, o qual normalmente chamamos de domínio, de forma a termos uma visão clara do mesmo.

Nem todos os nossos sistemas precisam ter acesso a todos os dados do cliente, alias apensar do reuso ser algo que está no DNA da Orientação a Objetos não é crime nenhum termos diferentes versões de uma mesma classe, como o Cliente que é usado na Nota Fiscal, o Cliente que é usado no módulo de Entrega, o Cliente utilizado pelo sistema Financeiro, cada um com um grupo de dados, e comportamentos, diferenciados.

Outra coisa importante é lembrar que um objeto representa o estado de algo em um determinado momento no tempo. Ao carrega-lo do sistema de persistência ele representa aquele item naquele exato momento, e a partir de que começamos a manipula-lo através da chamada de seus métodos, ele sofrerá alterações e deve ainda permanecer em um estado válido para posterior persistência.

É por isto que hoje ouvimos tanto falar em Setters privados, encapsulamento dos comportamentos, garantia de que não quebraremos o estado.

Mas fui além do que queria falar no inicio deste artigo.

O ponto central aqui é que por começarmos nossa modelagem pelos dados corremos dois riscos: colocarmos em nossas classes dados que achamos que iremos utilizar e transformamos nosso objeto em uma sacola de dados.

A abordagem que gostaria que vocês experimentassem aqui é a de começar modelando suas classes po seus comportamentos, ou seja, quais mensagens usarei para me comunicar com ela.

Com isto já consigo visualizar dois itens importantes: quais parâmetros estes métodos receberão? E destes parâmetros qual estado deverá ser alterado e persistido.

Se te pedisse para modelar uma classe de Conta Corrente com toda certeza voce começaria com os dados do correntista, da agencia, etc., etc.

Mas e se dentro do contexto que estamos desenvolvendo, talvez um microserviço que cuide apenas de manipular o saldo desta conta, com serviços como Depositar uma quantia e Sacar uma quantia, a coisa já muda de figura, certo?

Então temos aqui uma classe Conta com dois métodos, Depositar e Sacar.

Curiosamente os dois métodos recebem um valor monetário, o valor a ser depositado ou retirado da conta.

Como resultado teremos o Saldo desta conta atualizado e persistido.

Logo teremos também um atributo, preferencialmente privado, com este Saldo.

Algo como:

Classe Conta { void Depositar(decimal valor) => Saldo = Saldo + valor; void Sacar(decimal valor) => Saldo = Saldo – valor; private decimal Saldo = 0; }

Sim, bem simples, bem rudimentar, mas que me parece ser funcional.

Agora vamos pro segundo ponto. E se por um erro sistêmico eu passar um valo negativo tanto para Depositar como Sacar? E se eu tentar sacar um valor maior do que meu saldo atual? Colocarei minha conta corrente em um estado inválido.

É por isto que o encapsulamento de como minha classe funciona é tão importante. Com isto eu garanto que qualquer parte do meu sistema não irá bagunçar meu estado interno e com isto tenho um maior controle do qu está acontecendo, reduzindo a possibilidade de erros.

O encapsulamento também me traz mais benefícios. Consigo realizar testes de maneira mais isolada e eficaz já que. Reduzo a possibilidade de alterações de estado involuntário tornando os resultados previsíveis.

Em nossa classe como não conseguimos alterar o saldo sem chamar Depositar ou Sacar, independente de como eu fizer minhas operações, eu sempre obterei o mesmo resultado.

Não estou falando aqui d concorrência e outros desafios do mundo moderno, mas se não conseguimos visualizar estes problemas já em abstrações mais básicas, a coisa se torna muito mais complicada em versões mais completas e complexas deste modelo.

Espero ter ajudado!

Até a próxima!

Este artigo foi publicado em 2018. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! No último domingo, dia primeiro de julho, foi iniciado um novo ciclo do programa Microsoft MVP o qual tenho a honra de fazer parte desde 2016. Para quem não conhece o programa trata-se de uma iniciativa da Microsoft, que já tem 25 anos, onde membros da comunidade que tem contribuições relevantes do ponto de vista do compartilhamento de conhecimentos, recebe este premio de reconhecimento e alguns benefícios, apesar de o melhor deles ser realmente a integração com profissionais fantásticos e um contato mais direto com as equipes de produto. Caso queira conhecer mais sobre o programa basta acessar https://mvp.microsoft.com. Mas por que isto é tão importante pra mim? Lembro que em 2008 foi quando tive o primeiro contato e real interesse com comunidades. Havia recém sido fundado o grupo .NET Archtects e em 2009 foi a primeira vez que ouvi falar do programa. Desde então esta galera vem me inspirando. Achava que eles estavam em um outro nível, mas fazia meu melhor para que da mesma forma que eles, eu conseguisse impactar e inspirar pessoas que quisessem entrar ou até mesmo crescer dentro da área de desenvolvimento. E este trabalho trouxe bons frutos, como citei acima. Nem preciso dizer que se cheguei onde cheguei hoje com certeza é resultado do meu trabalho, mas algumas coisas deram uma força e o programa realmente me abriu diversas portas. Fica aqui registrado então o meu compromisso de continuar sendo referencia e ajudando o máximo de pessoas, o meu parabéns aos colegas que também renovaram e aos novos integrantes do time, e a voce que está lendo este post e tem me motivado e confiado em meu trabalho. Até a próxima!

Este artigo foi publicado em 2018. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

Fala galera! Hoje foi confirmada a aquisição por parte da Microsoft da plataforma GitHub. Se não sabe do que se trata provavelmente voce foi congelado junto com o Capitão América e não sabe o ue aconteceu na industria do software nos últimos anos. O GitHub é a maior plataforma de compartilhamento de códigos do planeta com mais de 80 milhões de repositórios e 27 milhões de usuários. Utilizado tanto por grandes projetos open source como por gigantes da industria o GitHub revolucionou a forma como o código fonte era gerenciado pelas equipes tornando o so do git ainda mais fácil. Esta aquisições não só mostra para o mercado a real importância do GitHub mas também;em a preocupação da Microsoft em estar. conectada aos desenvolvedores e oferecer em todas as plataformas a excelência em serviços. Muito está por vir com esta integração e apesar de muitos descrentes começarem a abandonar a plataforma acredito ainda mais na sua continuidade como um espaço livre mas com a possibilidade de. expansão com os serviços da gigante de Redmond. Vamos aguardar! Até a próxima!