3d-interface-rapport/rapport/conclusion.tex

\part*{Remerciements}
Je tiens particulièrement à remercier \\

\begin{itemize}
    \item Vicent \textsc{Charvillat}, pour m'avoir donné l'occasion de faire un
        stage intéressant, et pour toute l'aide qu'il a pu me fournir
    \item Geraldine \textsc{Morin}, pour sa disponibilité
    \item Axel \textsc{Carlier}, pour son aide sur les points plus techniques
    \item Wei Tsang \textsc{Ooi}, pour ses suggestions souvent pertinentes
\end{itemize}

\paragraph{}
mais je me dois aussi de remercier \\

\begin{itemize}
    \item Thierry \textsc{Malon} et Émilie \textsc{Jalras}, pour avoir joué le
        rôle de canard en plastique \footnote{\emph{La méthode du canard en
        plastique consiste à expliquer méticuleusement le code source que l'on
        a écrit à un collègue, à un simple passant, ou même à un objet inanimé
        comme un canard en plastique. Le simple fait d'exprimer ses pensées à
        voix haute est censé aider à trouver les erreurs de programmation.
        Comme les réactions de l'interlocuteur ou son niveau de compréhension
        du problème n'ont aucune importance dans ce processus, on peut le
        remplacer par un canard en plastique.} --- Contenu soumis à la licence
        CC-BY-SA 3.0 (\url{http://creativecommons.org/licenses/by-sa/3.0/deed.fr})
        Source : Article Méthode du canard en plastique de Wikipédia en
        français
        (\url{http://fr.wikipedia.org/wiki/M\%C3\%A9thode\_du\_canard\_en\_plastique})}.
        et plus encore,
    \item Julien \textsc{Fayer}, qui nous a accompagné durant les derniers mois
        de nos stages
    \item Bastien \textsc{Durix},
    \item Vincent \textsc{Angladon},
\end{itemize}

\newpage
\part*{Conclusion}
Peu avant ce stage, nous avons eu le projet long qui nous a permi
d'expérimenter les projets d'envergure en groupe, et la façon dont on devait
les gérer.

\paragraph{}
Ce stage, pendant lequel j'ai développé le programme (\emph{plus ou moins})
seul m'a permi de compléter les expériences que j'avais eu lors du projet long.
En effet, la plupart des projets étudiants à l'ENSEEIHT sont de très petite
taille (si l'on devait passer 35h par semaine sur ces projets, je crois qu'il
n'y en aurait pas un qui durerait plus de trois jours), et on ne se rend en
fait pas compte que certaines des techniques de gestion de projet que nous
avons du mettre en application pendant le projet long sont tout aussi
importantes dans le cas d'un projet seul.

\paragraph{}
Dès nos premiers cours à l'ENSEEIHT, on nous enseignait l'importance des
commentaires qui rendaient compréhensible un programme à quelqu'un d'autre, ou
parfois, à soi-même mais dans le futur. Mais sur un projet de quelques jours,
il est évident que l'on comprendra toujours ce qu'on a fait avant. Cependant
dès que le projet devient suffisament important, on se rend compte qu'il est
impossible de maîtriser parfaitement le code d'un bout à l'autre, et que c'est
là que les commentaires prennent tout leur sens.

\paragraph{}
Ce projet a été très agréable pour moi, puisqu'il m'a permi de me consacrer à
temps plein, et pendant une longue durée, sur un programme qui part de zéro.
Lors d'un projet en groupe, ou d'un sous-projet qui permet de constituer une
brique d'un plus gros bâtiment, on peut ressentir la fierté d'avoir participé à
un si grand projet, mais il y a aussi cette sensation qu'au final, l'impact que
l'on a eu sur ce projet n'est pas si grande que ça. Lors d'un projet fait seul
(ou en petite équipe), et qui part de zéro, on voit le programme grandir au fur
et à mesure, ses fonctionnalités s'améliorer, ses bugs se corriger et de
nouveaux apparaître, et regarder le projet une fois terminé est nettement plus
flatteur pour l'ego.