Alheim

 Hier se déroulait la plus grande freeze du monde. Après New-York, Londres et d’autres, celle de Paris a réuni près de 3000 personnes autour des fontaines du Trocadéro.

A 14h36, tout le monde s’est immobilisé dans des positions assez démentes.

Merci à Charles Nouÿrit pour l’organisation. On a passé un super moment.

La vidéo officielle devrait être publiée en début de semaine. 

En attendant, vous pouvez allez voir ici et là.

En tout cas, ça m’a permis de voir pas mal de monde de la blogosphère et donc…de me bouger pour écrire sur mon blog.

 Je commence aujourd’hui une série de billets sur les "design smells". Derrière cette expression se cachent les problématiques qui ont poussé un jour le Gang Of Four (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) à écrire les premiers design patterns.

Je lis beaucoup d’articles traitant de ces recettes magiques et souvent le constat est le même : on apprend à faire un template, une factory, un proxy….mais on ne sait pas quand les utiliser. Alors on tombe dans le syndrome de la "paternite aiguë" qui consiste à vouloir les implémenter systématiquement et à toutes les sauces. Et là c’est le drame. Ce qui aurait pu être codé en quelques ligne requiert 4 classes, une interface, de la réflexion…. L’exemple paraît extrême mais on le retrouve souvent chez les développeurs qui viennent de lire "Head First in Design Pattern" mais qui n’avaient pas forcement de notions d’architecture avant cela. Les conséquences, des coûts de développement supplémentaires et une frustration de la part des développeurs qui se rendent vite compte que rien est magique.

Voilà donc pourquoi j’apprécie l’approche "Code Smells" qui apprend tout d’abord à identifier les portions de code mal écrites et les besoins de refactorisation. Le design pattern est alors un outil et non un objectif en soi.

Let’s rock !

Aujourd’hui, ce billet sera dédié au Smell le plus facile à identifier : "le code dupliqué"

Première chose, pourquoi essayer de lutter contre la duplication de code :

- tout d’abord parce que plus le code est compact, plus il est facile à tester et à maintenir
- imaginons qu’il y ait un bug dans une des portions dupliquées. Souvent, la correction n’est pas reportée dans les autres portions et le même bug risque de réapraître plus tard. Il sera considérer comme une régression, gloups…

On peut distingue 2 sortes de code dupliqué : le code dupliqué explicite, le code dupliqué subtil.

Le code dupliqué explicite est le plus facile à identifier. On retrouve les mêmes lignes de code à plusieurs endroits.

Le code dupliqué subtile quant à lui est bien plus fourbe car il s’agit de plusieurs portions de code exécutant les même traitements, mais codé différemment.

Exemple 1 :

La même méthode est implémentée de manière presque similaire dans 2 sous-classes. On retrouve alors des lignes de code communes et des lignes de code spécifiques.
Une solution possible est d’utiliser le pattern "Form template method" qui consiste à créer une méthode ayant la même signature dans la classe mère. Cette implémentation contiendra le code commun puis déléguera à ses filles les comportements spécifiques via des méthodes abstraites (hook)

Un exemple de code ici.

Exemple 2 :

Si une classe contient plusieurs constructeurs avec du code dupliqué, l’utilisation du pattern "Chained Constructor" peut résoudre le problème.
En exemple de code ici.

Exemple 3 :

2 classes exécutent sensiblement les même traitements mais n’implémentent pas d’interface commune. Si les 2 interfaces ne peuvent pas être mergées, une solution peut être de créer une interface commune à ces 2 classes afin de simplifier le code appelant. L’utilisation du pattern "Unify interface with Adapter" permet de créer un point de jonction.
Un exemple de code ici.

Exemple 4 :

On introduit souvent une logique conditionnelle dans le cas où un objet est nul. Et cette logique est répercutée dans tout le code. En utilisant le pattern, "Null Object", cette duplication peut être évitée.
Un exemple de code ici.

Et bien voilà, 4 exemples de Smell, 4 solutions…et non le contraire.

Dans le prochain billet, je parlerais d’un autre cauchemar de développeur : les longues méthodes, ou comment éviter d’avoir des méthodes de 400 lignes qui deviennent très vite impossible à maintenait.

 

 Quoi de plus désagréable que d’arriver dans un code dans lequel les méthodes font 400 à 500 lignes !

Au delà du fait qu’il faut 2 heures pour arriver à comprendre ce que fait cette méthode, "long method" pose 2 problèmes d’architecture :

• partage de logique : souvent dans 2 méthodes longues, voire au sein de la même, on retrouve du code dupliqué

• maintenance : qui peut garantir qu’il se souviendra de ce que font exactement les 400 lignes de codes plusieurs mois après

