Même si le langage reste très strict et fortement typés, certains outils ont réussi a le rendre flexible dans les méthodes de développement.

Maven

Si je dis que c’est une évolution de Ant, je vais me faire trucider et créer une guerre de religion . Cet outil m’a permis de plus facilement structurer mes programmes. Déploiement automatique, test unitaire, Maven crée un squelette qui permet facilement de gérer tout le “cycle de vie” d’une application. Le système de dépendance (repris par Ivy) est plus qu’appreciable . Le genre d’outil que j’affectionne particulièrement. Une ou deux lignes de code et tout fonctionne parfaitement, peut importe la plateforme

GWT

Je sais que le Google Web Toolkit ne fait pas partit intégrante d’une application Java mais il faut avoué que sur ce coup là, Google a fait fort. Plus qu’un outil de transcodage Java->JavaScript, les différents design pattern (comme MVP) qui sont proné dans GWT m’ont permis de faire un bon spectaculaire dans ma manière de coder.

Guice

N’étant pas particulièrement fan des fichiers de conf en XML et n’étant pas habitué a Spring, je trouve que Guice a toutes les fonctionnalités pour faire de l’injection de dépendance en Java, simple et efficaces .

Sonar

Il est toujours bon de développer avec une boussole, savoir où on va. Sonar permet d’avoir des indicateurs de qualité de code. Un petit “mvn sonar:sonar” sur un projet maven et zou ! On a une ribambelle d’indicateurs et le résultat des tests unitaires dans une interface vraiment très pratique.

Sculptor

Si vous ne connaissez pas le concept de “MDA“, ce n’est pas bien grave. Sculptor vous permet de définir votre “model” et de générer toutes les parties de codes rébarbatives au possible.

Génération de code EJB3, JPA, Spring et même GoogleAppEngine . Une fois correctement maitrisé, il vous fera économiser de nombreuses heures

Voici les “réponses” les plus fréquentes.

Pourquoi changer ? ça marche

Pourquoi changer ? C’est une bonne question et elle n’est pas si stupide que ça.

Vous avez déjà vu un ou deux stagiaires qui ont voulus optimiser un code backdoor qui n’est quasiment jamais appelé. Passer de 513ms a 437ms sur un code qui est appelé dans un CRON tout les mois… ça n’a pas forcément un grand intérêt. Mais il faut se poser quelques questions:

• Dois-je modifier ce code souvent ?
• Ce code est-il appelé dans une boucle haptique a 1000Hz ?
• Est-ce que ma fonction ressemble plus a une boite noire qui des fois me retourne des résultats “mystique” ?

Si vous avez répondu “oui” a une seule de ses 3 réponses, OUI ! Il faut changer !

solution: Expliquez que la machine à vapeur ça marche aussi et pourtant…

On avait pas le temps

C’est la vie ! Dans une boite (une vrai comme nous), on nous demande des trucs et on a pas le temps de faire comme à l’univ !

HAHAHAHA, celle là me fait bien rire . On a pas le temps de reviewer un peu son code mais on a la temps de rester 3 jours jusqu’a minuit juste avant la prod ! Là on peut bosser !

Le temps ça se trouve. La plupart des entreprises devrait fixer un créneau horaire pour revoir et remanier le code existant. Le temps passé a faire cela serait largement gagné sur les phases de debugging.

solution: expliquez que ranger sa chambre tout les jours c’est moins chiant que de le faire une fois par an juste avant que maman passe en foutant tout sous le lit.

C’est pour optimiser

Il y a un petit coté “humain” derrière cette excuse. “J’aurais bien voulu mais c’est pas possible”.

Tout d’abord si la personne qui vous dit ça fait autre chose que du C ou C++ vous pouvez directement lui jeter des pierres. On “optimise” pas un code PHP ou Ruby en faisant du code crade. A partir du moment ou on ne sait pas comment l’interpréteur/compilateur fonctionne derrière. Le fait de tout mettre dans une fonction ne vous fait faire que des économies de bout de chandelles.

