Nous allons parler ici principalement de conventions et comment les utiliser pour améliorer notre code. Le but des conventions est de nous amener au zéro friction development. Soit donc d’avoir une manière de développer qui supprime au maximum la tuyauterie répétitive au minimum.
Par exemple sur une voiture, il y a des conventions, on peut en théorie s’assoir dans n’importe quelle voiture, se repérer rapidement et être capable de la conduire car les conventions de manipulations d’un véhicule sont toujours les mêmes.
Souvent on ne veut pas entendre parler de conventions car elles ne sont pas supposées être compile type safe. Csharp est statiquement type et me donne un certain nombre de garanties avec le compilateur, cela nous apporte des outils intelligents en temps réel et du refactoring efficace.
mais un programmes ne peut être entièrement checke de manière efficace uniquement par le compilateur dans tous les cas!
Par ex, les gens ont eu peur lors de l’arrivé du mot clé var alors qu’il ne s’agit que d’une convention.
De même si on a un type générique et que l’on énumère sur une liste de ces génériques, on doit par la suite faire des tests sur chacun des types possibles. Des erreurs peuvent être possibles à ce moment et c’est normal car le compilateur csharp est un compilateur multi usage qui ne peut pas tout connaître des règles que l’on va utiliser dans notre code.
Par exemple si vous avez pour des rapports, un dossier dans lequel vous aller mettre ou chercher tous les reports,vous pouvez définir un dossier dans un fichier de config. Ceci est une convention. Ceci peut être remplacé de manière lus élégante par une construction automatisée du chemin basée sur des règles ou conventions: ceci nous donne au final un code plus simple et plus fiable.
le but d’un framework ou application bien écrit est de minimiser proprement la manière de travailler avec et le code produit
wcf est un exemple concret de mauvais code compliqué pour rien. On a tous en tête la création, configuration utilisation de services wcf complexes. Voici un contre exemple de configuration wcf par conventions via castle Windsor:
On voit que les conventions sur ce modèle nous permettent avec peut de conventions que très rapidement on est gagnants:
Les gens ont peur en général des conventions parce qu’il ont l’impression qu’il n’y a rien ou que c’est magique alors que de longues lignes de code et configuration sont rassurantes.
Mais les conventions ne sont pas toujours faciles à suivre. Il faut de la discipline.
Plusieurs choses peuvent êtres vérifiés par réflexion en utilisant plusieurs méthodes: par convention de noms comme dans asp mvc, par des génériques, par des attributs…
Mais il nous manque quand même des outils pour vérifier nos conventions avant le runtime.
Mais nous faisons des tests, non?
Pourquoi ne pas vérifier nos conventions lors de l’exécution des tests?
Le principe est ici de rajouter des projets de tests spéciaux pour valider des conventions. Ces projets nous permettent aussi de générer De la documentation. Pour cela on peut s’aider du package suivant : ConventionTests:
On se base sur des tests nunit pour lancer nos tests, on défini en général, un test de convention par classe (note : par classe on entend ici une classe de type configuration de convention comme des classmap automapper ou autres)
Pour s’aider, on peut utiliser un librairies comme ApprovalTests. Ceci permet de génèrer des fichiers (received) lors des tests, ces derniers vont être comparés avec des versions (approved). Ceci va nous permette de dire pour un test si c’est normal par exemple qu’une classe ne suive pas la convention attendue. L’autre intérêt de cette méthode, c’est que ce fichier d’approbations de non respect de la convention va être comité dans le repository, ce qui nous permettra d’informer simplement les autres développeurs de cette non convention et surtout d’avoir un historique du comportement au fur et à mesure de la vie du projet.
Note: Windsor utilise ce type de conventions et tests en interne et possède un certain nombre de tests intéressants par defaut : par tester si il y a dans une librairie cliente des utilisations en mode service locator! So damn cool 
Règles pour les tests par conventions:
- être consistant
- lister les les problèmes nominativement
- expliquer le problème
- use ApprovalTests tests
Les tests par convention nous permettent de diminuer la complexité du code, cela facilite la discussion, permet d’avoir un feedback plus rapide
notes: nous avons pu voir ici, une solution très élégante sur le sujet de la programmation par conventions, que j’adore soit dit en passant car il vaut mieux à mon sens définir la manière globale dont doit se comporter une application et définir en apparté les exceptions que l’inverse. Cette solution permet surtout de faire du traitement de convention dans notre code ( et pas uniquement quand des gentils frameworks nous le proposent) et ce de manière simple et claire: pas de framework, sécurisée par les tests, informations dans des fichiers texte et historiques dans le contrôleur de sources.