Lorsqu’on jette un oeil à des frameworks tels que le Zend Framework en PHP ouHibernate en JAVA, il est plaisant de constater que beaucoup de méthodes ne dépassent pas 10 à 20 lignes et que les noms choisis sont explicites. En parcourant le code d’une classe, on comprend instantanément son fonctionnement.

Evidemment personne n’est là pour fixer un nombre maximum de lignes par méthode. Personnellement je pense que le nombre optimal se situe entre 30 et 40.

Comment procéder pour réduire la taille du contenu d’une méthode ?

Le cas le plus simple

La méthode se contente d’appeler une longue série d’instructions, utilisant des variables locales et renvoyant un résultat.
Dans ce cas, le pattern Extract Method qui propose de découper le contenu en sous ensembles de code, suffira à simplifier la méthode. L’attention doit être portée sur le nom 
des "sous-méthodes", afin qu’il soit le plus explicite possible. Attention à leur portées. Dans la majorité des cas, ces méthodes extraites doivent être privées. Inutile d’exposer du code inutilement.

Ma méthode concatène des informations dans une variable avant de la renvoyer

On observe souvent ce genre de choses dans du code manipulant des chaînes de caractères, ou des tableaux. Tout le contenu de la méthode accumule des données.
Une solution est d’adopter le pattern "move accumulation to collecting parameters".

Identifier la variable qui collecte les données, puis extraire des sous-méthodes qui prennent en paramètre cette variable et qui contribuent à son "remplissage".

Ma méthode contient un switch énorme (aussi appelé râteau) pour traiter les données ou appeler d’autres codes

Nicolas le jardinier doit être content. Cependant, nous, développeurs que nous sommes préférons les patterns "command dispatcher" ou "Strategy".
On peut trouver ces "conditional statements" dans des codes d’analyses numériques qui appellent un algorithme en fonction de paramètres d’entrées, ou bien dans des servlets ou des contrôleurs qui traitent les requêtes http avant de les dispatcher.

Que se passe-t-il si on souhaite rajouter une nouvelle logique ? Et bien il faut modifier le switch appelant. On se retrouve alors avec un couplage fort entre les composants.

Les patterns command et strategy, proposent de déléguer à des classes ou des méthodes ces différentes logiques. L’instantiation se fait dynamiquement, par réflexionou via une factory. Rajouter une nouvelle logique revient alors à rajouter une méthode ou une classe, sans toucher à la méthode appelante. Bien utilisé, ce pattern permet d’étendre des fonctionnalités d’un code dont on ne dispose pas des sources.

De tous les design smells, je considère celui-ci comme l’un des pires pour la compréhension, la maintenance, les tests, et la réutilisabilité (je viens d’inventer un mot ?) du code.

Ces quelques recettes devraient permettre de réduire la taille des méthodes de classe, dans la majorité des cas. Je suis preneur de cas particuliers qui ne seraient pas résolus par les patterns évoqués ci-dessus. A vos claviers !

 Un pas de plus franchit par Amazon dans son offre de web services. Après Amazon EC2 etAmazon S3, voici Amazon SimpleDB, un service de requêtes temps réel sur des données structurées.

En d’autres mots, il s’agit d’offrir un système de base de données non relationnelles accessible par un jeu de web services. L’objectif est de faciliter la vie des éditeurs en les affranchissant d’opérations complexes liées à un cluster de base de données.

Comment ça marche ?

Amazon SimpleDB ressemble plus à une feuille Excel qu’à une instance Oracle. Les données sont organisées par domaines, caractérisées par des attributs (paires clef=>valeur) et indexées automatiquement. Sympa quand on voit le nombre d’années d’expérience qu’il faut pour créer un schéma SQL de données optimisé.

Les domaines sont accessibles via http en lecture / écriture pour insérer, modifier, effacer et rechercher des données.

Les avantages :

1- Couplé à EC2 et S3, ce service complète la boîte à outil Amazon. Les éditeurs disposent donc d’un hébergement entièrement élastique (scalable). Inutile de dimensionner des cluster de base de données complexes à administrer.

2- Le modèle économique est toujours le même : on ne paye que les heures d’utilisation et les données transférées.

3- Enfin, l’API accessible via REST ou SOAP est d’une simplicité exemplaire :

Création du domaine :
https://sdb.amazonaws.com/
?Action=CreateDomain
&AWSAccessKeyId=[valid access key id]
&DomainName=MyDomain
&SignatureVersion=1
&Timestamp=2007-06-25T15%3A01%3A28-07%3A00
&Version=2007-11-07
&Signature=hvH87q32QzGbDba6bm9YUEVpiGQ%3D