Le soucis d’optimisation pouvait s’expliquer encore il y a quelques années avec des machines plus lentes mais maintenant les machines sont suffisamment puissante.

Les solutions actuelles pour gérer de gros volumes de données se font surtout par des clustering/cloud car les processeurs ne montent plus en puissance mais en nombre. Il y a de forte chance pour qu’un code “optimiser” à l’ancienne ne puissent pas être réutiliser sur un cloud.

solution: proposez de multi-threadé le code comme ça il sera encore plus performant ;). Les autres dev n’auront plus l’excuse de l’optimisation.

C’est trop compliquer, on peut pas faire autrement !

“Il y a trop de vérification a faire, on a besoin de ces 34 if/else imbriqués”.

Souvent les collègues se cachent derrière l’excuse du “trop compliqué”. C’est vrai que c’est facile. Le code est compliqué a lire on en déduit que ce que le code fait est… compliqué.

Si je pars sur l’exemple du “34 if/else”, on peut se poser la question “si c’est une vérification, ce code ne devrait t’il pas être déporté dans une classe Validator ?”. Sémantiquement, les “34 if/else” sont-il dissociable ?

Un problème infiniment complexe n’est que la somme d’une infinité de problème simple

J’aime me dire que tout problème aussi compliqué soit-il peut être résumé par une somme de problème simple à comprendre.

Partant de ce principe, le code aura surement beaucoup plus de classe et pourra peut être effrayé des personnes de passé d’une classe statique a une douzaine de petite classe mais pour autant le code sera beaucoup plus simple et raisonné.

solution: expliquez qu’un code complexe peut être subdivisé en code plus simple.

Quelques “autres” excuses bidons envoyés par twitter

• cette appli a pas loin de 7 ans, on va pas s’amuser à tout reprendre maintenant !
• mais si, c’est bien codé, toi tu sais !
• w3c c’est pour les low
• je mets pas de commentaire parce que j’ai peur de pas comprendre ce que j’ai voulu dire

N’hésitez pas a en laisser en commentaire

J’ai envie aujourd’hui de vous faire partager un certain nombre de choses dont je me rend compte en même temps que je commence a perdre mes cheuveux .

La réutilisabilité.

Ahhh la jeunesse, la fac ! Quel nostalgie !

Je me souviens a chaque fois que j’avais une idée d’amélioration dans un programme, je reprogrammais TOUT. Repartir d’un projet vide et tout refaire pour atteindre le code “ultime”, celui qui sera maintenable et rapide à la fois.

Mais voilà… en prenant de l’age. Il n’y a plus maman pour faire les courses, la vaisselle, la lessive et du coup il y a forcément moins de temps pour dev. Alors forcément, si j’ai quelque chose qui marche, j’ai pas très envie de réinventer la roue (surtout carré).

Oui mais j’ai fait ça il y a 2 ans !

N’étant pas un fervent défenseur de la javadoc, phpdoc ou autre joyeuseriedoc, je ne documente pas beaucoup mon code (PÔ BIEN !!!) mais je fais des tests unitaires. Si j’avais un conseil a vous donnez, faites des tests unitaires au moins vous aurez un vague souvenir de ce que fais chaque fonctions .

A partir du moment ou mes tests unitaires passent, je considère que mon code “fonctionne”. Il n’est surement pas parfait mais je ne vais pas le changer tant qu’il

• n’est pas horriblement lent
• n’a aucun bug detecté

Et puis… le code a t’il besoin d’être parfait ? Injection de dépendances, Design pattern, Meta modèle, les concepts en informatiques fleurissent tellement que le temps de finir un projet, techniquement il est déjà dépassé . Il faut vivre avec son temps mais cela ne sert a rien de modifier quelque chose qui marche et qui semble “plutôt” maintenable.

Ouh là… mais c’est en PHP4 !

