- đ„ Membres du groupe
- đŻ Objectifs
- đ€ Travail collaboratif
- đ ïž Outils
- đ Principe gĂ©nĂ©ral
- đïž Planning de la semaine
- đ MĂ©thodes de dĂ©bogage employĂ©es
- đïž Typologie des erreurs
- đ Fichiers
- 𧩠Syntaxe
- đĄ Typographie
- đ Logique
- đ„ïž Affichage
- đ§č QualitĂ© du code
- đ§Ș Tests fonctionnels manuels
- đ Bilan et perspectives
| Etudiant.e | Alias | Branche |
|---|---|---|
| Mathilde C. | Clouddy23 | bugfix/mathilde |
| Kamo G. | Spaghette5 | bugfix/kamo |
| Mathieu L. | mathleys | bugfix/mathieu |
| Filippos K. | filkat34 | bugfix/filippos |
- Mobiliser les méthodes de déboggage abordées en classe virtuelle pour rendre une page web fonctionnelle.
- Savoir utiliser le client git et la plateforme Github en vue de collaborer au sein d'une équipe de développement.
- Se familiariser avec la syntaxe Markdown en vue de rédiger la documentation d'un dépÎt distant.
Le principal outil de collaboration utilisé est Github. Nous avons cloné le dépÎt fourni et chaque membre de l'équipe a créé sa propre branche pour pouvoir travailler indépendamment. Nous avons également utilisé Teams pour faire les visios de code review.
La premiĂšre code review nous a permis de repartir grossiĂšrement le travail entre nous en ajoutant dans la rubrique "issues" de Github pour mĂ©moire les bogues dĂ©jĂ repĂ©rĂ©s, commençant ainsi une liste appelĂ©e Ă ĂȘtre progressivement enrichie au fil de notre travail.
Tout en se partageant la résolution des bogues listés et vu l'ampleur restreinte du projet et l'envie de certains de se préoccuper également d'accessibilité et de qualité de code, nous avons décidé de laisser libre cours à chacun de travailler sur sa branche et d'apporter les modifications qu'il juge nécessaires. Une fois son travail fini, chacun fait une demande de tirage pour que les autres puissent en prendre connaissance.
Un travail d'harmonisation est prĂ©vu dans le cadre de la deuxiĂšme code review en visio oĂč l'on discute des propositions de chacun, faisons des tests fonctionnels manuels dans chaque branche pour choisir et amender celle qui devra ĂȘtre fusionnĂ©e avec la branche principale.
| Dates | Objectif |
|---|---|
| 12/10 | Code review n. 1 en visio : lecture collective du code et ouverture d'issues pour mémoire sur Github |
| 13/10-16/10 | Période de débogage en priorité des erreurs assignées au développeur dans sa branche bugfix/nomdudev |
| 17/10 | Code review n. 2 pour discussion autour des pull requests et merge dans main |
| 18/10-19/10 | Finalisation de la rédaction du CR dans le README.md de la branche main |
Pour identifier et corriger les problÚmes, plusieurs méthodes de debug ont été employées :
Ă lâouverture de lâapplication, le navigateur affichait uniquement lâarborescence des fichiers, au lieu de charger automatiquement le fichier index.html. Cette anomalie a Ă©tĂ© attribuĂ©e Ă une erreur dans lâextension du fichier.
Lâinspection du HTML a permis de dĂ©tecter que le contenu attendu entre les balises <body> nâĂ©tait pas prĂ©sent. Cette Ă©tape a mis en Ă©vidence des erreurs structurelles qui pouvaient perturber le rendu de la page.
Lâinspection du rĂ©seau a montrĂ© que seul index.html Ă©tait chargĂ©. Les appels au fichier CSS et Ă Google Fonts ont Ă©tĂ© contrĂŽlĂ©s, rĂ©vĂ©lant des fautes de frappe empĂȘchant le chargement correct du design.
Les fichiers ont Ă©tĂ© examinĂ©s pour vĂ©rifier le nesting des Ă©lĂ©ments, la fermeture correcte des balises et la cohĂ©rence de la syntaxe. LâĂ©diteur VS Code a Ă©tĂ© utilisĂ© pour dĂ©tecter automatiquement les erreurs de syntaxe, les fautes de frappe et les incohĂ©rences dans les fichiers.
La console a signalé des erreurs : fonctions invalides, fautes de frappe, absence de fermetures et erreurs de type. Chaque erreur a été corrigée de maniÚre ciblée, en suivant les messages de la console.
AprĂšs correction, le rendu de la page et du design a Ă©tĂ© validĂ© visuellement. L'horloge a Ă©tĂ© testĂ©e pour vĂ©rifier lâensemble de ses fonctionnalitĂ©s (voir Tests fonctionnels manuels).
GrĂące Ă cette mĂ©thodologie structurĂ©e, combinant inspection manuelle, outils de dĂ©veloppement du navigateur et vĂ©rification automatique via lâĂ©diteur, lâensemble des anomalies a Ă©tĂ© identifiĂ© et corrigĂ©, aboutissant Ă un affichage fonctionnel et conforme au design attendu.
Nous avons établi ci-dessous une typologie des erreurs trouvées avec quelques exemples pour chacune d'entre elles. Il s'agit bien d'une typologie et non d'une liste exhaustive de toutes les erreurs corrigées.
Quelques erreurs ont Ă©tĂ© trouvĂ©es concernant l'extension du fichier index qui l'empĂȘchait de s'afficher correctement ainsi qu'une coquille dans la saisie du chemin du fichier des styles.
| Fichier | Exemple | Solution |
|---|---|---|
| index | index.php | Renommer l'extension incorrecte du fichier en index.html |
| index | asset/css/style.css | Correction de la coquille dans le nom du dossier assets/css/style.css |
De nombreuses erreurs de syntaxe ont été corrigées : oublis de fermeture de balises et d'accolades principalement.
| Fichier | Exemple | Solution |
|---|---|---|
| index | <title>Timetitle> |
Ajout de la balise fermante <title>Timetitle</title> |
| styles | .inside font-weight: bold; font-size: 75px;;} |
Ajout de l'accolade ouvrante et suppression du point virgule en double. Corrigé en .inside { font-weight: bold; font-size: 75px; } |
| script | .setTimeInterval(function(){ ... }, 1000; |
Ajout de la parenthĂšse fermante (et correction du nom de la fonction Javascript) setInterval(function(){ ... }, 1000); |
De nombreuses coquilles typographiques ont été rectifiées : inversions ou oublis de lettres principalement.
| Fichier | Exemple | Solution |
|---|---|---|
| styles | #wrappr{ |
Ajout de la lettre manquante #wrapper{ |
| script | addEventListener('clic', (event) =>... |
Ajout de la lettre manquante addEventListener('click', (event) =>... |
| script | dcument.querySelector('.button') |
Ajout de la lettre manquante document.querySelector('.button') |
Quelques incohérences dans le typage des variables et dans la structuration des fonctions ont été trouvées.
| Fichier | Exemple | Solution |
|---|---|---|
| script | let is_run = "true" |
La variable doit ĂȘtre un bolĂ©en sinon elle sera toujours false. Il suffit d'enlever les guillemets : let is_run = true |
| script | function randomHexColor(x, y) |
La signature de la fonction comporte deux paramÚtres alors que son corps et son appel utilisent trois arguments. Il faut rétablir le troisiÚme au niveau de la signature : function randomHexColor(x, y, z) |
| script | function adjustTimer(timer){(timer < 10 ? '0'+timer : timer);} |
Le return de la fonction a été oublié : function adjustTimer(timer){return (timer < 10 ? '0'+ timer : timer);} |
| index | <div id="wrapper"><div class="inside" id="wrapper"> |
Deux Ă©lĂ©ments dans la structure ont le mĂȘme id qui est censĂ© ĂȘtre unique. Il faut soit renommer l'un des deux ou refactoriser. |
Concernant l'affichage, en plus de nombreuses erreurs typographiques, nous avons constatĂ© une mauvaise utilisation de certaines propriĂ©tĂ©s, notamment de flexbox. Mais une fois ces problĂšmes rĂ©solus, le principal dĂ©fi a Ă©tĂ© de faire en sorte que le bouton qui bascule entre deux formes qui n'occupent pas le mĂȘme espace, ne pousse pas les autres Ă©lĂ©ments du DOM. Nous avons rĂ©ussi Ă faire cela en attribuant au bouton une hauteur et une largeur fixes.
Des optimisations ont été faites au niveau de l'affichage responsive en ajoutant une media query pour les petits écrans.
Nous avons Ă©galement ajoutĂ© des attributs aria-live pour rendre l'horloge plus accessible en avertissant les utilisateurs ayant recours Ă des lecteurs d'Ă©cran des champs susceptibles d'ĂȘtre dynamiquement modifiĂ©s.
Selon les choix des uns et des autres, de nombreuses modifications ont été apportées dans le but d'optimiser la qualité et la lisibilité du code. En voici quelques exemples :
| Optimisation | Description |
|---|---|
| Lisibilité | Dans les fichiers index et styles le code a été mal formaté : pas de sauts de ligne, mauvaise indentation. Nous avons utilisé l'option "Format Document" de VS Code pour rétablir une mise en page lisible |
| Standardisation | Usage de lowerCamelCase pour les variables. |
| DRY | Dans le fichier script le code a tendance à se répéter, notamment concernant les sélecteurs permettant la manipulation du DOM. Nous avons choisi de créer des variables au début du fichier pour les sauvegarder et éviter de les répéter. |
| KISS | Que ce soit au niveau du HTML qui multiplie les <div> ou du CSS qui multiplie les classes, nous avons chosi de refactoriser pour raccourcir et simplifier le code. Par exemple, l'insertion d'éléments dans le DOM via le CSS (les séparateurs) nous a paru le meilleur moyen de complexifier à outrance le code et de le rendre vulnérable aux bogues d'affichage : le CSS est sensible à l'ordre des sélecteurs et multiplier les sources du contenu n'est jamais une bonne idée car cela rend le code plus difficilement maintenable. |
| Accessibilité | Au niveau du CSS nous avons préféré utiliser des mesures relatives (em et non px) ce qui rend l'interface plus flexible et responsive. |
| Documentation | Nous avons également ajouté des commentaires dans notre code afin de faciliter sa maintenabilité. |
| Fonctionnalité/Branche | Mathilde | Kamo | Mathieu | Filippos |
|---|---|---|---|---|
| Pas dâerreur JavaScript dans la console. | â | â | â | â |
| La page affiche lâheure, les minutes et les secondes Ă 00:00:00 au chargement. | â | â | â | â |
| Les sĂ©parateurs (:) sont visibles. | â | â | â | â |
| Lâheure, les minutes et les secondes se mettent Ă jour chaque seconde. | â | â | â | â |
| La couleur du fond change progressivement en fonction de lâheure. | â | â | â | â |
| Cliquer sur le bouton met l'horloge en pause (lâheure nâavance plus). | â | â | â | â |
| Cliquer Ă nouveau sur le bouton relance l'horloge. | â | â | â | â |
| Le bouton affiche âpauseâ quand l'heure tourne et âplayâ quand elle ne tourne pas. | â | â | â | â |
| L'horloge reste lisible et centrĂ©e, sans dĂ©bordement. | â | â | â | â |
| L'affichage de l'horloge s'adapte correctement sur de plus petits Ă©crans (mobile, tablette). | â | â | ||
| Lorsque le bouton bascule entre play/pause, il ne pousse pas les autres Ă©lĂ©ments du DOM. | đš |
đš ImplĂ©mentation partielle et non universelle. Fonctionne correctement sur certains navigateurs (Firefox) mais non sur d'autres. Son fonctionnement dĂ©pend Ă©galement de la taille de la fenĂȘtre du navigateur redimensionnĂ©e (il faudrait sans doute rajouter d'autres breakpoints dans le css).
AprĂšs des tests sur plusieurs navigateurs, la branche bugfix/filippos prĂ©sentait le moins de problĂšmes d'affichage. Nous avons donc dĂ©cidĂ© de la fusionner dans la branche main. Nous n'avons supprimĂ© aucune des branches de dĂ©veloppement afin que le travail de chacun puisse ĂȘtre visible.
Nous avons également suite à cela déployé notre horloge sur la page github du dépÎt distant.
Les objectifs fixés ont tous été atteints. L'affichage de l'application et ses fonctionnalités ont été rétablies conformément aux consignes de l'exercice.
Tous les membres du groupe ont montrĂ© de l'implication dans le travail demandĂ©. Des Ă©changes ont eu lieu, Ă la fois lors des deux visios programmĂ©es sur Teams et rĂ©guliĂšrement sur Whatsapp. Une rĂ©elle entraide sâest manifestĂ©e au sein de lâĂ©quipe. Ă la demande de Mathilde Chauvet, Filippos Katsanos et Mathieu Leyssene ont tous deux acceptĂ© de partager leurs connaissances afin de permettre un approfondissement des compĂ©tences sur GitHub et VS Code.
Tous les membres du groupe maßtrisent les différentes méthodes de déboggage, le client GIT (commit, création et gestion de branches, etc.) et les fonctionnalités de collaboration offertes par Github.
Tout le monde a également pu contribuer dans la rédaction du fichier README du dépÎt et prendre connaissance des particularités de la syntaxe Markdown.
MĂȘme si le projet ne s'y prĂȘtait pas (trop d'erreurs imbriquĂ©es, trop peu de fichiers Ă dĂ©bogguer, dĂ©lai de rendu trop court), le groupe pourrait encore gagner en efficacitĂ© en s'organisant mieux en amont :
- en définissant plus rigoureusement le périmÚtre d'intervention de chacun de ses membres. Cela implique notamment une identification plus précise des bogues, dÚs la premiÚre réunion, et une répartition plus stricte entre développeurs des issues plutÎt que d'en rajouter au fil de l'eau ce qui peut créer des doublons.
- en harmonisant les conceptions que chacun a de la notion de déboggage. Jusqu'à quel point peut-on aller dans l'optimisation et la refactorisation d'un code qu'on juge de mauvaise facture ?