Insérer des données :

https://sdb.amazonaws.com/
?Action=PutAttributes
&Attribute.0.Name=Color&Attribute.0.Value=Blue
&Attribute.1.Name=Size&Attribute.1.Value=Med
&Attribute.2.Name=Price&Attribute.2.Value=14.99
&Attribute.2.Replace=true
&AWSAccessKeyId=[valid access key id]
&DomainName=MyDomain
&ItemName=Item123
&SignatureVersion=1
&Timestamp=2007-06-25T15%3A03%3A05-07%3A00
&Version=2007-11-07
&Signature=gabYTEXUgY%2Fdg817JBmj7HnuAA0%3D

Rechercher des données :

https://sdb.amazonaws.com/
?Action=Query
&AWSAccessKeyId=[valid access key id]
&DomainName=MyDomain
&MaxNumberOfItems=3
&NextToken=[valid next token]
&QueryExpression=%5B%27Color%27%3D%27Blue%27%5D
&SignatureVersion=1
&Timestamp=2007-06-25T15%3A03%3A09-07%3A00
&Version=2007-11-07
&Signature=2wVXB1x0NSWWETwLylZPVP%2FtqXQ%3D

Difficile de faire plus simple.

Les inconvénients :

1- Ce qu’il manque dans SimpleDB, c’est l’aspect relationnel. Donc pour ceux qui ont des modèles complexes basés sur des données fortement liées (jointures), oubliez :(

2- Comme les autres services Amazon, sur des configurations minimales (1 serveur, 1Go de ram) qui n’ont pas besoin d’être étendues ponctuellement, cette offre est moins compétitive que chez les autres herbergeurs. Donc si vous êtes sûr de n’avoir besoin que d’un seul serveur, oubliez aussi :(

Je pense qu’en cette période de Noël durant laquelle le trafic e-commerce explose, cette offre peux permettre aux éditeurs de tenir la charge sans engager trop de dépense d’infrastructure.

Je prend l’exemple d’un service de création d’e-card qui offre un espace de stockage des cartes générées. C’est certain qu’en cette période de fêtes, le nombre de fichiers et des méta données associées va croitre très vite et  énormément.

Pour tenir la charge, il faut augmenter le nombre de nœuds du cluster de base de données, augmenter la bande passante des serveurs frontaux, augmenter les espaces de stockage physiques. Tout cela à un cout non négligeable en infrastructure et en personne (DBA, administrateurs systèmes).

Grâce aux services Amazon, en quelques clic, il est possible de créer de nouveaux domaines SimpleDB (chaque domaine contient 10Go de données), de nouveaux nœuds S3 pour le stockage de fichiers. Et le plus important, c’est qu’une fois la montée en charge résorbée, les instances qui ne sont plus nécessaires peuvent être éteintes. Qu’en est il du DBA qui vient d’être embauché ?

 De retour après un marathon gastronomique, je décidai de faire le ménage dans monMac afin de démarrer l’année 2008 (qui promet d’être enrichissante vue la roadmap de notre produit) sur des bases saines.

Et comme on est à l’heure du bilan, je me pose la question existentielle suivante : quel éditeur choisir pour mes développements ?

Vi, Emacs, Eclipse, Zend Studio, TextMate … Entre tous mon cœur balance. J’en ai un certains nombre d’installés mais il est difficile de passer constamment de l’un à l’autre - oui je n’ai pas beaucoup de mémoire, je ne peux pas retenir tous les raccourcis claviers-

Voila mes exigences.

1) Légèreté (1Go de RAM pour un IDE, ça fait beacucoup)
2) Coloration syntaxique pour tous les langages que j’utilise : php5, JAVA, javascript, html, css, SQL, wsdl, xml 
3) Complétion automatique sur les librairies natives des langages ET sur le code du projet
4) Navigation dans les sources (un click sur le nom d’une classe ou d’une méthode ouvre le fichier la définissant) 
5) Recherche performante

Textmate est probablement l’éditeur le plus complet en terme de support de langages mais la complétion auto et la navigation automatique dans les sources sont fastidieuses.
Le plugin standard php n’est pas satisfaisant. La complétion ne prend en compte que la librairie PHP et non le code du projet, ce qui pose problème pour naviguer dans ses propres classes. La recherche dans un projet n’est pas toujours très performante.
Néanmoins j’aime beaucoup sa légèreté et l’interface épurée.
Si quelqu’un connaît le killer addon PHP pour TextMate, je suis preneur !! Sinon, pour éditer simplement un fichier, c’est très bien. C’est d’ailleurs TextMate que j’utilise pour rédiger les billets de mon blog.

