Olá, Julia. Como vai?
Parabéns pela resolução do desafio! A sua proposta demonstra que você compreendeu perfeitamente os pilares do Pensamento Computacional, especialmente a Decomposição (ao separar os dados em entidades lógicas) e o Reconhecimento de Padrões (ao estruturar a repetição com o loop).
A sua abordagem para a regra de negócio foi excelente. Na vida real, estipular uma margem como 80% do tempo total é uma ótima prática de engenharia, pois previne que um participante perca o e-mail de agradecimento apenas por ter tido uma queda rápida na conexão de internet ou por ter entrado alguns minutinhos atrasado.
Para agregar ainda mais valor ao seu algoritmo e expandir o seu raciocínio lógico, trago duas sugestões importantes de boas práticas e refinamento:
1. Cuidados com o Nome das Variáveis no Loop
No seu bloco de código, você buscou os dados do relacionamento entre a live e os espectadores:
$viewers = $liveViewersModel->getViewers($liveId);
Como essa variável $viewers armazena os registros vindos da tabela Live Viewers, cada item dentro do seu foreach representa, na verdade, o vínculo de visualização daquele espectador com a live específica.
Para deixar o seu código mais legível para outras pessoas desenvolvedoras do time, uma boa prática é nomear a variável do loop refletindo esse papel de histórico ou registro. Veja como o código ganha clareza:
foreach ($viewers as $viewerHistory) {
if ($viewerHistory->watchTime >= (0.8 * $live->totalTime)) {
sendEmail($viewerHistory->viewer_id, $live->id);
}
}
2. Escalabilidade (Otimização do Processo)
O seu algoritmo funciona perfeitamente para um evento com poucas pessoas. No entanto, se a transmissão ao vivo tiver 10.000 participantes, o seu código vai tentar disparar 10.000 e-mails sequencialmente de dentro do loop foreach. Isso pode travar a execução do sistema por falta de memória ou estourar o tempo limite do servidor (timeout).
Como boa prática para algoritmos de automação desse tipo, existem dois caminhos muito comuns no mercado:
- Filtragem direto no Banco de Dados: Em vez de trazer todos os usuários para a memória do código e testar a condição do
if um por um, podemos pedir para o banco de dados entregar apenas os IDs de quem assistiu mais de 80%. - Filas de Processamento (Queues): A função
sendEmail não deve enviar o e-mail na hora. Ela deve apenas jogar o ID do participante em uma "lista de tarefas" (fila), para que outro processo em segundo plano faça os envios aos poucos, sem sobrecarregar a aplicação.
O seu desenho das tabelas e a construção da lógica estão no caminho certo para uma desenvolvedora júnior de sucesso. Continue exercitando essa capacidade de transformar problemas do mundo real em estruturas de dados e códigos organizados!
Espero que possa ter lhe ajudado!
