Gestion de la dette technique : partie 3 – Les test unitaires

Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur les tests unitaires.

Les tests unitaires, vous en avez probablement entendu parler notamment de phpUnit. L’intérêt des tests unitaires est multiple, mon intention ici n’est clairement pas de vous apprendre à faire des tests unitaires mais de rappeler leur intérêt et surtout comment les mettre en place intelligemment.

Rappel, un test unitaire sert à tester une fonction précise unique avec un périmètre défini. Prenons par exemple une fonction que nous nommerons « somme » qui prendra en paramètre deux nombres et qui en retourne la somme. Le périmètre est restreint simple à tester. La fonction parait même simpliste et on pourrait se demander pourquoi la tester. Plusieurs raisons :

  • Ça ne prend pas énormément de temps
  • Vous aurez l’esprit serein quand vous aurez besoin de modifier cette fonction
  • Si ce test ne passe pas et que tout s’écroule vous trouverez rapidement le coupable

Les tests unitaires ne sont pas la pour vous ennuyer ou vous ralentir, mais pour vous apporter une sérénité et un confort de travail. C’est un des points les plus importants des tests unitaires. Vous obtiendrez un retour sur votre travail quasi instantanément. C’est ce retour qui fait que vous avez l’esprit serein.

Prenons un exemple simple, sans test unitaire, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient l’exécution du code, c’est l’erreur fatale. S’en suit alors une série de ctrl+z ou des var_dump et die en tout genre.

Avec des tests unitaires c’est simple, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient le passage des tests unitaires, …, vous savez exactement ce qui ne marche pas.

A l’instar d’un correcteur orthographique qui vous dit quand vous tapez si vous avez fait une faute et où vous avez la même chose avec les tests unitaires. Vous vous passeriez sérieusement du correcteur orthographique sur votre PC ?

L’autre point c’est que les tests unitaires prennent fatalement du temps au moment des les réaliser. Autant les prévoir, et avancer avec plus de sérénité pour le futur. Mais bon ce temps représente un coût et vous ne pouvez pas forcement vous le permettre. Alors quoi tester ?

Nous avons pris parti avec mon équipe de tester systématiquement deux éléments :

  • Tous les services qui sont fournis à des tiers
  • Toutes les briques que nous réutilisons en interne

Pourquoi uniquement ces deux points là et pas tout ? Parce que nous n’avons pas le temps, et surtout que tout tester n’est pas forcément pertinent. Par exemple certaines applications événementielle qui vont être jeter au bout de deux semaines nous faisons l’impasse. Le retour sur investissement ne vaut pas le coût.

Nous testons les services fournis aux tiers, pour la simple et bonne raison que nous n’allons pas fournir un service défaillant à des tiers liés uniquement à des modifications de notre part. C’est une question de respect à mon sens. Quand vous payez un service vous ne souhaitez pas que votre fournisseur vous disent : « Ah oui ça marche plus mais c’est parce qu’on a fait des modifications, on est désolé on va réparer ça rapidement, …. bla bla bla ». Vous voulez que ça marche un point c’est tout. Donc on s’y engage.

Nous testons les briques que nous réutilisons, par exemple, nous avons des briques internes qui sont réutilisées à travers toutes nos applications. Celles ci par moyen d’y couper on teste. C’est logique si on a une erreur elle sera multipliée par le nombre de projet. Ça relève plus du bon sens que d’autre chose. D’autant plus que ces briques sont énormément utilisées et complexes, rejouer tous les tests à la main ou penser à tout vérifier est impossible. Alors qu’exécuter les tests unitaires ça prend quelques secondes (un peu plus car on en a quelques centaines voire quelques milliers sur certains projets).

Pour le reste, on ne teste pas unitairement notre backoffice par exemple, parce qu’on n’y voit pas l’intérêt, nous avons moins de 10 utilisateurs dessus, quand ça pète ils s’en rendent compte dans l’environnement de recette et ça ne fait de mal à personne. On corrige, ils vérifient, ça par en prod.

Bref, à mon sens tout tester n’a pas forcément de sens, mais tester est indéniablement un atout pour la tranquillité des équipes et la pérennité du code.

Gestion de la dette technique : partie 2 – Duplication de code

Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur le code dupliqué, code duplicate ou encore très souvent nommé « copier/coller à l’arrache ».

Le premier point sur ce sujet c’est tout simplement de comprendre pourquoi un code dupliqué est nuisible dans un projet unitaire. L’évidence même c’est tout simplement qu’au lieu d’avoir un bug, vous en avez autant de fois que vous avez dupliqué le code. Ca semble une évidence et pourtant.

Pour éviter ce genre de bourde nous utilisons plusieurs choses. La première c’est un outil simple et surtout automatique que vous pourrez intégrer dans jenkins. J’ai nommé : phpcpd

La seconde chose c’est l’échange entre les développeurs. Sans échanges au sein de l’équipe de développement il y’aura forcément du code dupliqué. Il est utopiste de penser que tous les développeurs d’un même projet ont la même connaissance de l’ensemble du projet. Chacun a ses préférences, d’autres ont travaillé plus de temps sur un point, et tout simplement tout le monde ne peut pas tout retenir.

Ok, très bien, qu’est ce qu’on fait de ce code dupliqué dans notre projet unitaire. C’est assez simple, il suffit d’en faire une librairie. Sortez le code dupliqué dans une fonction avec des paramètres d’entrées et la sortie qui va bien. Le tour est joué.

Quoi que… Il faudra faire attention à une chose. Le moment où ce code dupliqué utilisé par N autres personnes aura besoin d’une petite spécificité pour l’un d’entre eux. Il sera alors temps de ne surtout pas faire un petit « fix » à l’intérieur spécialement pour l’un pouvant impacter les autres.

Mais le véritable problème du code dupliqué c’est quand il est transverse à plusieurs projets. Là ça devient vraiment pas cool. La raison est toujours la même que précédemment, on va devoir corriger des bugs de partout. Et surtout c’est potentiellement des personnes différentes qui vont corriger le bug de façon différente.

Pour éviter ça, nous échangeons le plus possible à l’oral pour savoir qui fait quoi. Quand quelqu’un rencontre un problème avant de le corriger, on demande si quelqu’un l’a déjà rencontré. Les compétences de chacun sont ainsi tirées vers le haut, et l’émulation se crée au sein de l’équipe.

Une fois qu’on identifie des éléments dupliqués au sein de plusieurs projets nous en faisons si possible une librairie qui se retrouve ensuite en sous module des différents projets. Il faut faire attention à ce point et essayer de garder à jour un schéma de tout ça car ça peut devenir un nœud de spaghetti. Mais surtout la mise à jour du dépôt parent peut engendrer des effets en cascade sur les projets enfants.

Il n’y a pas de solution miracle, c’est l’échange, la revue de code, le pair programming qui restent à mon sens la clé du succès sur ce point même si des outils existent et peuvent attirer votre attention dessus.

Gestion de la dette technique : partie 1 – C’est quoi une dette technique

Suite à la lecture de cet article sur la différence entre ce qu’est une bonne et une mauvaise dette technique j’ai pris l’initiative de faire réfléchir mon équipe et moi même sur le sujet. Nous avons abordé les choses en plusieurs points,  en commençant par qu’est ce qu’une dette technique pour nous.

J’insiste un peu sur le « pour nous » car cet article et les suivants n’ont pas vocation à évangéliser les foules juste à vous partager un retour d’expérience.

Nous avons donc listé les points suivants et je vais tacher à travers une série d’articles de vous faire partager notre expérience.

Une dette technique pour nous c’est :

  • absence de respect d’une convention de codage
  • absence de commentaires
  • complexité du code trop importante
  • code dupliqué
  • pas de tests unitaires
  • pas de test fonctionnel

Nous avons ensuite pris chaque point pour les prioriser et surtout définir le périmètre de chacun. Pour chacun nous avons également discuté des options de mitigation afin de ne pas accumuler de dette sur des points simple.