Avec le temps, on apprend aussi de nouveau langage. Basic, Delphi, C++, PHP, Python, Ruby, Java… c’est qu’on aime expérimenter un peu tout. Il faut aussi avouer qu’il serait un peu bête de ne pas utiliser le langage le plus approprié pour la tache. Je ne m’amuserais pas a faire une appli web en C++ ni a faire un programme en PHP/QT.

Mais comment réutiliser du code d’un autre langage ? C’est très simple, en utilisant une interface.

Le mot “interface” ici est a prendre au sens large. Que ce soit du xmlrpc, une page en JSON ou une exécution dans le langage actuel avec une glue quelconque (je pense a python avec des dll ou java avec jython, jruby), l’important ici est d’utilisé une technique de communication “standardisée”.

Mais le mot “interface” est aussi a prendre au sens propre d’un langage de programmation. Plus vous aurez d’interface définis, plus il sera facile de changer son implémentation par la suite.

Souvent on me regarde de travers quand je dis “on peut faire du code bien crade si l’interface est propre“. Peut importe d’avoir un bout de programme en TCL/TK tant que son utilisation dans le programme principal reste transparente et que cette brique puisse être interchangeable.

Concretement cela donne quoi ?

Si j’ai eu l’idée de faire ce petit post c’est parce qu’actuellement j’ai 2 projets en parallèles que je traine depuis un moment et où je suis très content de réutiliser le code existant.

Le premier c’est scrutator où une partie du code serveur est en PHP. Même si la nouvelle implementation est en python twisted, la couche de sauvegarde s’effectue en XML-RPC et utilise toujours l’ancien code de sauvegarde. Une partie de l’ancienne logique de déploiement repose toujours sur du code PHP mais elle a tendance au fur et a mesure a disparaitre.
Le fait d’avoir décidé de réutilisé une partie de mon code PHP m’a facilement fait gagné 2 a 3 semaines de développement. La logique de déploiement disparaitra mais la sauvegarde se fera a mon avis toujours par la couche PHP qui reste robuste.

Le 2ème c’est MyLibrary. Je suis en train de réfléchir a le refaire en GWT. Ici aucun intérêt a changer la couche de sauvegarde et de requête sur Amazon. Je pense développer une couche en JSON pour dialoguer avec PHP. L’interface de sauvegarde risque ensuite de s’améliorer par la suite pour surement utiliser la sauvegarde PHP et Google Gears.

Ne pas faire de programmation spaguetti

Oui il faut réutiliser ! Oui on peut réutiliser du code imbuvable ! Mais attention a ne pas faire n’importe quoi non plus. Vous devez garder le contrôle.

Rien ne vous empêche de faire des tests unitaires dans votre nouvelle implémentation (en java par exemple) pour vérifier que votre ancienne implémentation (en PHP) fonctionne toujours.

Il faut aussi éviter de réutiliser un code qui utilise lui même un code déjà recyclé. Utiliser du code Perl dans un programme PHP qui est repris en Python… Il serait peut être un peu temps de se remettre en question et de voir si tout est réellement nécessaire.

En conclusion

Pour réutiliser son code il y a quelques règles simples à suivre.

1. Assurez qu’il est facile de se replonger dans le code. Tests unitaires, exemples, doc automatique, il y a bien des moyens de faciliter la reprise d’un code existant. Personnellement je préfère les tests unitaires qui assureront aussi des tests de régressions, de plus ils doivent en théorie être complet et donc utiliser toutes les interfaces ceux qui vous permettra de vous souvenir des entrées/sorties de chaque fonctions.
2. Faites des interfaces ! Il faut en faire le plus possible. Des interfaces sont nécessaire pour chaque partie “clé” de votre code.
3. Ne pas être perfectionniste. Pourquoi refaire un code qui marche alors que votre implémentation actuelle fonctionne correctement et qu’il n’y a pas d’évolution prévu pour cette partie de code ?

En espérant que cela vous aidera a faire du très bon recyclage