1. >>>
1.1. Next.js
1.1.1. O que é?
1.1.1.1. "O Framework React para Produção"
1.1.1.2. Framework vs Biblioteca
1.1.2. O que ele tem a oferecer?
1.1.2.1. Componentes
1.1.2.1.1. Link
1.1.2.1.2. Image
1.1.2.1.3. Script
1.1.2.1.4. Head
1.1.2.2. Roteamento
1.1.2.2.1. Rotas via Sistema de Arquivos
1.1.2.2.2. Rotas dinâmicas
1.1.2.2.3. router e useRouter()
1.1.2.3. Rotas de API
1.1.2.4. Renderização
1.1.2.4.1. Lado do cliente
1.1.2.4.2. Lado do servidor (SSR)
1.1.2.4.3. Geração de sites estáticos (SSG)
1.1.2.4.4. Incremental Static Regeneration (ISR)
1.2. Testes Automatizados no Javascript
1.2.1. Introdução
1.2.1.1. Linguagem javascript
1.2.1.2. Foco no back-end
1.2.1.3. Etapas:
1.2.1.3.1. Conhecendo a teoria por trás dos testes
1.2.1.3.2. O framework Jest e nosso primeiro teste
1.2.1.3.3. Testes unitários e de integração na prática
1.2.1.3.4. Testando uma API rest com banco de dados
1.2.2. Conhecendo a teoria por trás dos testes
1.2.2.1. O que são?
1.2.2.1.1. Código que testa seu código
1.2.2.1.2. Simula o comportamento do seu software para assegurar que tudo está funcionando como deveria
1.2.2.1.3. Estrutura de um teste
1.2.2.1.4. Principais tipos de testes automatizados
1.2.2.1.5. Conceitos importantes:
1.2.2.2. Por que escrever?
1.2.2.2.1. Todo software é testado
1.2.2.2.2. Testes manuais vs Testes automatizados
1.2.2.2.3. Mitos sobre escrita de testes automatizados
1.3. SOLID e Design Patterns
1.3.1. O que é SOLID?
1.3.1.1. Conjunto de princípios
1.3.1.2. Independentes de linguagem e paradigma
1.3.1.3. Introduzidos e promovidos por Robert C. Martin, mesmo autor do famoso livro Clean Code
1.3.1.4. Servem para
1.3.1.4.1. prevenir o "apodrecimento" do software
1.3.1.4.2. melhorar a qualidade do código
1.3.1.4.3. diminuir o acoplamento
1.3.1.4.4. aumentar a testabilidade
1.3.1.4.5. facilitar manutenção e extensões futuras
1.3.2. SOLID: Single Responsability
1.3.2.1. Uma entidade deve ter responsabilidade sobre uma única parte da funcionalidade de um programa (e deve encapsular essa parte).
1.3.2.2. Uma entidade deve ter “uma única razão para ser alterada”.
1.3.2.3. Não necessariamente significa ter um único método.
1.3.2.4. Evitar classes “faz-tudo”.
1.3.2.5. Com várias classes menores e mais precisas reduzimos o acoplamento e facilitamos a manutenção do código
1.3.3. SOLID: Open-closed
1.3.3.1. Uma entidade deve estar aberta para extensão e fechada para modificação.
1.3.3.2. Devemos estender uma funcionalidade adicionando código novo ao invés de modificando o código já existente.
1.3.3.3. Dessa forma diminuímos as chances de quebrar funcionalidades essenciais da aplicação e facilitamos a implementação de novas funcionalidades.
1.3.4. SOLID: Liskov's Substitution
1.3.4.1. Qualquer objeto e subobjeto devem ser intercambiáveis sem que isso quebre a aplicação.
1.3.4.2. Dada uma classe T, qualquer subclasse S que estende T deve ser capaz de substituir (ou ser substituída por) T em qualquer lugar da aplicação.
1.3.4.3. Dada uma interface I, qualquer classe C que implemente I deve ser capaz de substituir qualquer outra referência pelo código que implemente essa mesma interface.
1.3.4.4. Um objeto de uma subclasse não é intercambiável com um objeto da superclasse automaticamente.
1.3.4.5. Devemos tomar cuidado ao abstrair conceitos e características do mundo real de forma descuidada, pois isso pode levar a abstrações que não funcionam.
1.3.5. SOLID: Interface Segregation
1.3.5.1. Nenhum código deve ser forçado a depender de métodos que ele não usa.
1.3.5.2. Ou ainda nenhum código deve depender de nada além do método que ele está chamando.
1.3.5.3. Mudar um método em uma classe não deve afetar nenhuma classe que não dependa dela
1.3.5.4. Dessa forma, um cliente que estiver consumindo essa interface saberá apenas aquilo que interessa a ele e diminuímos o acoplamento na aplicação.
1.3.6. SOLID: Dependency Inversion
1.3.6.1. Nunca dependa de nada concreto, apenas de abstrações (interfaces, classes abstratas, etc)
1.3.6.2. Ou ainda, abstrações não devem depender de detalhes, detalhes (implementações concretas) devem depender de abstrações.
1.3.6.3. Módulos de alto nível não devem depender de módulos de baixo nível, apenas de abstrações.
1.3.6.3.1. Módulo de Alto Nível
1.3.6.4. Deve ser fácil mudar uma implementação sem alterar código de alto nível.
1.3.6.5. Obs.: não confundir com injeção de dependências
1.3.7. O que são design patterns?
1.3.7.1. Design patterns são
1.3.7.1.1. soluções genéricas e reutilizáveis para problemas recorrentes
1.3.7.1.2. soluções atestadamente eficazes que ajudam a manter a qualidade do nosso código
1.3.7.2. Design patterns não são
1.3.7.2.1. uma solução pronta, logo não dá para copiar e colar cegamente no seu código
1.3.7.2.2. uma solução perfeita, logo exigem conhecimento por parte do programador para entender o cenário e a forma correta de aplicação
1.3.7.3. São tradicionalmente classificados em
1.3.7.3.1. padrões de criação (creational patterns)
1.3.7.3.2. padrões de estruturação (structural patterns)
1.3.7.3.3. padrões de comportamento (behavioral patterns)
1.3.7.4. Vale destacar que
1.3.7.4.1. não existe um número fixo de design patterns, novas soluções sempre poderão surgir e soluções já existentes podem cair em desuso
1.3.7.4.2. nessa série nós iremos conhecer alguns dos padrões mais importantes e mais utilizados
1.3.7.4.3. você pode e deve continuar aprendendo sobre design patterns, estudando outros além dos que veremos aqui
1.3.7.5. Referências e indicações:
1.3.7.5.1. Use a cabeça!: padrões de projetos, por Eric Freeman e Elisabeth Freeman
1.3.7.5.2. Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos, por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four)
1.3.7.5.3. Refactoring.Guru, disponível em https://refactoring.guru
1.3.8. Strategy Pattern
1.3.9. Factory Method Pattern
1.3.10. Adapter Pattern
1.4. UI e UX para Programadores
1.4.1. O que é UI e design de UI
1.4.1.1. Interface de Usuário
1.4.1.1.1. De forma genérica
1.4.1.1.2. Na programação
1.4.1.1.3. Podem ser boas ou ruims:
1.4.1.2. Design de UI
1.4.1.2.1. Criação das interfaces de usuário
1.4.1.2.2. Intenção
1.4.1.2.3. Responsabilidade do UI designer
1.4.1.2.4. Ferramentas
1.4.2. Etapas do design de UI
1.4.2.1. Nunca vá direto para o código!
1.4.2.2. Não é uma receita de bolo nem um manual de regras
1.4.2.3. Para executar e reexecutar
1.4.2.3.1. Planejamento
1.4.2.3.2. Pesquisa
1.4.2.3.3. Wireframe
1.4.2.3.4. Protótipo
1.4.3. Fundamentos do design de UI
1.4.3.1. **Atenção:** os termos podem variar de acordo com a literatura mas seus princípios geralmente são parecidos
1.4.3.2. Exemplos:
1.4.3.2.1. https://www.microsoft.com/pt-br/
1.4.3.2.2. https://medium.com/
1.4.3.2.3. http://www.gatesnfences.com/
1.4.3.2.4. https://www.airbnb.com.br/
1.4.3.2.5. https://www.amazon.com/
1.4.3.2.6. https://arngren.net/
1.4.3.3. Alinhamento
1.4.3.3.1. O arranjo dos elementos em relação às bordas e limites de um determinado espaço
1.4.3.4. Contraste
1.4.3.4.1. O arranjo das diferenças entre elementos opostos
1.4.3.5. Cor
1.4.3.5.1. O uso intencional da cor para transmitir intenção na composição
1.4.3.6. Escala
1.4.3.6.1. O relacionamento entre os tamanhos dos elementos
1.4.3.7. Espaço Negativo
1.4.3.7.1. O espaço vazio, ou "espaço em branco", entre os elementos
1.4.3.8. Hierarquia
1.4.3.8.1. O arranjo do nível de importância dos elementos
1.4.3.9. Tipografia
1.4.3.9.1. O uso e organização da tipografia na composição (com seus diferentes estilos e formatos)
1.4.4. O que é UX
1.4.4.1. Experiência de usuário (ou *user experience*)
1.4.4.1.1. "O conjunto de elementos e fatores relativos à interação do usuário com um determinado produto, sistema ou serviço cujo resultado gera uma percepção positiva ou negativa."
1.4.4.1.2. Não limitado ao design, abrangendo toda a experiência do usuário (por mais que isso pareça redundante)
1.4.4.1.3. É dinâmica, sendo constantemente modificada ao longo do tempo
1.4.4.2. O processo de design da UX varia de acordo com o produto, sistema ou serviço em questão
1.4.4.3. Alguns pontos de interesse do design de UX (mas que não garantem, por si, uma boa UX)
1.4.4.3.1. Eficácia
1.4.4.3.2. Usabilidade
1.4.4.3.3. Performance
1.4.4.3.4. Acessibilidade
1.4.4.4. Exemplo:
1.4.4.4.1. Desenvolvimento de um site
1.4.5. Boas práticas e padrões de UX
1.4.5.1. Padrões preestabelecidos
1.4.5.2. As 10 heurísticas de Jakob Nielsen
1.4.5.2.1. 1. Visibilidade do estado do sistema
1.4.5.2.2. 2. Correspondência entre o sistema e o mundo real
1.4.5.2.3. 3. Liberdade ea controle para o usuário
1.4.5.2.4. 4. Consistência e padrões
1.4.5.2.5. 5. Prevenções de erros
1.4.5.2.6. 6. Reconhecimento em vez de memorização
1.4.5.2.7. 7. Flexibilidade e eficiência de uso
1.4.5.2.8. 8. Estética e design minimalista
1.4.5.2.9. 9. Ajudar a reconhecer, diagnosticar e se recuperar de erros
1.4.5.2.10. 10. Ajuda e documentação
1.4.5.3. Pesquisa
1.4.5.3.1. Qualitativa
1.4.5.3.2. Quantitativa