Commençons par le plus simple la convention de codage. Nous avons adopté les conventions de codage psr 0-1-2-3 c’était un choix évident étant donné qu’on utilise Zend framework 2. Tous les membres de l’équipe ont bien assimilés la chose, tout le monde y trouve son compte en gagnant en lisibilité et en adaptabilité en passant sans problème du code de l’un à l’autre.

Même si la convention est présente dans l’esprit de chacun au court du développement, nous restons des humains faillibles. Pour cela nous nous sommes donc posés la question de comment garantir le respect de cette convention. Nous avons plusieurs éléments à notre disposition.

Premier point notre serveur d’intégration continue,  jenkins. On y a PHP code sniffer (phpcs) avec l’implémentation de la convention PSR disponible ici. C’est bien mais on est réactif et non proactif et ça ne nous convient pas complètement.

Nous avons alors utilisé des plugins dans nos IDE. Sur sublime text ou netbeans il existe de solutions qui font tourner phpcs au fil des modifications. C’est bien pratique pour corriger au fil de l’eau les erreurs d’inattention.

Mais cette solution ne convient pas à tout le monde. Alors nous avons rajouté un autre système le pré commit hook. Ce pré commit lance cs fixer de sensiolabs qui corrige automatiquement les erreurs.  Et derrière on passe de nouveau phpcs. Ceinture et bretelles on est tranquille.

Actuellement nous n’avons plus ce type d’erreur ou alors occasionnellement quand on fait des développements en dehors de nos ide etc… C’est rarissime mais ça peut arriver. Deux ou trois fois par an.

C’est pas grave on a pas tué un bébé panda.

Voilà pour la partie convention de codage. La prochaine fois on attaque le code dupliqué ;-)

PHP : PSR pour ceux qui ont raté le coche

Actuellement en poste chez France Télévisions j’ai fait adopté à mes équipes et mes sous traitants la suite de convention PSR. Pour ceux qui auraient loupé un épisode dans le fabuleux monde de PHP mais surtout sur dans un monde qui veut aller vers du mieux, PSR c’est une suite de « normes ». Actuellement il y a 4 chapitres dans PSR nommés très justement PSR-0, PSR-1, PSR-2 et je vous le donne dans le mille, PSR-3.

C’est une suite qui va plus loin qu’une « simple » convention PEAR ou ZEND, je ne vais pas tout vous citer ici mais voici ce que vous trouverez dans chaque chapitre.

PSR-0

L’objectif c’est en se basant sur le namespace d’une classe être capable de la charger. C’est ce qu’on appelle l’autoloader.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

PSR-1

L’objectif c’est de définir une convention de codage « à minima »

  • Files MUST use only <?php and <?= tags.
  • Files MUST use only UTF-8 without BOM for PHP code.
  • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
  • Namespaces and classes MUST follow PSR-0.
  • Class names MUST be declared in StudlyCaps.
  • Class constants MUST be declared in all upper case with underscore separators.
  • Method names MUST be declared in camelCase.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

PSR-2

L’objectif est d’enrichir PSR-1. Il n’y a qu’un point avec lequel je suis en désaccord, c’est la limitation du nombre de caractères par ligne que je trouve trop bas.

  • Code MUST follow PSR-1.
  • Code MUST use 4 spaces for indenting, not tabs.
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
  • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations.
  • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility;static MUST be declared after the visibility.
  • Control structure keywords MUST have one space after them; method and function calls MUST NOT.
  • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
  • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

PSR-3

L’objectif c’est de définir comment votre application doit logger des évènements. Je trouve l’idée intéressante mais je suis un peu dubitatif sur le fait que ce soit un standard.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

 

Je continue sur PSR, pour ceux qui voudraient passer leur code aux normes PSR, Sensio Labs (Symfony) a publié un outil pour faciliter la mise en place : http://cs.sensiolabs.org/. Je ne l’ai pas testé personnellement, mais je suis preneur de vos retours dans les commentaires ;)

Enfin pour terminer le chapitre PSR, voici un outil pour vérifier dans votre environnement d’intégration continue que tout est conforme, grâce à une implémentation des rulesets de PHP_CodeSniffer disponible ici :https://github.com/klaussilveira/phpcs-psr .

