Et le blog ?

Le lecteur attentif aura remarqué que ce blog n'avance plus beaucoup.

En effet, il m'est assez compliqué d'appréhender une nouvelle technologie et d'écrire dessus. Au fur et à mesure que j'en découvre, je suis obligé de revenir sur ce que j'ai déjà fait.

Si j'avais écrit tout ce que j'ai fait, le résultat aurait été proprement imbitable

J'ai donc décidé de faire une pause dans Castle / Monorail pour publier de temps en temps des articles plus généraux sur le développement.

Je reviendrais sur Castle quand j'aurai maîtrisé la techno

Factorisation en base de donnée

Factorisation

La factorisation, qu'est ce que c'est ?

On parle factorisation de code quand on essaye d'extraire les points communs entre plusieurs problèmes, afin de ne les traiter qu'une seule fois.

Basiquement, l'utilisation d'une fonction (ou d'une procédure) appelée plusieurs fois dans un programme est la première forme de factorisation.
L'héritage en programmation orientée objet est un puissant outil de factorisation : le même code étant propagé à tout une famille d'objets présentant des caractéristiques communes.
La notion de service dans les architectures orientées service est une autre forme de factorisation.
etc.

Je pourrais ainsi faire une longue liste, mais ceci n'aurait pas d'intérêt et il y aura toujours un emmerdeur puriste pour débattre, vendre sa vision de la chose ou insister pour rajouter ou mettre en avant sa méthode favorite. L'objectif ici est simplement de justifier la suite de cet article.

L'idée ici est de montrer comment, grâce à ActiveRecord, on va pouvoir factoriser une partie du travail sur la base de donnée.

Factoriser le code, pourquoi faire ?

Pour éviter de refaire le même travail plusieurs fois.
Pour simplifier la maintenance d'une application
Pour généraliser une best-practice dans un framework
etc.

En l'occurence, ce qui m'intéresse ici c'est de factoriser la mise en place de certains champs quasi-obligatoires dans ma base de donnée.

Factoriser ma base de donnée

Points communs

Quels sont les points communs entre toutes les données nécessaires pour coder mon blog ?

• Je souhaite tout d'abord qu'elles soient toutes identifiées de façon unique
• Je veux que cette identification se fasse par un entier (principalement pour des questions de performance)
• Parfois je pourrais aussi être amené à utiliser d'autre identifiant, notamment les GUID
• J'aimerai stocker la date de création de la plupart des données
• Il me semble sensé de noter également la date de dernière modification
• Idéalement, il faudrait également connaitre l'identité de l'utilisateur ayant créé cette donnée
• Et tant qu'à fait, si on pouvait également noter l'identité de l'utilisateur ayant fait la dernière modification

Mes champs communs

Grâce à la liste ci dessus, j'ai la liste des champs que veux dans chacune des données de ma base :

• ID - un identifiant, soit entier, soit GUID
• DateCreation - la date de création de mon entrée en base
• DateModification - la date de dernière modification
• IdCreator - l'identité du créateur
• IdUpdator - l'identité du dernier utilisateur ayant modifié cette donnée

Quelques explications

Pourquoi ne pas stocker un historique global des modification ?
Ca serait très pratique en effet
Disons que d'expérience c'est beaucoup plus compliqué à mettre en place. On verra pour la v2.

Pourquoi utiliser des GUID pour identifier des données ? Il peut y avoir deux raisons :

• Lorsque plusieurs bases de données peuvent créer des entrées dans une même table. La gestion d'un identifiant entier auto-incrémenté pose alors des problèmes de synchronisation.
• Lorsqu'on veut pouvoir exposer un identifiant de façon sécurisée. Il est plus difficile pour un hacker de deviner un GUID que d'essayer différents entiers pour récupérer les informations d'un autre utilisateur ou d'un élément auquel il n'a pas accès. Dans une URL typiquement.

Pourquoi 'DateCreation' et pas 'CreateDate' ?
Parce que j'essaye de toujours mettre le type de la donnée en premier.
Ma règle implicite de nommage c'est 'quoi' en premier. D'où les "IdSchtroumpf" et pas "SchtroumpfId".
C'est une convention de nommage personnelle qui m'apporte beaucoup en terme de lisibilité.

Conventions de nommage

Une convention de nommage, qu'est-ce-que c'est ?

L'article de Wikipedia étant un peu réducteur, en voici une définition plus personnelle.

C'est un ensemble de règles de nommage des différents éléments du code.
Ces règles sont définies par le chef de projet ou l'architecte du projet, afin d'homogénéiser le code.
Un développeur travaillant seul défini et applique généralement ses propres conventions de nommage.

Fondamentalement, une convention de nommage est une discipline très stricte que cultivent tous les bons développeurs.

Une convention de nommage, pourquoi faire ?

Les projets informatiques sont de plus en plus vastes.
Il est quasiment impossible d'avoir en tête d'intégralité d'une application en détail.
Par conséquent, lorsqu'un développeur intervient sur un projet, il faut qu'il puisse lire le code sur lequel il travail.

Sans convention de nommage, la lecture du code n'est pas fluide, le développeur est toujours obligé d'aller voir à droite ou à gauche ce que représente telle ou telle variable, d'aller analyser un autre morceau de code pour savoir quelle est la fonction à utiliser pour faire telle chose.
Bref, c'est l'anarchie.

Sans même parler du bénéfice dans une équipe, un développeur qui travaille seul et qui revient sur son code passé quelques mois aura besoin de retrouver ses petits si son projet est conséquent.

Concentration

Une convention de nommage permet également au développeur de concentrer son attention sur ce qui est vraiment important : la résolution du problème.

Pour faire un rapprochement, imaginons un athlète avec des baskets pourries.
Lorsqu'il courre, il doit faire attention aux petits cailloux car ses semelles sont trop fines et il peut se piquer la plante des pieds ce qui est désagréable.
En plus, il doit faire attention à bien poser son pied par terre et surtout à ne pas taper le sol sous peine d'avoir des problèmes aux genoux.

Est-ce que cet athlète à une chance de devenir athlète de haut niveau ?
Non.
Il va se concentrer sur des détails qui vont l'empêcher de se focaliser sur son but : devenir le meilleur, et il ne va pas pouvoir exploiter tout son talent.

Utiliser des conventions de nommage, c'est donner des bonnes baskets à votre développeur qui vont lui permettre de pulvériser vos records problèmes.