Déjà bravo pour vos projets, je vous souhaite à tous un bon courage pour la suite :)

Voici donc quelques remarques générales qui complète les remarques individuelles que vous avez reçu. Les points sont mit en vrac, lisez ce qui vous concerne et ce qui vous intéresse. Je suis à disposition si vous avez des questions.

Relisez les différents chapitres abordés lors de la revue de mi-projet en fonction des remarques sur votre project : https://github.com/HE-Arc/slides-devweb/wiki/[Django-2020---2021]-Revue-de-mi-projet

Respectez PEP 8 (convention pour écrire du code en Python)

Il existe des packages permettant de corriger la plupart de votre code automatiquement afin qu'il respecte le standard PEP 8 (ex. autopep8)

Evitez les Select N+1

Django met en place des systèmes afin d'éviter cela. Lisez les chapitres concernant les méthodes select_related() et prefetch_related() dans la doc de Django cela pourrait vous être très utile si vous veniez à faire des projets plus conséquent

Stockage des JWT

Ne stockez pas les JWT dans le session storage, c'est le pire compromis que vous puissiez avoir. Session non persistente et les JWT ne sont pas stockés de manière sécurisée. Vous devez choisir parmi l'une des 3 solutions suivantes :

1. Vous n'utilisez pas les JWT et vous trouvez une autre solution.
2. Vous stockez les JWT dans le local storage, non sécurisé, mais persistent.
3. Vous utilisez des cookies sécurisés (httpOnly, etc.), comme ça c'est sécurisé et les sessions sont persistentes.
   • Le meilleur compromis pour vous, c'est de les mettre dans le local storage (projet étudiant)
   • Dans le cadre d'une entreprise, c'est les cookies ou trouver une autre solution (grand projet / pro / prod)

Responsiv design et mobile first

Beaucoup de groupes ont réalisés des apps responsives et c'est une très bonne pratique, certains groupes ont également pensés au mobile first et c'est bien également. Je me permet de vous rappeler que mobile first, ne veut pas dire mobile only. Un design responsiv est un design qui s'adapte à toutes tailles d'écrans et non pas un design qui est supporté ("utilisable") par toutes les tailles. Supporté par toutes les tailles est une première étape. Mais pour avoir un design responsive, il faut que votre site soit adapté et intuitif à utiliser sur la plateforme de l'utilisateur. Le desktop n'a pas les mêmes exigences que le mobile ou que la tablette. Un desktop veut dire grand écran, beaucoup d'espace, il faut donc l'utiliser et répartir les éléments en fonction et profiter de cet espace afin de rendre l'utilisation desktop agréable et intuitive. Un mobile veut dire un petit écran, il faut donc réorganiser les éléments pour qu'ils fonctionnent également bien à cette échelle. Ce n'est pas très grave et le principal c'est d'avoir penser au mobile, ce que la plupart des groupes ont fait. Mais pour aller au bout de la démarche, comprenez qu'un design responsive ne veut pas dire que votre site est "utilisable" sur différentes tailles, mais véritablement pensé et créé pour fonctionner de manière intuitive sur les différentes tailles.

CITEZ VOS SOURCES

A partir aujourd'hui et pour le restant de votre vie, CITEZ VOS SOURCES ! ...merci... Prenez sérieusement l'habitude de citer vos sources tout le temps ! C'est un must have. Que cela soit d'une source en ligne ou d'un autre groupe (ApiRequester à tout hasard :) ). Sinon on commence à avoir des doutes et du coup on pénalise rapidement. En entreprise, cela n'est pas un comportement acceptable.

Migrations Django

Certains groupes n'ont pas bien saisi comment elles fonctionnent, les migrations Django sont très différentes de celles de Laravel. Dans Django, vous modifiez les modèles et ensuite vous créez simplement une migration avec une commande "python manage.py". Les migrations Django s'accumulent, il ne faut en principe pas les supprimer une fois push et utilisées par d'autres personnes (prod ou dev) car cela voudrait dire que les autres devront reset leur DB (voilà une bonne raison d'avoir des seeders).

Seeders

En Django, vous avez 2 solutions, seeders ou fixtures. La plus répandue est l'utilisation des fixtures, c'est simplement un fichier json ou xml qui stock l'état de votre DB à un instant T. C'est une bonne pratique d'en faire, cela permet d'avoir un projet setup sur une nouvelle machine en quelques secondes. Peu de groupes l'ont implémentés.

.gitignore

C'est un must have dans tout projet (web ou pas web), certains groupes ne l'ont pas intégrés dans le leur. Il y a 36 façons différentes de faire un .gitignore, vous pouvez le faire vous même ou chercher un template en ligne comme base puis l'adapter à vos besoin (en fait, il y à 2 façons) Si jamais voici un bon site que j'utilise tout le temps (il se base sur un répo github très utilisé pour cela) (le site a récemment changé de proprio, avant le site s'appelait gitignore.io) : https://www.toptal.com/developers/gitignore

snake_case convention Python et Django

En python et Django, la convention est le snake_case si jamais. Pas du camel case. Respectez les conventions du langage que vous utilisez, n'appliquez pas simplement ce que vous connaissez déjà (Vous devez savoir vous adapter au projet, aux techno et à l'équipe)

A+
Alex - SpicyPaper