Add Codificação do prototipo
This commit is contained in:
parent
ac51384b12
commit
a1a83da273
2 changed files with 52 additions and 3 deletions
BIN
images/gitflow.jpg
Normal file
BIN
images/gitflow.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 98 KiB |
|
@ -87,7 +87,7 @@ de Aula.
|
|||
\end{figure}
|
||||
|
||||
\vfill
|
||||
\cleardoublepage
|
||||
\cleardoublepage{}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
|
@ -96,6 +96,55 @@ de Aula.
|
|||
\end{figure}
|
||||
|
||||
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
|
||||
IFMG.
|
||||
a facilidade de uso por parte dos usuários, uma vez que a ferramenta é bem difundida no ambiente acadêmico do 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}
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue