Vaste sujet ! Dans cet article, nous allons parler clean code, dette technique, refactoring et anti-patterns. Il fait suite à la série sur les designs patterns que vous pouvez retrouver ici :
Les design patterns et les principes SOLID en développement logiciel Les patterns creationals Les patterns structurals Les patterns behaviorals Tout logiciel est constitué de code, et c’est la qualité de ce code qui va faire d’une application une application de qualité.
Je suis (enfin !) de retour sur le blog après plusieurs mois d’inactivité. Dernièrement, le temps d’écrire m’a pas mal manqué (!) et la migration de mon blog vers une nouvelle plateforme m’a aussi beaucoup occupé. C’est justement ce dernier point que je vais aborder aujourd’hui.
Vous avez dû remarquer (j’espère…) que le style du blog a bien changé et que les performances sont bien meilleures qu’avant (j’espère aussi… !). On va faire ensemble le tour de toutes les nouveautés, et je vais essayer de vous expliquer au fur et à mesure les raisons qui m’ont poussé à changer.
Troisième et dernière catégorie de pattern que je vais aborder, les behavioral patterns ou patrons de comportement. Il en existe 11 et ils permettent de définir comment organiser nos objets pour que ceux-ci collaborent.
Si jamais vous les avez ratés, je vous invite à (re)lire les parties précédentes :
L’introduction sur les design patterns Les patterns creationals Les patterns structurals Table des matières Chain of responsibility Pipeline Command Interpreter Iterator Mediator Memento Observer State Strategy Template Visitor Chain of responsibility Ce pattern permet de séparer les objets émetteurs de requêtes et les objets chargés de recevoir et traiter les requêtes.
J’ai récemment eu besoin de mettre en place une authentification via Azure AD dans une application web ReactJS. Globalement, la procédure est assez simple, mais il y a tout de même quelques subtilités sur lesquelles j’ai perdu pas mal de temps et que je souhaiterais partager ;)
Côté client, c’est la librairie ADAL.js (Active Directory Authentication Library for Javascript) qui va nous aider. Microsoft supporte de nombreuses plateformes différentes en fonction des environnements client ou serveur visés (plus d’informations sur ce lien).
C’est la capacité d’une application à s’adapter à la charge, c’est-à-dire le nombre d’utilisateurs pouvant être servis simultanément.
Après les patterns creationals (que vous pouvez retrouver ici), je vais maintenant aborder les structural patterns ou patrons de structure. Il en existe 7 et ils permettent de définir comment organiser nos objets. Si vous le souhaitez, vous pouvez retrouver l’introduction sur les design patterns ici.
Table des matières Adapter Bridge Composite Decorator Façade Flyweight Proxy Adapter L’objectif du pattern Adapter est de faire passer quelque chose pour autre chose sans perturber le reste de l’application.
De retour pour un nouvel article sur un sujet à la mode : les Progressive Web Apps ! Cela fait quelques mois que j’ai envie d’écrire sur cette technologie que je trouve très intéressante et pertinente à l’heure actuelle. Les Progressive Web Apps, que je vais abréger par PWA dans la suite de l’article, sont nées en 2015 sur l’impulsion de Frances Berriman et de l’ingénieur de chez Google Alex Russell.
Je vais aujourd’hui vous faire partager un sujet qui est dans ma to-do list depuis plusieurs mois et dont je me sers très souvent : l’instruction MERGE en SQL.
Cette instruction est apparue avec SQL Server 2008 et permet de combiner plusieurs opérations DML (Data Modification Language -> INSERT, UPDATE, DELETE) en une seule instruction. Elle est très pratique pour synchroniser 2 tables entre elles. Voici les principaux éléments à mettre en place, que je vais appliquer à un exemple :
Suite à l’article d’introduction, les premiers types de patterns que je vais aborder sont les creational patterns ou patrons de création. Il en existe 5 et ils permettent de définir la manière de faire l’instanciation et la configuration des classes ou des objets de manière souple tout en minimisant le couplage et en maximisant la réutilisation du code.
Table des matières Singleton Factory Abstract Factory Builder Are you fluent ? Prototype Singleton C’est probablement le design pattern le plus connu et le plus utilisé.
Je souhaite revenir aujourd’hui sur un sujet qui, à mes yeux, est très important mais malheureusement assez méconnu des développeurs : les design patterns. Lors des quelques entretiens que j’ai pu faire passer, je me suis rendu compte que cette notion est soit mal maitrisée (quelques mots-clés/buzzword cités ça et là mais sans réelle explication derrière) soit carrément inconnue ! Je trouve ça dommage car c’est quelque chose de très utile dans son travail quotidien et nous allons voir pourquoi dans cet article.