DEV Community: anastacio_dev

Configurando o projeto da melhor API de tabelas de campeonato que você já viu!

anastacio_dev — Mon, 11 Nov 2024 15:12:17 +0000

Assumindo que você já preparou o ambiente, vá até o Spring Initializr e gere um projeto com os parâmetros da imagem abaixo:

Algumas considerações sobre as dependências:

Vou utilizar MongoDB no projeto, pois creio que faz mais sentido dado ao tipo de dado que iremos produzir. É possível utilizar um banco relacional, também. Sinta-se à vontade;
Ainda não vou mexer com Spring Security, pois o foco agora é a solução de negócio. No futuro, vamos trabalhar a parte de autenticação. Se você domina o Spring Security, sinta-se à vontade para decidir baixar isso agora ou não;
Muita gente gosta de usar Lombok para a gestão de getters e setters. Particularmente, não gosto e não vou usar. Sinta-se livre para fazer a sua escolha;
Também não está no escopo atual do projeto lidar com Cloud, conteinerização, orquestração, rastreamento, observabilidade e outras coisas relacionadas a infraestrutura e SRE, por isso não estou baixando nada relativo a esses assuntos. Mais uma vez, sinta-se à vontade para montar a stack que você se sentir confortável.

Uma vez o projeto baixado, unzipado, dependências instaladas e com o "Hello World" rodado, crie os pacotes abaixo:

Se você estiver atento, se lembrará que essas pastas estão batendo com o nosso desenho arquitetural feito em um capítulo anterior, exceto pelo "View", que é o front-end e ainda não trararemos.

Sendo assim, podemos relembrar a utilidade de cada pacote:

Model: onde criaremos os nossos modelos, ou classes de objetos;
Repository: onde ficará a nossa interface com o banco de dados (leia sobre padrão ODM)
Service: onde ficará nossa lógica de negócio, como a geração da tabela e agendamento de jogos, além das validações de dados de entrada e saída;
Controller: onde cuidaremos dos endpoints (ou rotas, URLs, URIs, links) de requisição e resposta. É o que chamamos informalmente de API.

No próximo texto tem código. Eu juro! :)

Prosseguimos!

Preparando o ambiente de desenvolvimento da melhor API de tabelas de campeonato que você já viu!

anastacio_dev — Mon, 11 Nov 2024 14:37:54 +0000

Antes de começar a codar loucamente, preciso confirmar se você tem domínio sobre o preparo do ambiente de desenvolvimento. O objetivo desta série não é entrar nesse assunto, logo:

Ou você tem total domínio das ferramentas necessárias antes de iniciar um projeto Java;
Ou você anota a lista abaixo, pause a caminhada e vá aprender sobre esses assuntos.

Preparar ambiente é chato porque parece que você não está gerando valor (e não está mesmo), mas é o tipo de coisa que você faz uma vez. E com o tempo, passa a ser algo simples de resolver.

Bora pro checklist. Confira se você possui essas ferramentas e conhecimentos:

Lógica de programação básica, como if, while e essas coisas bem básicas;
Particularidades da linguagem Java, como gestão de pacotes com Maven (vou usar Maven aqui, o que não te impede de utilizar outro gerenciador), o arquivo pom.xml, domínio do pacote Jakarta/Javax;
Particularidades do Spring Framework, como a gestão de pacotes Spring dentro do pom.xml, uso do Spring Initializr para gerar os projetos;
Instalação/atualização do JDK na sua máquina. Eu vou usar a JDK 21. Outras versões podem apresentar alguma diferença em alguma funcionalidade, mas qualquer versão da 17 em diante não apresenta mudanças drásticas;
Instalação do MongoDB, que será o nosso banco de dados. caso você queira utilizar um banco relacional, sinta-se livre, mas aqui adotaremos o Mongo por acreditar que se encaixa melhor com o projeto
Uso de alguma IDE para facilitar o desenvolvimento. Eu uso o IntelliJ, mas existem outras opções como Eclispe, VS Code e Netbeans; além de IDEs online, como o Replit. Fique a vontade na sua escolha. É possível desenvolver esse projeto confortavelmente em qualquer uma delas (e com algum nível menor de conforto em outras que não citei aqui), mas não vou entrar nos detalhes de configuração de cada IDE e nem indicar o uso preferencial de nenhuma delas. Qualquer problema ou dúvida, pesquise!
E, por fim, vou assumir que você tem conhecimento em Git e Github. Não é estritamente necessário o uso dessas duas ferramentas, mas é altamente recomendado. Se você não sabe o porquê, então sugiro que pesquise mais sobre elas. Não ficarei dando detalhes sobre como commitar código, administrar branches e outras coisas do tipo.