Zend Studio est excellent pour le développement PHP (pas étonnant vu l’éditeur du soft). Complétion auto, navigation dans les sources intuitive, intégration d’un debuger, intégration CVS, SUBVERSION… Certes l’environnement est lourd, mais il fonctionne très bien. Je le conseille donc, même s’il manque tout de même des outils intéressants pour le développement logiciel : refactoring, test unitaire.

Eclipse est tout simplement magique quoi qu’aussi un peu lourd (pas de RAM pas d’eclipse). Dans un environnement J2EE, j’apprécie beaucoup les outils de refactoring, et tous les plugins Hibernate, Struts, Stripes, SOAP… qui en font un RAD surpuissant.

Mais qu’en est il pour le PHP ?

Zend a sorti récemment Zend Neon, qui est un portage du Zend Studio sur la plate-forme de développement Eclipse. Alors attention les yeux, voilà ce qui est dis sur le site de Zend :

* Facilitez le développement et la collaboration en équipe en gérant efficacement votre code source grâce à l’utilisation de CVS ou Subversion directement depuis Zend Studio “Neon”
* Modification transparente des différents éléments PHP avec l’outil de refactoring robuste qui permet aux développeurs de visualiser les informations avant d’appliquer les modifications.
* Support de PHPUnit pour le développement agile.
* Documentez facilement votre code, vos applications et vos projets avec PHPDocumentor, l’outil standard de documentation pour PHP
* Recevez un retour d’information immédiat sur la performance du code et des scripts en utilisant les outils de QA et de test
* Listes de tâches pour gérer les actions à réaliser
* Développement HTML en WYSIWYG (beurk !!! mais certains aiment)
* IDE SQL

Il y a ici un comparatif entre Neon et les PDT (php development tool for eclipse).

And the winner is…Neon !  Et oui, cet IDE comblera bon nombre de développeurs PHP, même ceux qui codent aussi sur d’autres langages. La communauté open source autour d’eclipse, permet d’ajouter un nombre de plugin quasi infini (reverse engineering de base de données, UML, gestion de mail…)

Je crois donc que ce sera mon IDE 2008.

Mais je ne renonce pas à mes 2 éditeurs poussiéreux. En effet j’ai toujours été un grand fan de vi et emacs car ils sont à mon sens les plus performants et les plus légers. La possibilité de développer des plugins en LISP pour emacs le rend très ouvert. Mais, sur des projets lourds, il est très difficile d’être aussi productif qu’avec un IDE.
Je garde donc mon vi pour l’administration système ou pour des corrections rapides sur un fichier.

Et vous ?

 

 Une fois par mois va se dérouler un Altaide Dev Drink, organisé par … Altaide.

Il s’agit d’une sorte de bar camp durant lequel un intervenant technique expose le sujet de son choix.

J’ai eu la chance d’inaugurer cet évènement Jeudi dernier, pour parler de l’utilisation dePHP au sein d’une architecture orientée service.

Gartner prédit que d’ici 2008, 60 % des entreprises auront commencer à migrer leurs applications sur cette nouvelle architecture.

Il me paraissait important de montrer d’une part que penser SOA permettrait de faire converger la multitude de services qui fleurissent chaque jour sur le web, et d’autre part que la technologie la plus utilisée dans le web aujourd’hui permet de passer ce virage, et donc envisager une interopérabilité avec les applications externes.

Notamment grâce à des framework solides tel que la très bonne implémentation de SCA / SDO qui permet de développer des services PHP indépendant du protocole de transport (soap, REST-RPC, XML-RPC, JSON-RPC …).

La présentation a duré une heure et les feedbacks ont été assez bons. Exemple sur le blog de William Peres ou ici.

Pour ceux que ce sujet pourrait intéresser, je met le la prez en pièce jointe.

Et pour mes fans, il paraît qu’une vidéo est en cours de montage…

Alors, les développeurs PHP, quand allez vous passer aux SOA ?

Après tant de temps passé sur le Net et en travaillant chez un éditeur de logiciel 2.0,blueKiwi Software, je me devais de créer mon blog.

Et pour commencer, il parait qu’il faut se présenter. Je m’appelle Alexandre Heimburger et je suis responsable R&D chez blueKiwi Software.
J’ai travaillé 4 ans chez Dassault Sytemes et 1 an chez FullSIX.

Je suis passionné par le développement logiciel  (programmation objet, SOA, design pattern) et par Internet, surtout depuis le virage 2.0.

Ce blog traitera donc de sujets techniques autour du développement, d’usages et de veille sur tout ce qui touche au web et surement d’autres choses…moins sérieuses.