Se 80% do que você faz no dia a dia como desenvolvedor(a) é ler e escrever código, então nada mais justo do que investir no seu aprendizado sobre como desenhar e escrever código de qualidade. Neste plano de estudos vamos navegar por diversos conceitos, técnicas, dicas de design e tradeoffs ao escrever código que seja fácil de ler e entender, simples de manter a médio-longo prazo e flexível o suficiente para ser evoluído mitigando a complexidade acidental.
Para isso, vamos estudar orientação a objetos, técnicas e conceitos de programação pragmática, design patterns e alguns estilos arquiteturais para organizar e estruturar nosso código. Focaremos na linguagem Java, mas boa parte do que veremos são conceitos do paradigma orientado a objetos que podem ser facilmente aplicados com outras linguagens e plataformas.
Aqui assumimos que você já possui algum conhecimento sobre os temas abordados ou já os pratica no dia a dia, pois dessa forma podemos ir mais longe e abrir sua mente sobre as ferramentas que você tem em mãos mas provavelmente não está tirando máximo proveito. Abaixo os tópicos principais que estudaremos:
- Orientação a objetos e técnicas de design de código
- Revisitando Design Patterns
- SOLID: ou como juntar OO e design patterns na mesma panela
- Design e arquitetura de código
Ao fim desse plano de estudos, você terá heuristicas úteis que te ajudarão a olhar para trechos de código e que te permitirão identificar oportunidades de refatoração e implementação de código com maior qualidade e que também elevará regua em sessões de code review.
Por algum motivo nos convenceram que orientação a objetos é algo simples, mas a verdade é que não é. Ao estudar sobre o conteúdo que curamos aqui você vai entender que o cerne da OO se baseia em manter estado e comportamentos juntos. Quanto mais cedo você entender isso mais facilmente você saberá como encapsulamento, polimorfismo e composição se encaixam no seu design.
Junto a OO, também estudaremos algumas técnicas que irão te guiar no dia a dia para escrever código mais enxuto, fléxivel e de fácil manutenção. E, por fim, você também vai aprender como especialistas usam todos estes conceitos e técnicas no dia a dia através de heurísticas que vão te colocar noutro patamar na hora de escrever, refatorar e revisar código.
- Orientação a Objetos
- 1.1. Introdução: Programação Orientada a Objetos e programação estruturada (10min)
- 1.2. Objetos não são atributos + funções 🤯 (7min)
- 1.3. Como não aprender Java e Orientação a Objetos: getters e setters (10min)
- 1.4. Como não aprender orientação a objetos: Herança (12min)
- 1.5. Como não aprender orientação a objetos: o excesso de ifs (10min)
- 1.6. Fantoches (8min)
- 1.7. Evitando VOs e BOs (7min)
- 1.8. Enums são mais que constantes 🤯 (6min)
- 1.9. OO na Prática: representando o usuário logado no sistema (8min)
- 1.10. OO na Prática: Cuidados com relacionamento bidirecional (10min)
- 1.11. OO na Prática: Controle Transacional Programático em Sistemas Legados (15min)
- 1.12. OO na Prática: Evite condicionais em JavaScript com o uso de Duck Typing (8min)
- Tell, don’t ask e The Law of Demeter
- 2.1. Tell, Don't Ask (10min)
- 2.2. TellDontAsk - What Martin Fowler thinks about it? (8min)
- 2.3. Tell, Don't Ask, The Pragmatic Way (12min)
- 2.4. Tell, don’t ask (by Robson Castilho) (10min)
- 2.5. The Law of Demeter - Writing Shy Code (10min)
- 2.5. Java examples of the Law of Demeter (10min)
- Early Return e Fail Fast
- 3.1. Return Early Pattern (7min)
- 3.2. Fail Fast (2004) (15min)
- 3.3. How to Make Readable Code: Return Early or If Statement? (8min)
- 3.4. Are Early Returns Any Good? (10min)
- Design by Contract
- 4.1. Contratos Nulos 🤯 (8min)
- 4.2. Wikipedia: Design by contract (15min)
- 4.3. Assertion and Design by Contract in Java (12min)
- 4.4. Programming by contract on the JVM (10min)
- 4.5. 3 Benefits of Design by Contract (7min)
- Heurísticas de código OO no mundo real
- 5.1. Refatoração: Sete situações que eu percebo de maneira quase automática 🤯 (28min)
- 5.2. Como evitar um dos piores acoplamentos que existem (13min)
- 5.3. Como eu sei se devo criar ou não uma nova abstração para um determinado parâmetro/retorno? (32min)
- 5.4. Acoplamento distribuído: O fundo do poço dos acoplamentos (30min)
- 5.5. Encapsulamento para ganhar mais coesão: O feijão com arroz que precisa estar dominado (22min)
Agora que você já se sente mais confortável com OO e as técnicas de design de código discutidas até aqui, vamos validar nosso conhecimento através de atividades práticas 💪🏻
Que tal olhar para seu projeto atual e identificar trechos de código com grande potencial de melhoria de qualidade?
É isso mesmo, é hora de refatorar código 🥳🥳
Para cada trecho de código que você identificar no seu projeto, faça:
- a) Se possível, refatore o código do projeto e submeta uma PR para revisão; aproveite e discuta com seu time sobre as motivações do seu refactoring e os pontos positivos que você enxega;
- b) Crie Gists com a versão de antes e depois da refatoração, e por fim compartilhe-os no nosso forum do Github para melhor feedback e discussões;
⚠️ Privacidade e confidencialidade
Lembre-se dos cuidados ao compartilhar código fora da empresa, crie Gists privados na sua conta da Zup no Github, evite expor dados sensíveis do seu projeto e compartilhe somente com Zuppers.
Por fim, se você ainda não fez nossa avaliação Knowledge about Object-Oriented Design ou se não obteve êxito nela, essa é uma excelente oportunidade para (re)fazê-la.
Acesse o link da avaliação e valide seus conhecimentos sobre design de código orientado a objetos! 🎯
Embora você tenha adicionado diversas heurísticas de código no seu cinto de utilidades, muitos problemas comuns em projetos de software são facilmente identificados e solucinados através de "receitas prontas", conhecidas como Design Patterns (ou Padrões de Projetos, do português). Não à toa, um bom desenvolvedor(a) precisa conhecer os principais design patterns catalogados, quais os tipos de problemas de design de código que eles resolvem e por fim conseguir facilmente aplicá-los.
Esta é uma boa oportunidade para revisitarmos alguns patterns populares e tentar conectá-los com nosso aprendizado sobre design OO 😁
- Design patterns: Breve introdução aos padrões de projeto (15min)
- Creational Design Patterns
- 2.1. Factory Method (20min)
- 2.2. Builder (20min)
- 2.3. Singleton (15min)
- Structural Design Patterns
- Behavior Design Patterns
- 4.1. Command (20min)
- 4.2. Strategy (20min)
- 4.3. Observer (20min)
- 4.4. Template Method (15min)
- Inversion of Control (IoC) e Dependency Injection (DI)
- 5.1. Inversion of Control Containers and the Dependency Injection pattern (45min)
- 5.2. Demystifying Inversion of Control (IoC) (12min)
- Functional Programming Patterns e Loan Design Pattern
Hora de validar nosso conhecimento sobre design patterns, mas desta vez vamos exercitar nossa habilidade de escrever artigos a fim de ajudar outros desenvolvedores(as) dentro e fora da Zup 💪🏻
Escreva um artigo sobre Loan Design Pattern para ajudar seu time a conhecer melhor este padrão de projeto, os tipos de problemas que ele resolve e como identificar oportunidades de aplicá-lo.
⚠️ Lembre-se de compartilhar seu artigo
Você pode escrever o artigo onde você achar melhor (como Gist, Google Docs, blog pessoal etc), o importante é que você consiga compartilhá-lo com nossa turma e monitor através de um link público no nosso forum do Github 😊
Por fim, se você ainda não fez nossa avaliação Knowledge about Design Patterns ou se não obteve êxito nela, essa é uma excelente oportunidade para (re)fazê-la.
Acesse o link da avaliação e valide seus conhecimentos sobre os principais e mais utilizados design patterns no mercado! 🎯
Além dos design patterns que estudamos no tópico anterior, existe um conjunto de 5 principios que foram apresentados por Robert C. Martin (Uncle Bob) há +20 anos atrás para ajudar desenvolvedores(as) a escrever código que seja fácil de entender e fácil de mudar. Mais tarde, estes principios ficaram conhecidos pelo acronimo SOLID.
A ideia do SOLID é tirar ainda mais proveito da orientação a objetos a fim de resolver problemas comuns relacionados a código em projetos de software. Na Zup Edu gostamos de pensar que SOLID discute, extrai e aponta o melhor do Polimorfismo na OO, o que nos permite entender o real poder desse pilar de forma isolada e em termos de arquitetura de código. Por esse motivo, se você aprendeu bem sobre OO com conteúdo que curamos até aqui então com toda certeza você se sentirá bastante confortável nos estudos de SOLID.
Por fim, vale a pena refletirmos sobre SOLID de uma maneira mais crítica, afinal tudo em engenharia de software possui prós e contras. Ou seja, será que SOLID é tão "solid" assim? 🤔
- Clean Code e SOLID com Alberto Souza (16min)
- Zupcast #55: Desbravando SOLID com Alexandre Aquiles (37min)
- SOLID Principles: melhorando o design do seu código (10min)
- SOLID para devs de alta performance (15min)
- SOLID: Programação Orientada a Objetos (1h)
- Why SOLID principles are still the foundation for modern software architecture (12min)
- The Principles of OOD (20min)
- Solid Relevance (15min)
- Livro Desbravando SOLID - Alexandre Aquiles (4-6h)
- Livro Orientação a Objetos e SOLID para Ninjas - Mauricio Aniche (4-6h)
- Que tal contrapontos? 😈 Livro SOLID is not SOLID - David Bryant Copeland (3-6h)
Mais uma rodada para validarmos nosso conhecimento e fortalecer as conexões do que estudamos.
Aqui temos 2 possibilidades de tarefas, escolha a que achar mais interessante para exercitar seu aprendizado (mas se quiser você pode fazer as duas 😎):
- a) Se possível, encontre um trecho de código no seu atual projeto e refatore-o aplicando algum dos principios SOLID. Em seguida, crie um Gist com a versão de antes e depois da refatoração, e compartilhe-o no nosso fórum do Github;
- b) Escolha um dos principios SOLID e escreva um artigo sobre ele de tal forma que um desenvolvedor(a) junior possa utiliza-lo como fonte de aprendizado. Aqui é importante ser didático e apresentar bons exemplos de código;
⚠️ Lembre-se de compartilhar seu artigo
Você pode escrever o artigo onde você achar melhor (como Gist, Google Docs, blog pessoal etc), o importante é que você consiga compartilhá-lo com nossa turma e monitor através de um link público no nosso forum do Github 😊
Por fim, se você ainda não fez nossa avaliação Knowledge about SOLID Design Principles ou se não obteve êxito nela, essa é uma excelente oportunidade para (re)fazê-la.
Acesse o link da avaliação e valide seus conhecimentos sobre os principios de design SOLID! 🎯
Ao começar um novo projeto de software você precisará definir qual arquitetura de código você adotará no seu projeto. Ter uma arquitetura bem definida guiará o time na hora de desenvolver novas funcionalidades, na hora de navegar e encontrar artefatos na base de código existente mais rapidamente e, principalmente, a mantê-la por médio-longo prazo de forma sustentável.
Existe diversos estilos arquiteturais, mas sem dúvida, hoje em dia os estilos arquiteturais mais populares e utilizadas no mundo Java são Clean Architecture e Hexagonal Archicteture. Mas será que eles são ideais para todo tipo de projeto, incluindo microsserviços? Quais os pontos fortes e fracos delas? Onde elas ajudam e, principalmente, onde elas podem atrapalhar? 🤔
Será que depois de todo conhecimento e aprendizado sobre OO, design patterns e principios de design SOLID o estilo arquitetural importa tanto assim? Será que estou olhando pro lugar certo? 🤔
- Hexagonal Architecture
- 1.1. Hexagonal architecture - Alistair Cockburn (15min)
- 1.2. Treinamento na Handora: Introdução a arquitetura Hexagonal (4-6h)
- Clean Architecture
- Nem Hexagonal nem Clean Architecture
- 3.1. PresentationDomainDataLayering - Martin Fowler (10min)
- 3.1. Layered architecture pattern in software engineering (15min)
- 3.1. Package by Feature 🤯 (15min)
- 3.2. Package by feature, not layer (10min)
- 3.3. Package by Layer vs Package by Feature (15min)
- 3.4. Discussão entre especialistas no Spaces do Twitter sobre “Clean Arch morreu?” 🤯😈 (1h32min)
- 3.5. Overengineering in Clean/Onion/Hexagonal Architectures 🤯 (15min)
Essa atividade vai exigir um pouco mais de você, mas com certeza vai te ajudar a solidificar o que estudamos sobre estilos arquiteturais e vai te dar "pano pra manga" para discutir com sua turma, monitor e, quem sabe, até com seu time 😈
Crie um novo projeto de microsserviço onde você consiga aplicar o estilo arquitetural Package by Feature. A ideia é você escrever esse serviço aplicando este estilo arquitetural e poder enxergar os prós e contras com outros estilos arquiteturais mais rebuscados.
Para melhor proveito dessa atividade, é obrigatório que seu serviço possua no minimo 2 features. Melhor ainda se ele contiver 3 ou 4 features, assim você pode praticar mais e reforçar o aprendizado 💪🏻
Lembre-se de compartilhar o projeto no nosso fórum do Github para feedback e possíveis discussões!
Se você ainda não fez nossa avaliação Knowledge about Hexagonal Architecture ou se não obteve êxito nela, essa é uma excelente oportunidade para (re)fazê-la.
Acesse o link da avaliação e valide seus conhecimentos sobre Arquitetura Hexagonal! 🎯
Por fim, se você ainda não fez nossa avaliação Knowledge about Clean Architecture ou se não obteve êxito nela, essa é uma excelente oportunidade para (re)fazê-la.
Acesse o link da avaliação e valide seus conhecimentos sobre Arquitetura Limpa! 🎯