Voila ça fait une petite piqûre de rappel ou qui sera peut être une grande découverte pour d’autres ;)

PHP : MSSQL / ODBC sous Linux

Ajourd’hui je réalise un petit script PHP pour surveiller les résultats d’une requête. Le script sera sur une vieille debian lenny et devra interroger une base de données SQL Server 2008. Ca sent le traquenard, mais je me lance dedans. J’ai déjà utilisé le module pdo_odbc dans un précédent projet, mais sur une distribution récente ou sur ma machine sous archlinux.

Bref, j’installe mon module, freetds et tout ce qui va bien. Vérification avec isql, tout est OK. Je lance mon script et la « Segmentation Fault ». Oh god why… Après multiples vérifications des configurations, des dépendances que j’aurais pu oublier, je tombe sur des pelletés de bug report sur ce type de problème.

Après un moment à galérer je suis tombé sur ce petit post : http://mikegriffin.ie/blog/20120831-accessing-mssql-with-php-on-debian-linux/ . Pour vous simplifier la vie laissez tomber pdo_odbc. ;)

PHP : Identification avec MySQL

Un nouveau screencast pour les débutants, sur l’identification et la restriction d’accès à certaines pages avec PHP et MySQL.

Les fichiers sources sont disponibles : Source : Identification PHP MySQL

A noter que j’ai changé une petite chose, l’enregistrement en session se fait dans la classe et non dans identification.php. Je vous laisser regarder les sources ;)

ERRATUM

J’ai parlé tout au long du tuto de MEDIUMINT, mais j’avais en tête SMALLINT. Du coup je rectifie ce que j’ai dit, le MEDIUMINT (5) non signé va nous permettre d’enregistrer jusqu’à 99 999 utilisateurs. Largement suffisant pour nous. Le SMALLINT (5) non signé lui nous permettrait d’enregistrer 65 535 utilisateurs, clairement suffisant aussi pour la plus grande partie des cas. Merci Olivier d’avoir mis le doigt sur cette erreur de ma part ;)

Freelance : le bon tarif journalier

Pour les freelance il est des fois délicat de se situer dans un marché où les prix peuvent fluctuer très rapidement en fonction de l’offre et de la demande. Suite à l’effet de crise le tarif des prestations à baisser au sein des SSII et il n’est pas forcément aisé de se vendre au juste prix. Pour vous aider le site freelance-info.fr vous propose une grille de tarif que je trouve à titre personnel très bien conçue. Vous pouvez y accéder via ce lien : tarifs jour de facturation des freelance. Vous y trouverez non seulement le tarif, mais également la répartition des missions par année d’expérience, et par intermédiaires. De plus pour ceux qui cherche une description précise et concise du poste qu’ils cherchent à pourvoir il y a une description pour chaque métier. Une très bonne chose pour les freelance et en plus c’est gratuit donc c’est encore mieux.

Y a site web et site web voire PHP et PHP

Depuis toujours le métier de développeur web a été plus ou moins méprisé. Ce qui revient souvent dans les conversations c’est les phrases comme « Ah mais donc en fait je peux moi aussi faire mon site web » ou « Ah vous faites pas le contenu, vous faites quoi alors ? ». Je vais donc aujourd’hui un peu éclaircir le sujet et répondre à ces questions qui ne rendent pas hommage à ceux qui travaillent durement pour vous servir.

La première chose à savoir c’est à mon sens que c’est le contenu qui fera le succès d’un site. Et les équipes qui rédigent le contenu des sites sont clairement la clé de cette réussite. Toutefois pour y parvenir il leur faut ce fameux site web, site internet, blog peu importe la forme en fin de compte. Ce qu’il faut comprendre c’est qu’un site web ce n’est pas seulement l’affichage de ces textes et images. C’est aussi tout un système qui permet de gérer ce contenu, mais qui gère également les auteurs, la mise en page, la mise en avant de certains éléments, la possibilité de changer certains éléments, de gérer des sondages, la publication du contenu en fonction des auteurs, encoder de la vidéo en flash et j’en passe. C’est une véritable suite bureautique en ligne.

