# Architecture logicielle --- ## Objectif de la capsule Améliorer la qualité de son application web. --- ## Programme - L'architecture, **pour quoi** faire ? - Les **types** d'architecture - Les **patrons** de conception - Les grands **principes** pour un code propre # L'architecture logicielle --- ## Les fenêtres, je les mets où ? - Pourquoi faire de l'architecture logicielle ? - Quelles sont les missions de l'architecte ? - Pourquoi le DAFS doit-il s'intéresser à l'architecture ? ![architecture](./images/numerobis2.jpg) --- ## L'architecture - Intermédiaire entre le _besoin_ et la _réalisation_ - Pour anticiper les problèmes - Donner une feuille de route à l'équipe --- ## Ses missions - Décrire et défendre le fonctionnement d'un système - Maintenir ses connaissances - Avoir une vision claire des orientations du projet - Évaluer la charge d'un projet --- ## Zoom sur l'évaluation d'un projet - En quoi consiste l'estimation de charge ? - Comment la faire ? --- ## Estimer la charge d'un projet - C'est estimer la charge en **jours/homme** d'une tâche - Différent du délais - Prévisionnel donc inexact - Prise en compte des tâches autres que le dev - Précis pour le planning prévisionnel... - ...ou vague en avant-projet --- ## Évaluation précise - Détailler ce qu'il faut faire - Évaluer chaque sous-tâche - Ajouter un coef. pour tests / validation / documentation - C'est en chiffrant que... --- ## Évaluation « grosses mailles » - Méthode scrum poker - Estimation relative - Méthode approximative --- ## Méthode approximative 1/2 - Pas de délais précis mais des approximations - H ~ une heure (~2h) - H\* ~ plusieurs heures (~5h) - D ~ un jour (~1,5j) - D\* ~ plusieurs jours (~3j) - … --- ## Méthode approximative 2/2 - Permet de faire comprendre que l'évaluation est approximative - Mais tout de même convertible en jours directement - Ne fonctionne que pour les chiffrages « grosses mailles » --- ## Exemple de chiffrage **Activité** : évaluer la charge d'un projet. Notes: Sur le projet fil blanc. Par story. Individuel. # Les grandes architectures pour les DAFS --- ## Recherche Quelles architectures existent ? Notes: - https://fr.wikipedia.org/wiki/Architecture_trois_tiers - https://fr.slideshare.net/HeithemAbbes1/architectures-3tiers-web - https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur - https://www.youtube.com/watch?v=4Qfk8MhtZJU - https://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services - https://proandroiddev.com/mvvm-architecture-viewmodel-and-livedata-part-1-604f50cda1 - https://fr.wikipedia.org/wiki/Client%E2%80%93serveur - https://www.youtube.com/watch?v=ucHwp1jUS2w - http://igm.univ-mlv.fr/~dr/XPOSE2001/perrot/Intro-Comparatif.htm --- ## Trois anneaux pour... - 3-tiers - MVC - MVVM - ... --- ## 3 modules - Modèle / Data - Controller / Logique - Vue / Présentation --- ## 3 tiers ![3tier](./images/3tier2.png) --- ## MVC ![mvc](./images/mvc2.png) --- ## MVVM ![mvvm](./images/mvvm.png) --- ## Le service, c'est la santé - SOA / Web service - Micro-services --- ## Service Oriented Architecture ![soa](./images/Concept_SOA.jpg) Note: Q: Quels sont les avantages ? --- ## Les avantages - Autonomes - Découplés - Composables - Encapsulés - Interopérables - Découvrables --- ## Web service ![soa](./images/Concept_WS.jpg) --- ## Micro service - Du SOA poussé à l'extrême - Scalabilité - Mise à jour - Résistant aux pannes - Isolation --- ## Mais... - Pb quand logique partagée -> redondance - Nécessité d'une supervision - Complexité - Bus # Les patrons de conception --- ## Ne pas réinventer la roue - Produit de l'expérience - Problématique récurrentes - Théorisation / Structuration - Boîte à outils Notes: Parler de la terminologie. --- ## Découvrons les patrons **Activité** : associer les définitions et exemples aux patrons correspondants. Notes: Regarder le PDF. --- ## Réponse 1/2 - Adapter - Decorator - Façade - Factory - ... --- ## Réponse 2/2 - ... - Observer - Proxy - Singleton # Apprendre à mieux développer --- ## Quelqued grands principes - DRY - KISS - YAGNI - SOLID --- ## DRY... ... ou l'art d'être feignant. ![sleeping cat](./images/kitty.png) --- ## KISS... ... ou pourquoi faire compliqué quand on peut faire simple. ![Rube golberg](./images/rubegolberg.jpg) --- ## YAGNI... ... ou le mieux est l'ennemi du bien. ![Swiss army knife](./images/toomany.jpg) --- ## SOLID... - S - Single responsibility Principle (AKA: Separation of concerns) - O - Open-Closed Principle - L - Liskov Substitution Principle - I - Interface Segregation Principle - D - Dependency Inversion Principle --- ## Tout en restant raisonnable Le mieux est l'ennemi du bien. --- ## Zen of Python ```python >>> import this """The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!""" ``` --- # Des questions ?