	A	B
1	Liste "in progress" de choses à faire ou vérifier systématiquement à avoir en tête pendant le développement, pour améliorer la qualité globale du code livré
2	N'hésitez pas à suggérer des précisions ou de nouvelles vérifications à faire pour compléter cette liste et améliorer la qualité livrée.
3
4	Mots clefs	Description
5
6	CONCEPTS GENERAUX TOUT AU LONG DES DEVELOPPEMENTS
7	Finition, qualité	La finition et la qualité sont plus importantes que la vitesse
8	Factorisation	Factoriser quand c'est possible et souhaitable (si cela complexifie trop le code et/ou que ça impacte d'autres modules, il faut en débattre)
9	Performances	Penser performance. Vous développez en test avec 3-4 jeux de données mais quel volume représentera ce jeu de données dans 1 mois, 1 an, 5 ans ? Tout ce qui est consommateur de ressources et répétitif doit faire l'objet de notre attention pour soit être repensé, soit utiliser le deamon en arrière plan.
10	Simple	KIS (Keep It Simple) > La solution la plus simple est toujours la meilleure > Simple != simpliste > Plus une méthode est unique, plus elle est facile à lire, plus elle sera facile à déboguer > On utilise la force de l'équipe pour valider/chercher des solutions.
11	Réutilisation des codes	DRY (Don’t Repeat Yourself) > Par extension dans notre équipe DRO (Don’t Repeat Ourselves) > Toujours chercher à utiliser une technique, une fonction,, une classe, une manière de faire existante. Demander à un collègue plus expérimenté s'il sait. Si l'existant n'est pas satisfaisant le remonter (me contacter) et on en discute.
12	Inutile	Au-delà de KIS > YAGNI (You Aren’t Gonna Need It) > Tout ce qui n'est pas indispensable est à supprimer à priori > Il y a 1000 façons de coder une fonctionnalité nous recherchons la plus simple avec le moins de dépendances possibles (js, librairies etc...) et la plus performante possible en terme de ressources.
13
14	SQL
15	Indexation	Optimisation des tables au fur et à mesure, créer les indexs selon les requêtes sur les tables. Voir le nommage particulier des index dans des tables existantes. => ne pas créer systématiquement des index, essayez d'utiliser l'existant, les index étant chargés en RAM, une surabondance peut plomber les performances globales. Ca vaut le coup d'en parler si vous avez un doute.
16	Suivi structure BDD	Reporter toutes les créations et changements de BDD dans divers/Hightekers.sql
17	Préparation MEP	Fournir toutes les requêtes sql (ajouts/modif...) prêt à l'usage pour la mise en production (MEP) dans le répertoire upgradeFromMaster/ (le créer si n'existe pas) et dans un fichier + changements JS README.md
18
19	TESTS ET PULL REQUEST
20	Tests réels	Bien réfléchir aux données de tests, très souvent on "s'enferme" pendant le développement dans des tests avec un jeu de données biaisées qui nous arrange pour le développement. Il faut absolument créer des jeux de données réelles pour les tests.
21	Tester ' et caractères spéciaux	Dans les champs
22	Tests complets	Tester l'intégralité des fonctionnalités de votre module pendant le développement régulièrement et avant livraison.
23	Tests complets croisés	Faire tester par un autre développeur avant livraison.
24	PULL REQUEST	Toujours merger le master avant de faire une PR et repouisser et contrôler ses PR régulièrement pour voir si elles sont mergeables. Si elles ne sont mergeable il faut régler les conflits et repousser.
25
26	CODE
27	Documentation et commentaires	Commenter, commenter même si c'est ce qui paraît évident. Pour les méthodes, utilisez les fonctionnalités de PHPStorm pour créer des commentaires standard PHPDOC et complétez les,
28	Merge	Pas de merge de 2 branches entre elles autres que MASTER et PREPROD
29	Rester strictement dans l'objet de la branche	Pas de modification ou bugfix/correctifs en dehors du sujet de la branche courante > Nouvelle branche depuis master > PR > Et on pull soit cette nouvelle brancher soit le master si ça été mergée.
30	Merger le master souvent dans votre branche	Merger origin/master plusieurs fois par jour dans votre branche courante.
31	Scripts sensibles	Dès que l'on touche à quelque chose de sensible, surtout les calculs (exemple include/model/comptes_consultants.inc.php fct maj_totaux_compte_consultant ou le deamon). Faire relire et vérifier au moins 3 fois la validité du calcul.
32	Toute modification update/insert	update/insert modifiés > vérifier, pointer les champs (manquent-il des champs),
33	Typer les variables dans les fonctions	exemple func(int $one):array {} ou func(int $one):nom_objet {}
34	Restreindre les colonnes	Dans les fonctions du manager ->get, ->update > préciser les champs voulus dans un tableau en paramètres ! Systématiquement.
35	Simplifier manager	Pas de fonction additionnelle dans les managers si pas indispensable.
36	Textes interfaces	Faire bien attention aux textes destinés aux users : Style, simplicité, didactique, orthographe.
37	Entities	Tous les attributs value des champs de form avec des valeurs provenant soit de l'utilisateur, soit de la base, doivent être protégés par la fonction entities()
38	Relecture	Relecture du code à la fin de chaque cycle (exemple fin d'un module).
39	Comparer	Revoir tous les changements par rapport au master avant la pull request.
40	Recomparer	Refaire lire le différentiel votre branche VS master à un autre développeur pour avoir son retour.
41
42	AFFICHAGES
43	Tableaux	Bien vérifier formatage des nombres et alignements dans les colonnes des tableaux (CF autres pages existantes) => la plupart du temps, nombres alignés à droite et textes à gauche
44	Listes	Pour chaque ajout de paramétres à une liste, il faut qu'ils soient pris en compte aussi dans le download xls
45	Défauts visuels	Vérifier les défauts visuels même mineurs, les noter s'ils ne sont pas traîtés immédiatement et les corriger.
46	Responsive	Tester le responsive
47	Protéger l'affichage	Tous les affichages de textes sur le navigateur doivent être encadrés par la fonction entities()
48
49	ERREURS & LOGS & DEBUG
50	Nettoyer	Vérifier les notices et warning et les traîter. Application web : tail -f apachelog/hightekers.process-id.com-error_log, Daemon : tail -f /project/htkd.log
51	Supprimer debugs	Chercher et supprimer debugvar, var_dump, print_r, error_log, ecrit_log, code mort de partout.