-
Notifications
You must be signed in to change notification settings - Fork 13
Remarques rendus : Django 2018 2019 rendu final
Tout d'abord, bravo à tous pour vos projets web. Dans l'ensemble vous vous en êtes tous bien sortis (parfois même très bien). Vous avez montré une bonne compréhension de django et donc plus généralement des concepts des frameworks web, tout en prenant parfois le pari de profiter de ce projet pour découvrir de nouvelles technos.
Je me permet tout de même de lister quelques remarques générales qui me paraissent pertinentes pour votre (ou vos) prochains projets django (et plus généralement web, ou dev). À savoir : ce ne sont pas des reproches (je n'en ai d’ailleurs pas tenu compte dans l'appréciation de vos codes, ou alors très peu) mais simplement des pistes pour aller plus loin si cela vous intéresse, en espérant ne pas enfoncer des portes ouvertes.
Chez certains, on retrouve la majorité de la logique métier (business logic) directement dans views.py (contrôleurs) (ou dans consumers.py selon projet). Ce qui fait que ces derniers deviennent très (trop) longs et peut vous mener vers du code non-DRY si le projet devait devenir plus conséquent.
La philosophie django propose par exemple d "encapsuler tous les aspects d'un objet dans la définition du modèle" (réf. https://docs.djangoproject.com/fr/2.2/misc/design-philosophies/#include-all-relevant-domain-logic). On se retrouve ainsi avec des "fat models" et moins de code dans les views.
Un bon exemple de fat model ici : https://github.com/HE-Arc/Synai/blob/master/synaiapp/models.py
Contrairement à ce que l'on pourrait penser, bien séparer les choses ne prend pas beaucoup plus de temps de développement et c'est surtout bien plus facile à maintenir sur le long terme tout en étant plus lisible.
Pour finir par rapport à cette remarque un peu abstraite, je me permets de vous renvoyer vers la punchline de philosophie UNIX et le ZEN python
https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://www.python.org/dev/peps/pep-0020/#the-zen-of-python
Bien entendu lorsqu'on parle d'architecture, tout n'est pas toujours noir ou blanc et à la fin ça devient souvent une question de goût, donc faites-vous votre propre avis en lisant, développant et testant ;)
Pour encore mieux diviser votre code python/django, des pistes : Managers : https://docs.djangoproject.com/fr/2.2/topics/db/managers/ Validateurs : https://docs.djangoproject.com/en/2.2/ref/validators/ Divisez votre projet en plusieurs apps : https://stackoverflow.com/questions/18270898/django-best-practice-for-splitting-up-project-into-apps Créez une nouvelle couche entre model et views pour la logique métier : services.py (comme pour les services Laravel), vu ici : https://github.com/HE-Arc/Synai/blob/master/synaiapp/services.py (décidément)
Comme le disait M. Amiguet en introduction à son workshop flask, django est une grosse boîte à outils (tout comme Laravel). On peut donc (moi le premier) passer à côté de certaines aspects qui auraient pu considérablement faciliter le dev du projet. Pour minimiser ce risque, on peut par exemple survoler la doc du l'outil (ici django) et/ou lire le code d'un projet poussé qui utilise pleinement le framework avant de se lancer dans le développement.Pour un django comme pour un Laravel.
Je fais ce commentaire car certains sont complètement passés à côté des vues génériques alors qu'elles auraient pu être bénéfiques. Dans la même catégorie, certains ont construit des urls "à la main" dans les template django alurs que {% url 'route-name arg %} existe.
Vues génériques : https://docs.djangoproject.com/fr/2.2/topics/class-based-views/generic-display/ Routes nommées : https://docs.djangoproject.com/fr/2.2/topics/http/urls/#reverse-resolution-of-urls Tout ce que django peut faire : https://docs.djangoproject.com/en/2.2/#the-model-layer
Je ne vous ai effectivement pas montré comment configurer un autre db engine derrière django mais c'est tout de même assez important pour vos futurs projets et presque gratuit en terme de configuration. SQLite ne supporte pas la concurrence et ne peut pas scaler. Les limites en seront donc très vite atteintes.
Django DB settings: https://docs.djangoproject.com/fr/2.2/ref/settings/#databases Which database should I use in production : https://djangodeployment.com/2016/12/23/which-database-should-i-use-on-production/
Quand vous travaillerez sur une app dans la vraie vie, vous aurez à prendre en compte l'internationalisation (i18n). Si vous avez des chaînes de caractère à traduire dans vos fichiers js, dans vos contrôleurs et dans vos templates ça devient compliqué.Essayez d'homogénéiser le tout (normalement des chaînes que dans les templates)
django i18n : https://docs.djangoproject.com/fr/2.2/topics/i18n/ vue i18n : https://github.com/kazupon/vue-i18n
Si votre projet utilise de nombreux assets front (bootstrap, un datepicker, un framework js, un truc, un autre truc) npm vous évitera bien des souffrances plutôt que d'avoir tous vos fichiers d'assets statics en local qui prendront de la place sur le repo.
why use npm : https://stackoverflow.com/questions/31930370/what-is-npm-and-why-do-i-need-it npm: https://www.npmjs.com/
Rejoignant un peu la précédente remarque. Si votre projet contient une part conséquente de Js, n'hésitez pas à opter pour un framework frontend JS. Si vous partez dans le web, vous devrez forcément passer par cette case à un moment ou à un autre. Si vous faites juste quelques calls à votre API, passez par un package comme axios ou au moins fetch, ajax c'est très old school.
axios : https://github.com/axios/axios js fw : https://hackr.io/blog/10-best-javascript-frameworks-2019
C'est tout, en espérant que certains points vous auront été utiles :)
Je reste à votre entière disposition en cas de remarques ou questions,
a+ et bonne continuation
Dom