Forum Programmation.python architectures de code

Posté par  . Licence CC By‑SA.
Étiquettes :
4
21
mar.
2022

Bonjour,
Je connais l'architecture MVC mais pas vraiment d'autres architectures…
Est ce que vous connaissez de bonnes ressources pour apprendre?
Là j'apprend avec les projets open source et les tests unitaires à déployer le code sur plusieurs fichiers et éviter les gros blocs d'un seul coup, mais je ne suis pas encore au top…

  • # Pour quelle techno ?

    Posté par  (Mastodon) . Évalué à 7.

    La bonne question, c'est pour quel type de projet ?
    Çà va conditionner sur quel framework vas-tu développer !

    Django

    Django propose une structuration des projets assez stricte

    + project/
  + settings.py
  + urls.py
  + wsgi.py

+ application/
  + admin.py
  + models.py
  + views.py
  + templates/application
  + urls.py
  + tests.py
  + ...

    On peut ajouter autant d'application qu'on veut, çà permet de découpler pas mal. Chaque application a son "namespace" dans la base de données.

    Chacun de ces fichiers a un rôle bien précis, et peut de toutes façon se transformer en module en remplaçant le fichier par un dossier avec le même nom + __init__.py.
    tu peux trouver plein d'applis complémentaires pour ajouter des fonctionnalités à ce que propose django "de base".

    Du coup, à base d'imports relatifs + abus de __all__, tu peux faire croire à tes imports qu'ils sont dans le module principal.

    Pour Django, le modèle de développement n'est pas MVC mais MTV : model / template / view. La partie "Controler" est répartie entre les models et les views, il y a des astuces pour faire en sorte que çà le soit pas trop le boxon, mais en général on retrouve bien ses petits.

    Django propose "de base" la gestion des utilisateurs / groupes / permissions, une interface d'admin paramétrable, la gestion des migrations de la base de données, des templates…

    Et si tu veux faire du REST, tu as django-rest-framework

    Flask

    Flask a quant à lui une démarche très différente : tu fais ce que tu veux, il ne t'impose rien ! Du coup, tu n'as pas d'ORM, pas d'admin, pas de gestion des utilisateurs ni des sessions… juste des routes et les fonctions associées.

    Il y a bien sûr des tas de plugins qui te permettent d'inclure ces fonctionnalités !

    Il y a aussi des applis plus touffues développées sur Flask, mais le principe reste le même : tu as les clés en main.

    Et sinon ?

    J'utilise pour ma part beaucoup django, pour les applis "classiques" type CRUD ou similaires, et flask si je n'ai pas besoin de base de données, par exemple pour faire un utilitaire Web.

    Ah, et j'ai aussi un gros intranet qui tourne avec Wagtail, une surcouche de django, qui fait très bien le taff : admin du CMS jolie et pratique, assez couple à mettre en place (1 mois de boulot ?), et la possibilité d'inclure des application django de façon transparentes pour des trucs "à côté" du CMS.

    Il y a plein d'autres framework web à base de python, surtout que celui-ci a le vent en poupe, mais je ne pratiques que ces 2 là, car ils correspondent bien à mes besoins…

    Ah, aussi, si tu es dans une boîte, fais toi offrir une licence PyCharm, les trucs à base de VSCod(uim) sont largement en dessous ! En prime, le support de Flask et Django dans pycharm est très bon !

  • # Architecturer du code est le travail d'une vie ;)

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    L'architecture MVC est une manière d'implémenter une application mais dès que tu travailles sur des projets complexes, ça ne suffit plus.

    À partir de la, il y a plusieurs approches possibles selon les cas … Et pas de solution clé en main à mon sens.

    Plus tu découpes et découples, plus ton logiciel est résilient et maintenance… Mais plus il sera coûteux à maintenir.

    Veux tu mettre construire une architecture évolutive ? Dans ce cas une structure à base d'interfaces de programmation et de plugins sera la meilleure solution, mais alors c'est du boulot.

    Ou alors tu as une architecture monolithique, moins évolutive mais nettement plus simple à maintenir.

    Tu peux aussi t'orienter vers une architecture micro services mais là on s'éloigne de l'architecture logicielle pure…

    Ce qui me semble important :

    1. Regarder ce qui se fait
    2. Connaître les pattern classiques (Factory, stratégie, etc, etc)
    3. Écrire des tests car si tu veux changer l'architecture de ton code, les tests t'aideront à réécrire à iso-perimetre
    4. Documenter et faire le + simple possible

    La démarche d'évolution assez classique d'un développeur est :

    1. Novice -> pas d'architecture
    2. Intermédiaire -> trop d'architecture
    3. Expérimenté -> architecture réfléchie là où c'est important

    Mais même en étant expérimenté on n'est pas forcément d'accord avec ses pairs …

    Bon courage :)

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Pour moi la base : isoler les règles métier

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 22 mars 2022 à 09:11.

    De manière générale, il est de bon ton d'isoler les "règles métier" du reste de l'application.

    • tu fais une application de compta ? Ne mélange pas la gestion des sauvegardes avec le calcul de l'impôt récupéré sur la TVA au titre du quantième restant sur la plus-value amortie.

    • tu fais un serveur web ? MVC t'aidera à mettre de côté la gestion du cœur de l'appli (dans les modèles en général) du déroulé de la connexion/déconnexion de l'utilisateur (dans les contrôleurs en général).

    • tu fais un capteur de température en ESP8266 ? Ne mélange pas la conversion du résultat brut du capteur en °C/°F avec la remontée des données vers ton serveur MQTT.

    Que veut dire "ne mélange pas" ? Selon les cas ce sont simplement des fonctions à part, parfois des "modules" (selon le langage ce sera fichiers, classes…) à part, et même des services à part pour les plus grosses applis.

    Chaque "module" doit avoir un rôle assez précis. Dans une équipe d'une dizaine de développeur, imagine que chaque "module" serait administré par un spécialiste. Si tu es tout seul, à toi de retourner ta casquette chaque fois que tu touches un module pour veiller à ce qu'il n'aille pas se mêler de ce qui ne le regarde pas.

    Un très bon bouquin sur ce sujet est Architecture logicielle propre de Robert C.Martin, que j'ai découvert par ce billet de blog.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Commentaire supprimé

    Posté par  . Évalué à 8. Dernière modification le 24 mars 2022 à 15:51.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.