Add Codificação do prototipo

This commit is contained in:
Leonardo Murça 2024-03-18 17:03:24 -03:00
parent ac51384b12
commit a1a83da273
2 changed files with 52 additions and 3 deletions

BIN
images/gitflow.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

View file

@ -87,7 +87,7 @@ de Aula.
\end{figure} \end{figure}
\vfill \vfill
\cleardoublepage \cleardoublepage{}
\begin{figure}[ht] \begin{figure}[ht]
\centering \centering
@ -96,6 +96,55 @@ de Aula.
\end{figure} \end{figure}
A estrutura lógica das telas prototipadas foram baseadas no sistema \textit{Google Classroom} visando A estrutura lógica das telas prototipadas foram baseadas no sistema \textit{Google Classroom} visando
a facilidade de uso por parte dos usuários, uma vez que a ferramenta é bem difundida no ambiente acadêmico do a facilidade de uso por parte dos usuários, uma vez que a ferramenta é bem difundida no ambiente acadêmico do IFMG\@.
IFMG.
\subsection{Codificação do protótipo}
Após a prototipação das telas principais, iniciou-se o desenvolvimento da aplicação utilizando uma abordagem proposta
por \textit{Andrew Hunt} e \textit{David Thommas} em seu livro \textit{O Programador Pragmático} chamada de \textit{Projéteis Luminosos}.
Essa abordagem é uma analogia à atiradores de armas de fogo que utilizam projéteis luminosos. Esses projéteis são carregados a intervalos
no pente de munição com as balas comuns. Quando disparados, seu fósforo se acende e deixa uma trilha pirotécnica da arma até o que quer
que atinjam. Se os projéteis estiverem atingindo o alvo, as balas comuns também estarão. O feedback é imediato e, já que eles operam no
mesmo ambiente da munição real, os efeitos externos são reduzidos.
Os projéteis luminosos no contexto do desenvolvimento do IF Salas foi necessário para validar como certos fluxos, antes prototipados
no Figma, funcionariam na prática. Essa abordagem foi escolhida pelo fato do IF Salas ser algo que nunca foi construído e utilizado
anteriormente no contexto do IFMG Sabará. Ou seja, alguns requisitos pareciam ainda um pouco obscuros e, não tinhamos uma ideia clara
de como o sistema funcionaria na prática. Mesmo que \textit{Google Classroom} tenha sido utilizado anteriormente em alguns contextos,
a ferramenta ainda era de propósito geral, e certos fluxos comuns não foram cobertos pela ferramenta, como por exemplo todo o fluxo
de criação, atribuição e correção de atividades interdisciplinares.
A arquitetura e organização dos arquivos do código do projeto foi estruturada seguindo as práticas mais difundidas no mercado de
desenvolvimento web utilizando o ecossistema React. Dentre essas práticas estão:
\begin{itemize}
\item Modularização das pastas do projeto por agrupamento lógico. Exemplo: arquivos utilitários ficam em uma pasta chamada utils;
\item Convenções de nomes de arquivos. Exemplo: arquivos de estilos nomeados como styles.js;
\item Context API para gerenciamento de estado global;
\end{itemize}
Em relação à manutenção e versionamento de código, foi adotada a metodologia Git Flow com adaptação ao contexto do IF Salas.
O Git Flow é uma metodologia de desenvolvimento de software baseada em Git que define um conjunto de regras e práticas para
gerenciar o fluxo de trabalho de uma equipe de desenvolvimento. Essa abordagem é baseada em dois ramos principais: master e develop.
O ramo master contém o código em produção, enquanto o ramo develop é usado para integração contínua e desenvolvimento de novas funcionalidades.
Além desses ramos principais, o Git Flow introduz outros tipos de ramos, como ramos de feature, release e hotfix, cada um com sua
função específica dentro do ciclo de vida do desenvolvimento.
Os ramos de feature são criados a partir do ramo develop e são usados para desenvolver novas funcionalidades ou melhorias no código.
Uma vez concluído o trabalho na feature, ela é mesclada de volta ao ramo develop. Os ramos de release são criados a partir do develop
para preparar uma nova versão do software para implantação em produção. Após testes e ajustes finais, o código da release é mesclado
ao master e ao develop. Por fim, os ramos de hotfix são criados a partir do master para corrigir problemas críticos em produção, sendo então
mesclados tanto ao master quanto ao develop.
Entretanto, houve uma adaptação da metodologia Git Flow para o contexto IF Salas, sendo ela a não utilização dos ramos hotfix e release,
uma vez que não houve a implantação do software em ambiente de produção. Observe o diagrama abaixo:
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{gitflow.jpg}
\caption{Git Flow Adaptado}
\end{figure}