Se você chegou ao fim desse texto, é porque ou você já tem domínio de tudo isso ou ainda vai procurar preencher alguma lacuna de conhecimento.

De qualquer forma, prosseguimos!

Definindo a arquitetura da melhor API de tabela de campeonato que você já!

anastacio_dev — Sun, 10 Nov 2024 19:57:47 +0000

Disclaimer: Arquitetura é sempre um assunto polêmico. Há quem defenda que tudo isso caberia bem em um JSP e há quem diga que tudo tem que estar em microsservicos. Nem tão ao céu, nem tão ao inferno: optei aqui por um MVC, que creio que atende bem as expectativas. Vale lembrar que o objetivo principal desse projeto é educativo, então não estou considerando os custos e benefícios de qualquer abordagem considerando a exposição dessa solução ao usuário final. Nesses casos, precisaríamos de outras análises, que não cabem aqui.

Daqui pra frente, estou assumindo que você tem conhecimentos suficientes em Java e Spring para prosseguirmos. E dentro da grande caixa de ferramentas que é o Spring, você deve ter se deparado com o Spring MVC.

O Spring MVC pertence ao Spring Framework e implementar aplicações web utilizando a arquitetura MVC.

Assumindo também que você conhece este padrão (caso não conheça, estou deixando links para tudo isso no fim do texto), serei sucinto: a arquitetura MVC divide nossa aplicação em três camadas:

Model (M), onde fica as nossas classes, ou modelos;
View (V), onde fica o nosso front-end. Note que este projeto vai apenas entregar a API. Não pretendemos (ainda) abordar o front-end.
Controller (C), onde os endpoints da nossa API serão expostas.

Abaixo, um desenho arquitetural do nosso aplicativo, utilizando o padrão MVC bem simplificado:

Para os nosso propósitos, vamos adicionar as camadas de Serviço, que vai abrigar a lógica de negócio, deixando o Controller apenas para tratar a exposição dos endpoints; e vamos adicionar uma camada de Repositório, para lidar com a persistência utilizando uma ORM.

Na prática, fica assim:

Acho que no próximo capítulo já podemos começar com ele... O CÓDIGO!

Prosseguimos!

Leituras complementares:

Modelando as classes da melhor API de tabelas de campeonato que você já viu!

anastacio_dev — Sun, 10 Nov 2024 17:38:14 +0000

Se você já estudou nem que seja um pouco de orientação a objetos, sabe que o coração desse paradigma está em classificar objetos. É como separar todos os objetos da mesa de acordo com os seus atributos e funcionalidades.

Classificar — ou modelar classes — também é como criar uma forma que irá pegar o nosso punhado de dados e transformá-los em objetos, cada um com seus atributos e funcionalidades, repito.

Pra facilitar, vamos ao JSON que geramos no último texto:

{
  "nomeCampeonato": "String",
  "equipes": [
    {
      "id": "Integer",
      "nome": "String",
      "localizacao": "String",
      "grupo": "String",
      "subGrupo": "String"
    },
  ],
  "formatoCampeonato": {
    "divisaoPorGrupos": "Integer",
    "grupos": [
      {
        "id": "Integer",
        "nome": "String",
        "equipes": ["Integer"],

      },
    ],
    "turnosDentroGrupo": "Integer",
    "turnosEntreGrupos": "Integer",
    "sorteioGrupos": "Boolean"
  },
  "calendarioConfig": {
    "tabelaOtimizada": "Boolean",
    "totalJogosPorDia": "Integer",
    "diasDescanso": "Integer"
  }
}

Dando uma olhada, é possível ver que o JSON já classifica, de alguma forma, nossos objetos.

Segundo o que está posto, temos:

Uma lista de equipes, o que nos leva um objeto do tipo "equipe";
Um configurador de calendário (esse nome é ruim, mas vamos deixar assim, por hora) que ajusta alguns parâmetros do nosso agendamento de jogos, como quantidade de jogos por dia, período de descanso dos times e a opção de otimização de viagens tratada no nosso primeiro texto
E dentro de um objeto chamado "formatoCampeonato", temos uma lista de grupos. E grupo contém uma lista de equipes. Antes que você confunda a cabeça, essa lista de listas é algo como uma lista (grupo A, grupo B, etc...) sendo que cada item dessa lista também é uma lista.

Grupo A	Grupo B
Palmeiras	Bahia
Cruzeiro	Fluminense
Cuiabá	Grêmio
Paysandu	Náutico

Então, por enquanto temos as seguintes classes mapeadas:

Equipe: contento nome da equipe, localização, grupo e subgrupo;
Grupo: contendo nome do grupo e a lista de equipes que o preenche;
Configurador de calendário (nome bem ruim..., que contém os atributos de dias de descanso para cada equipe, quantidade de jogos por dia e se a tabela será otimizada ou não.

Faltou tratar o objeto formatoCampeonato, que contém dados sobre quantidade de turnos, grupos e se haverá um sorteio de chaves por nossa parte.

Mas bem que poderíamos chamar a classe que forma esse objeto de "Campeonato", não? Afinal, são todos esses dados pertencentes a um campeonato.

E também podemos adicionar a classe tabela. Todo campeonato tem uma tabela de jogos, certo? E é justamente por conta dessa tabela que esse projeto existe.

Logo, podemos definir essa classe:

Campeonato: contendo informações de quantidade de grupos, quantidade de turnos disputados dentro do grupo e contra times de fora do grupo e a tabela de jogos.

A tabela é mais um daqueles casos de lista de listas. A tabela, em si, é uma lista de rodadas. E a rodada é uma lista de jogos.

E se temos uma tabela de jogos, também temos a classe Jogo, que contém um time mandante, um visitante, um local e uma data.

Vamos definir, então, tabela, lista e jogo:

Tabela: lista de rodadas;
Rodada: contento lista de jogos, além do número da rodada;
Jogo: contendo informações de time mandante, time visitante, local e data.

Juntando tudo, segue abaixo todas as nossas classes, seguidas de seus atributos.

Equipe: contendo nome da equipe, localização, grupo e subgrupo;
Grupo: contendo nome do grupo e a lista de equipes que o preenche;
Calendário (mudei o nome), que contém os atributos de dias de descanso para cada equipe, quantidade de jogos por dia e se a tabela será otimizada ou não.
Campeonato: contendo a quantidade de grupos, a lista de grupos, quantidade de turnos disputados dentro do grupo e contra times de fora do grupo e a tabela de jogos.
Tabela: lista de rodadas;
Rodada: contento lista de jogos, além do número da rodada;
Jogo: contendo informações de time mandante, time visitante, local e data.

Abaixo, o diagrama UML representando nossas classes:

Nos próximos textos, podemos começar a implementação. Aqui, usaremos Java e Spring.

Prosseguimos.

Leituras complementares:

Identificando os objetos da melhor API de tabela de campeonatos que você já viu!

anastacio_dev — Sun, 10 Nov 2024 13:25:11 +0000

No último texto, finalizamos com uma ideia solta de como poderia ser os nossos JSONs de entrada e saida.

Fui além e pedi para uma LLM modelar aqueles requisitos em formato JSON, para que as coisas ficassem ainda mais claras. Vamos ver se isso nos ajuda?

{
  "nomeCampeonato": "String",
  "equipes": [
    {
      "id": "Integer",
      "nome": "String",
      "localizacao": "String",
      "grupo": "String",
      "subGrupo": "String"
    },
    ...
  ],
  "formatoCampeonato": {
    "divisaoPorGrupos": "Integer",
    "grupos": [
      {
        "id": "Integer",
        "nome": "String",
        "equipes": ["Integer"],

      },
    ],
    "turnosDentroGrupo": "Integer",
    "turnosEntreGrupos": "Integer",
    "sorteioGrupos": "Boolean"
  },
  "calendarioConfig": {
    "tabelaOtimizada": "Boolean",
    "totalJogosPorDia": "Integer",
    "diasDescanso": "Integer"
  }
}

Vamos entender o que a LLM nos trouxe:

Uma lista chamada equipes, contendo objetos com o nome do time e a sua localização;
Um objeto chamado formatoCampeonato, que que define em quantos grupos os times vão se dividir e nos traz, embutidos, um objeto grupo;
Uma lista chamada grupos, que contém os grupos onde estão organizadas as equipes. Pense que no Brasileirão, por exemplo, teríamos apenas um objeto desses, com os 20 times. Já na Libertadores, teríamos 8 objetos "grupo", com 4 times cada.
Dentro de formatoCampeonato também definimos se, e quantos turnos haverá entre times dentro do mesmo grupo e entre times de grupos diferentes. Lembre que no Paulistão (até 2024), por exemplo, são 4 grupos onde os times jogam um turno contra os times dos outros grupos e não jogam contra os times do próprio grupo.
formatoCampeonato também define se somos nós quem teremos que fazer o sorteio dos grupos ou se o usuário já vai mandar tudo pronto. É por isso que temos os campos de grupo e subgrupo lá no objeto equipes.
E, pra finalizar, o objeto calendarioConfig, que define questões de calendário, como quantidade de jogos por dia, quantidade de dias de descanso que um time deve ter entre um jogo e outro e o nosso "tempero secreto": a otimização de viagens!

Bem, se você já estudou um pouco de orientação a objetos, sabe que esse objetos JSON que modelamos aqui são grandes candidatos a se tornarem as classes do nosso código, certo?

No próximo texto, vamos analisar se cada objeto JSON desses é elegível para gerar uma classe no nosso backend e também vamos falar um pouco da arquitetura do nosso Tabelão.

Prosseguimos.

Analisando os requisitos da melhor API de tabela de campeonato que você já viu

anastacio_dev — Sat, 09 Nov 2024 19:25:44 +0000

Vamos começar escrevendo qual é a ideia:

Receber um conjunto de times e devolver a tabela com todos os jogos entre esses times, as datas das partidas e com a opção da nossa "otimização", que visa reduzir o número de viagens entre os times.

Considerando os requisitos de saída, precisamos ter como entrada não apenas o nome do time, mas outros dados também:

sua localização, para que possamos planejar as viagens;
o modelo do campeonato: serão times em um grupo único, como o Brasileirão? Ou serão times divididos em vários grupos, como a Copa do Mundo?
o campeonato será em turno e returno, turno único, ou algum modelo misto, como a Champions League, onde apesar de um grupo único, não jogam todos contra todos? Ou como a NBA, onde se joga 4 turnos contra os times do seu grupo e até 3 turnos contra os demais times[1]?
se houver a divisão por grupos, somos nós quem vamos sortear que time cai em cada grupo ou o usuário já definiu isso? Vamos dar a opção para o usuário;
o usuário realmente quer uma tabela "otimizada"?. Talvez seja só o campeonato de condomínio, não é mesmo? Vamos oferecer ao usuário a opção de criar uma tabela simples ou uma otimizada, ok?
quantos jogos podemos agendar por dia? Haverá diferenças de limite de jogos por cada dia da semana (tipo, mais jogos aos fins de semana)?
e qual é o intervalo de descanso que um time precisa ter entre uma partida e outra?
E o nome do campeonato, claro.

Nota: Nesta fase, em um projeto real, teríamos que obter esses requisitos com o cliente.

Dada as informações acima, podemos inferir que as entradas do nosso sistema serão:

Entradas:

Um conjunto de equipes e suas localizações
a forma do campeonato ( quantos turnos haverá entre times do mesmo grupo? E contra times dos demais grupos? Aliás, haverá divisão por grupos?
Havendo a divisão por grupos, somos nós quem faremos o sorteio ou receberemos os grupos já definidos?
O usuário quer uma tabela otimizada? Sim ou não?
Total de jogos permitidos por dia
Dias de descanso que um time;precisa ter entre um jogo e outro;
E o nome do campeonato.

E a saída será:

O nome do campeonato
Os grupos (ou o grupo, caso seja um só)
A tabela de jogos, contendo todos os jogos com suas respectivas datas

Aqui já dá pra imaginar dois JSONs, um com os dados de entrada e outro com os dados de saída, certo?

E, pra cada tópico, já dá pra imaginar um objeto, ok?

E como objetos sempre nos levam a falar de classes, então já estamos bem perto dele... O código.

Assuntos para o próximo texto. Prosseguimos.

[1] Por curiosidade, entenda o regulamento da NBA com esse texto no blog deles.

Porque eu estou criando a melhor API de tabela de campeonato que você já viu

anastacio_dev — Sat, 09 Nov 2024 17:43:12 +0000

Uma conversa sobre as motivações e as regras de negócio, para contextualizar o leitor

Uma coisa que me encanta desde criança são tabelas de campeonatos. Sempre fiquei doido com a ideia de conseguirem fazer com que 20 times jogassem todos contra todos, sem repetições, e tudo batia perfeitamente.

Me lembro, desde criança, rabiscando em papel cruzamentos de jogos e tentando fazer a coisa dar certo. Eu era uma criança estranha, eu sei.

Mas mal sabia eu que aquele era o meu primeiro contato com algoritmos... Quem diria.

Cresci, e na adolescência, conheci a NBA. E então a minha mente explodiu! Trinta equipes, divididas em seis grupos jogando entre si, jogando contra adversários dos outros grupos, confrontos que poderiam se repetir até quatro vezes... E o pior: tudo isso, 82 jogos para cada time, tinham que ser jogados em seis meses. Isso dá por volta de 14 jogos por mês: jogo dia sim, dia não.

Se você acha o calendário do futebol brasileiro maluco, tem que conhecer a NBA, meu parça. Jogar em dias seguidos (o famoso e infame "back-to-back") é coisa comum.

Só que nessa bagunça, algo me pegou: os times costumam fazer o que chamamos de "trips", que são sequências de jogos fora de casa, objetivando aproveitar ao máximo as viagens.

Imagine, por exemplo, o New York Knicks. Uma viagem ida e volta para Los Angeles, para enfrentar os Lakers, Estamos falando de 4 mil quilômetros, ou 6 horas pra ir, e mais 4 mil quilômetros pra voltar. Isso equivale a uma viagem entre Porto Alegre e Belém do Pará, pra você ter ideia.

Imagine então que temos não apenas os Lakers em Los Angeles, mas também os Clippers. E ainda os Warriors em São Francisco e os Kings em Sacramento. Seriam quatro viagens cansativas à California!

Mas, na NBA, essas viagens repetitivas são evitadas ao máximo. Os Knicks iriam à LA uma vez e jogaria contra os 4 times de uma vez só. Uma semana corrida, cansativa, tendo em compensação o alívio de não precisar voltar mais à Cidade dos Anjos, a menos que tenha que disputar a final do campeonato por lá.

Imagina a complexidade disso! Trinta times espalhados por todo o território dos EUA (29, na verdade, porque temos o Toronto Raptors. Isso mesmo, um time canadense na liga!) e a necessidade de fazê-los todos cruzarem esse país continental e dar a todos — equilibradamente, por questões de isonomia — o ônus e o bônus das longas viagens para enfrentar os adversários mais longínquos?

Por exemplo: quando os Knicks forem a Los Angeles enfrentar os Lakers, os demais times da California, citados anteriormente, precisam estar ali por perto para receberem os nova iorquinos naquela semana. Não pode acontecer de os Clippers estarem viajando pelo Texas, os Warriors pela Costa Leste e os Kings pela região de Chicago.

Tudo tem que se encaixar. Não basta um simples cruzamento como o que acontece no Brasileirão, por exemplo.

Daí surgiu o comichão: como criar um algoritmo que, dado um número de equipes e sua localização, consiga agendar essas viagens longas e partidas consecutivas fora de casa, fazendo essa otimização logística?

Nisto consiste o projeto Tabelão. Quando finalizado, nossa API vai receber um número de times, sua localização, mais algumas especificações que trataremos em outros textos, e vai devolver uma tabela completa de uma temporada, com a otimização logística de viagens, tentando aproveitar ao máximo as viagens longas que um time fará.

Obviamente que o campeonato do condomínio, por exemplo, não precisa desse nível de otimização. Por isso que não encontrei essa funcionalidade em nenhum gerador de tabelas de campeonatos nas lojas de aplicativos para celulares.

Aliás, antes de iniciar, precisamos alinhar expectativas:

Isto não é um SaaS. (Não ainda, pelo menos, rsrs) Logo, não estou me preocupando com MVP, validações com clientes, precificação, demandas comerciais e outras questões de negócio. A conversa aqui é técnica. Desde ferramentas e design patterns até algoritmos de machine learning que poderemos utilizar para alcançar a solução. Tudo aqui é perseguindo fins educacionais.
Se, no fim, tudo ficar muito bom e aparecer um comprador, também não reclamo. Vamos conversar, hehehe.
E eu acredito que esse estudo teria grande valia para resolver problemas mais "mundanos", como roteamento de transporte de cargas, por exemplo. Quem sabe este não seria um bom spin-off do Tabelão?

Isto posto, vamos aos próximos capítulos.

Prosseguimos.

Leitura adicional: saiba mais sobre a complexidade do quebra cabeça que é o calendário da NBA lendo esse post do blog Bola Presa

8 coisas que existem dentro de um CRUD (pelo menos)

anastacio_dev — Sun, 25 Feb 2024 22:12:59 +0000

Esse post pode ser considerado básico para alguns, mas existem pessoas que querem aprender e nem sabem por onde começar ou quais termos pesquisar. Esse post é pra você.

O que é um CRUD?

CRUD é o conjunto de operações básicas do mundo dev. É o acrônimo para Create (criar), Read (ler), Update (Atualizar) e Delete (deletar) dados.

Um CRUD é a alma de qualquer sistema. Não interessa a IA quântica das galáxias que você usar. Se você quer registrar usuários, operações, compras, pedidos, postagens, comentários e qualquer outra coisa, o CRUD estará lá.

Logo, saber lidar com um CRUD é um ótimo primeiro passo para quem quer aprender backend. Se você sabe fazer um CRUD, você já deu o primeiro passo.

Mas, no mundo real, um CRUD é muito mais que automatizar queries SQL para controlar o que entra e sai de um banco de dados. E este texto é sobre isso. Vamos dar uma olhada em pelo menos 8 coisas que tem dentro de um CRUD?

O que tem dentro de um CRUD, afinal?

1. Autenticação

A autenticação é como o porteiro do prédio. "Cara, crachá!" para saber quem pode ou não ter acesso as operações do CRUD.

Você pode depositar um valor na minha conta bancária, mas não pode sacar, não é mesmo?

A autenticação cuida de quem pode operar cada uma das operações CRUD. Um administrador do sistema pode muito mais do que um simples leitor, certo?

O assunto aqui é SEGURANCA!

Pesquise sobre "como funciona autenticação na linguagem ou framework X". Cada uma dessas linguagens tem suas próprias ferramentas e padrões de autenticação.

2. Integração

É aqui que cuidamos das famosas APIs, ou Interfaces de Programação de Aplicações.

Toda vez que você usa dados ou algoritmos que não estão em seu poder, você integra uma ferramenta externa via API. Desde um algoritmo de processamento de dados no Python até uma ferramenta de pagamento do PagSeguro no seu e-commerce.

O segredo aqui é fazer com que duas coisas diferentes se encaixem harmonicamente. E, para isso, existem diversos padrões, como REST, gRPC, GraphQL, entre outros.

Linguagens costumam ter frameworks que abstraem a parte difícil, mas é indispensável entender coisas como protocolos HTTP, por exemplo.

Pesquise por "Como minha linguagem lida com":

REST
GraphQL
gRPC
Protocolos HTTP

3. Persistência

Persistir dados não é nada mais que salvar essas dados em um banco.

Assim como tudo em programação, boas almas do Senhor já deixaram meio caminho andado com seus frameworks, mas eu desafio você a tentar usar o Spring JPA, por exemplo, sem ter sólidas noções de modelagem de banco de dados...

Falo por mim: tive que dar uma boa revisitada em conceitos tidos como básicos para saber onde e quais dependências injetar (e já vamos falar sobre "dependências").

Então, a primeira coisa a pesquisar são os tópicos básicos em banco de dados, depois sim, pesquise sobre frameworks.

Modelo entidade-relacionamento
SQL
SQL x Bancos NoSQL
SGBDs e suas diferenças
Como a minha linguagem lida com ORMs
Como a minha linguagem lida com Migrations

4. Padrões de Projeto (ou Design Patterns)

Sem querer falar mal, mas se Javascript foi sua primeira linguagem, pode ter sido que você tenha aprendido que basta escrever toda a sua lógica dentro do arquivo "script.js" e tudo funcionará.

E funciona mesmo. Mas a que custo!

Quando for necessário corrigir um bug ou inserir uma feature, você não vai querer varrer um arquivo de quatro mil linhas, escrito por outra pessoa, sem saber se é aquela linha com o comentário "apagar" que está sustentando todo o sistema em pé.

É para salvar nossas vidas que os padrões de projetos existem. MVC, MVVM, Factory, DTO são apenas alguns deles.

Se quiser ir além, pode pesquisar também sobre arquitetura de software, para entender o que são coisas como DDD, Event Driven, Arquitetura em pipeline, camadas, microkernel, microsservicos... Para um iniciante, basta saber que esses termos existem, para você não ficar boiando nas discussões "do Olimpo" entre os seniores. Não se preocupe tanto em aprender as minúcias, por enquanto.

Padrões de projetos utilizados na minha linguagem.

5. Dependências

Como tenho repetido por todo o texto, muitas das soluções que utilizamos no nosso código não são nossas. E todo o código que emprestamos de alguém é uma dependência.

E sobre dependências, duas coisas são importantes: o gerenciamento e a injeção.

Gerenciar dependências, na prática, é um arquivo que funciona como um caderninho onde anotamos todo o código que é emprestado. Com o detalhe de que seu código não reconheceria uma função de uma dependência que não estivesse anotada lá.

Já a injeção de dependências é a forma como você insere o código de uma biblioteca alheia dentro do seu. Importante entender como cada linguagem resolve isso.

Gerenciamento de dependências na minha linguagem
Injeção de dependências na minha linguagem.

6. Testes

O mundo dos testes é gigante e da pra escrever textos inteiros sobre. Mas creio que, para o início, basta entender o que são testes unitários, testes de integração, sua importância e como a sua linguagem lida com isso. Sempre há frameworks e bibliotecas que adiantam nosso trabalho.

Testes unitários
Testes de integração
Ferramentas e frameworks de testes para a minha linguagem

7. Regras de negócio

O que difere um CRUD do outro são as regras de negócio. Todo sistema existe, e só existe para atender uma necessidade. Cadastrar usuários, produtos, pedidos, entregas... E para cada negócio, as regras mudam.

Em uma rede social, por exemplo, eu posso ver o que os meus colegas estão postando. Mas, em um banco, eu poderia ver quanto dinheiro eles estão depositando?

Regras de negócio precisam atender as especificações não apenas do tipo negócio, clientes, usuários, mas da legislação vigente em cada pais, por exemplo. Alguns filmes classificados como "livres" no Brasil sequer podem ser exibidos em países árabes. Como será que a Netflix lida com isso?

E também tem a questão de coisas que só existem em localidades especificas, como o PIX ou os endereços doidos de Brasília, por exemplo.

8. Infraestrutura

Uma vez escrito, onde seu CRUD vai rodar? Se for pra rodar só na sua máquina, então tá tudo certo.

Mas se tiver que rodar em rede, você vai precisar de ferramentas como Docker, para "containerizar" seu código; Kubernetes, para orquestrar esses contêineres e entender sobre Cloud e qual cloud você pretende utilizar. Além de git e github, para manter os ciclos de integração e entrega, o famoso CI/CD.

Mas uma vez: vá aos poucos. Para fazer o básico aqui, o básico já basta.

Git
Github
Docker
Kubernetes
Cloud
CI/CD

Conclusão

Quando ouvimos "é só um CRUD", podemos partir de algo bem simples, como um código que lê algo do console e salva em um banco de dados até um backend robusto.

Meu primeiro CRUD na vida foi um código VBA que lia algumas coisas numa "msgbox" e salvava dentro de uma planilha. Simples assim. Mas o caos em que aquilo se tornou me fez entender a necessidade de muitos dos conceitos que apontei nesse texto.

Creio que este pode ser um bom guia para iniciantes. Nenhum assunto aqui foi esgotado. Dá pra se aprofundar em muitas coisas. Mas creio que esse seja um bom início.