Comme je viens de vous le montrer un site web ne se limite pas à l’affichage du contenu, outre la gestion des contenus on trouve également des fonctionnalités propre à chaque site, comme comparer des produits, calculer des couts de revient, souscrire à un contrat, répondre à un sondage, donner son avis sur le contenu, imprimer le contenu, publier son propre contenu un tas de fonctionnalités qui ne sont pas simplement de l’affichage de contenu mais qui demande des calculs et de la gestion de droit en fonction des utilisateurs par exemple. C’est toutes ces fonctionnalités qui permettent de faire un site internet.

Ou est ce que je veux en venir ?

C’est assez simple en fait, le métier de développeur web pourrait s’apparenter à celui de pilote de rally ou de chirurgien. En effet, si le web est accessible à tout le monde et qu’il existe des solutions clés en main pour créer son site internet nous sommes loin de ce qu’est notre métier, ou en tout cas ce qu’est le mien. Dans toute profession ou discipline il existe des niveaux. Ainsi ce n’est pas parce qu’on a le permis et qu’on sait conduire qu’on est Sebastien Loeb, de même ce n’est pas parce que l’on sais soigner une plaie ou même que qu’on a son brevet de secouriste qu’on est chirurgien. Et c’est encore plus complexe que ça il y a comptable et expert comptable, médecin et chirurgien, de même on a des intégrateurs, des développeurs et des ingénieurs au sein de notre métier. Et comme vous le savez à poste égal on a encore des différences de niveau entre les individus.

Vous devez commencer à comprendre que finalement faire des sites web ce n’est pas forcément si simple.

Je vais prendre un exemple plus concret, dans ma société (Opal CMS). Nos clients disposent d’un outils de gestion de contenu plus ou moins complet en fonction de leur besoin ça comprend la gestion de leurs documents comme des actualités à des dossiers multipages, la gestion de tous les types de médias, comme les images – avec la possibilité dans la partie administration de rechercher une image directement sur le net et de l’importer de façon transparente -, les fichiers audio, les fichiers vidéos. Pour certains ils ont la possibilité de tout simplement filmer ce qu’ils ont envie et d’envoyer le fichier sur le serveur. Notre outil transforme la vidéo en flash comme sur youtube ou dailymotion. Ils ont un système complet de workflow, c’est à dire de gestion du processus de publication, chaque utilisateur a des droits qui lui permet de signaler si son article est prêt à paraitre, alors qu’un autre utilisateur se chargera de le mettre en ligne. Certains clients ont des demandes particulières comme gérer l’import de flux RSS ou AFP de façon automatisée ou la possibilité de gérer des formules de calcul pour des applications particulières et d’autres la possibilité de gérer leurs commandes et leur stock. Je fais un peu de pub pour illustrer mon propos mais ça vous montre qu’un site internet ne se limite pas à afficher des actualités.On peut désormais utiliser le web pour gérer énormément de chose. Exemple très concret les opérateurs de téléphonie mobile gère la vente des téléphones et la souscription des contrats directement via des applications web.

Autres point important entre ce que monsieur tout le monde peut faire et ce que nous sommes amenées à faire, c’est travailler sur des applications scalable à haute performance. C’est à dire que l’application web est optimisée pour gérer beaucoup de demande, en effet entre un site personnel qui fait 10 visites par jour et des sites comme lemonde qui tourne plutôt autour du million de visites il y a une grosse différence. C’est pour ça que nous mettons en place des solutions performante et scalable, c’est à dire des solutions capable d’évoluer avec la demande qui seront capable d’être réparti sur des dizaines de serveurs de façon transparente pour le client et pour l’utilisateur sans que cela engendre des coûts pharaoniques.

Voila, vous en savez un peu plus sur ce que nous faisons ;) Rendons à César ce qui appartient à César et vive les développeurs et ingénieurs du web qui nous permettent à tous de profiter du contenu de chacun.

Oui une question ?

Pourquoi j’ai pas parlé de Google dans les applications web complexes ?

Je sais pas … :D

Bon surf ;)