Oi pessoa, meu nome é MaurÃcio Aniche e nesse vÃdeo vou contar pouquinho do paper que a gente escreveu. Agente: eu, o Jo Yoder e o Fábio Kon; sobre os desafios que a gente passa hoje na hora de se modelar nos sistemas orientados a objetos Esse é paper super curtinho, 4 páginas, fácil de ler e você pode baixar gratuitamente na URL que aparece aqui no vÃdeo. Qual que é a história do paper? Bem, nós já sabemos o bastante sobre como se modelos bons sistemas orientados a objetos! Por bons, eu quero dizer sistema fácil de ser mantido, fácil de ser evoluÃdo. Num caso do bug, o desenvolvedor ou desenvolvedora sabe mais ou menos onde olhar, pra detectar e corrigir o bug. Então, se você pensa nos trabalhos do Grady Booch, do David Parnas do Robert Martin, do Martin Fowler e etc. Esses trabalhos dão para gente ideias de como modelar bom sistema. Então, como pensar separar nossos sistemas módulos, acoplamento, coesão e etc. Só que o grande desafio hoje é que a gente não desenvolve software no vácuo. Por exemplo, a gente quando cria software, a gente escolhe frameworks ou bibliotecas pra ajudar a gente a implementar o programa, então pensa, quando você vai fazer uma aplicação no web, você vai muito provavelmente escolher algum frameworks, por exemplo, Spring MVC que tá disponÃvel no mercado, pra que você seja mais produtivo e não precise implementar coisa que já estão implementadas. Ou acesso a banco de dados. Você vai provavelmente escolher frameworks, por exemplo, Ribernet pra te ajudar a consumir e acessar o seu banco de dados. Ou mesmo, as vezes se você não tem escolha. Pensa, você vai fazer uma aplicação mobile. Você depende da API que o Google oferece ali no android ou do que a Apple oferece ali pro Iphone e etc. E esses frameworks e bibliotecas, eles geralmente são super cheios de opinião. Você tem que desenvolver dessa forma. E essas bibliotecas, de novo, cheias de opinião, acabam influenciando na maneira que você modela a suas classes. Como assim? Como a gente tá ali, estudando orientação objetos, nós criamos classes e fazemos umas depender das outras e ali, qualquer decisão que eu tomo é boa, eu tenho liberdade de tomar qualquer decisão. Quando você começa a colocar esses frameworks, eles colocam as vezes restrições pra você. Então, por exemplo, se você tá usando o framework como o Ribernet, não é frame que a gente de ORM de relacionamento de mapeamento objeto relacional, quando você começa a fazer por exemplo, relacionamento bidirecional, você precisa pensar se você quer fazer isso mesmo, porque talvez isso vai ser pouco mais complicado pro Ribernet, talvez pouco mais custoso, enfim, monte de decisões que você toma baseados que o framework faz pra você. Então, essa influência, se você não pensar com bastante carinho ela vai acabar fazendo com que você tome decisões de projeto que você vai se arrepender no futuro, que não são decisões que vão te ajudar a manter seu software de maneira simples. Então, tá aqui o primeiro ponto de atenção que o paper chama. Cuidado, ninguém faz software no vácuo, a gente faz software usando monte de frameworks e biblioteca, e essas bibliotecas, as vezes vão forçar você a tomar decisões que você não queira tomar do ponto de vista de modelagem. E a grande sacada aqui é encontrar o melhor [...] possÃvel. Quanto que eu consigo modelar, sem que o frameworks passe a me atrapalhar muito. Acho que a primeira boa dica que tá na literatura já, com certeza é tentar ao máximo isolar as duas regras de negócios, as suas entidades, de bibliotecas e frameworks. Claro, falar é fácil, na hora de fazer é difÃcil. Então, a gente sugeri no paper, que tem muito trabalho ainda a ser feito, pra entender cada uma das diferentes arquiteturas, bibliotecas e frameworks que são usados no mercado e como modelar sistemas orientados a objetos que usam esses frameworks. A segunda coisa que a gente discute no paper é que hoje nos temos uma quantidade de clientes e usuários, diferentes uns dos outros e como cada uma dessas pessoas enxergam o sistema de uma maneira diferente e pra isso precisamos de modelagens pro mesmo problema que são pouquinho diferentes. Então, pensa por exemplo num sistema super grande que controla todo uma empresa. Talvez a pessoa do RH enxergue vamos dizer, a classe funcionária de uma maneira, diferente do que a pessoa que toma conta de contabilidade. O funcionário existe pras duas pessoas, tanto pro cara da contabilidade, quanto para a pessoa do RH, só que a representação que eles precisam é diferente. Talvez a pessoa do RH tá mais interessada a anos que você ta na empresa etc e tal, e a pessoa do contábil ta mais interessado no seu salário, no tipo de imposto que você paga e etc. Então, e ai pensa nisso agora, uma larga escala, onde você talvez tenha múltiplos diferentes, stakehoulders que é a palavra inglesa pra isso e todos eles olhando sobe o mesmo problema com representações diferentes. Então, a gente também quando estuda os temas orientados a objetos, a gente tem lá: A vamos modelar uma classe faturamento, uma classe produto e a gente pensa nessa classe produto como sendo produto para todo sistema. E no mundo real, não é bem isso que acontece, você vai ter diferentes classes produtos, todas elas representando produto, mas num ponto de vista de ângulo diferente. E aÃ, o desafio vem quando você tem que manter isso, porque você começa a não prestar muito atenção a replicar código, entre as mesmas, várias classes produtos do seu sistema, como reutilizar código, como linkar de uma representação pra outra. Então, é desafio bem grande que acontece sistemas de super grande escala. Né escala que estou pensando mesmo não, número de usuário que acessam o sistema ou coisa do tipo, mas de quão complexo o sistema que você está modelando é. O livro Eric Evans, chamado de Domain-Driven Design, até discute essa ideia de você modelar a mesma coisa de ângulos diferentes e da dicas de como isso pode acontecer. Mas do meu ponto de vista, a gente tem muito do que aprender sobre como modelar isso, de maneira com que o código seja fácil de evoluir, que a gente dificulte ou diminua a duplicação de código e etc. E por fim, eu acho que hoje nós temos também uma grande necessidade de medidas de qualidade mais contextuais. Medir qualidade de código, identificar partes do sistema que merecem ser refatoradas é desafio real e até temos ferramentas pra isso. Ferramentas que por exemplo conseguem medir a complexidade do código ou como acoplado esse código é. Ferramentas até mais modernas conseguem ganhar por exemplo, ao longo da vida daquela classe quantos bugs ela já teve, quantas vezes ela foi modificada, pra levar isso consideração na hora de dar uma recomendação ou não. E a gente tá chegando lá, se você olha métricas de código por exemplo, lá nos anos 90 até antes disso, pra métricas que a gente tem hoje, que analisam repositórios, até usam pouquinho de aprendizados de máquina, tá muito melhor. Só que o grande desafio aqui, é que a gente precisa de métricas que sejam mais contextuais. Como assim contextual? O que eu quero dizer é, talvez a noção de complexidade que você tenha pra sistema web, seja diferente da noção de complexidade que você tem pra sistema mobile, ou de sistema embarcado de sistema cyber-physical. Então, a grande sacada aqui e o que a gente tentou discutir no paper é que do nosso ponto de vista, o futuro vai ser ferramentas que entendem. Olha, eu to nesse tipo de arquitetura, eu tomei essas decisões aqui de design. Então, é assim que eu tenho que medir qualidade e não de maneira mais genérica, que é o que a gente vê nas ferramentas de mercado hoje. Você vê lá uma ferramente medindo acoplamento e ela não quer saber se sua classe é uma controladora, se é uma entidade ou se é uma classe de acesso a banco de dados. Complexidade é tudo igual e bola pra frente. É isso que acontece hoje, e a gente quer mudar isso pouquinho, a gente acha que isso tem que mudar. De novo no sentido que essas métricas tem que ser mais contextuais, tem que começar a entender a maneira com que você programa. Não atoa, a literatura mostra que esse tipo de ferramenta apresenta muito falso positivo. A pessoa desenvolvedora olha a ferramenta falando desse código que não tá tão bom e a pessoa desenvolvedora fala: opa, eu acho que tá ok. Bem, essas são os 3 grandes desafios atuais que a gente discute no paper. Eu sugiro você ler o paper, esse paper também é super cheio de referências bem legais sobre o que a gente já sabe sobre orientação a objetos, então, definitivamente recomendo vocês a lerem. E no paper a gente também dá referências atuais que tentam atacar esses 3 problemas que a gente menciona. Então, fica ai mais coisa pra vocês lerem e estudarem e se quiserem discutir qualquer coisa sobre o assunto só mandar uma mensagem pra nós 3, que vai ser prazer. Ta bem? Até o próximo vÃdeo.
