Publié par

Il y a 9 années -

Temps de lecture 6 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

RIA

Le coin de la technique

Agilité

Convaincre votre MOA de passer aux méthodes Agiles

Dans un récent article, Alexandre Boutin explique comment convaincre une MOA de s’intéresser à l’agilité.
La démarche d’Alexandre a été de demander à la MOA de répondre à un questionnaire reprenant les divers problèmes habituellement rencontrés :

  • difficultés à définir le besoin fonctionnel et à maîtriser son évolution au cours du temps,
  • délais importants entre chaque version et effet tunnel pendant les périodes de développements,
  • les versions se terminent généralement avec du retard,
  • communication avec la MOE,
  • la productivité n’est pas au rendez-vous.

Ce questionnaire ayant permis à la MOA de mettre le doigt sur des problèmes récurrents, Alexandre présente les avantages que vont apporter l’utilisation des méthodes agiles dans leur travail :

  • meilleure communication et visibilité sur le travail de la MOE,
  • livraisons fréquentes à dates fixes d’un produit démontrable et fonctionnel,
  • amélioration de la productivité.

Alexandre termine par préconiser un accompagnement pour se former et passer aux méthodes agiles le plus rapidement et le plus efficacement possible.

L’adoption d’une méthode de travail (agile ou non) par l’ensemble des acteurs d’un projet est fondamentale. Il est en effet compliqué pour une MOA de travailler avec des méthodes différentes de celles employées par la MOE. Cela génèrera immanquablement des problèmes de communication entre les deux parties.
Convaincre une MOA de changer ses habitudes de travail n’est pas chose aisée, et le questionnaire proposé par Alexandre Boutin (potentiellement agrémenté en fonction des spécificités du contexte du projet) peut-être un bon moyen de déclencher le besoin de changement.
L’adoption d’une méthode agile n’est pas sans contrainte, mais un bon coach agile saura mettre en avant les bénéfices de l’agilité pour combler les lacunes de l’ancienne méthode.

RIA

Sortie de SproutCore 1.0

Les frameworks HTML5 continuent de se mettre à jour. Et après 52framework, c’est au tour de SproutCore de sortir en release majeure (version 1.0, information relayée ici).

InfoQ a récemment réalisé une interview de Charles Jolley (CEO de Sproutit) concernant SproutCore.
On y apprend ainsi que le framework gère certaines fonctionnalités d’HTML5 (comme l’offline storage ou le nouveau tag video) et qu’il est possible d’intégrer du code existant jQuery, ExtJS, YUI ou bien encore Prototype.
Il explique aussi les raisons principales de la migration, côté vue, de Ruby à JavaScript. La première est l’arrivée prochaine d’un Drag & Drop UI Designer (facilitée par les APIs JavaScript) et la seconde pour des raisons de performances (jusqu’à 10 fois plus rapide que la version précédente !).

Rendez-vous sur cette page pour une petite démonstration de SproutCore et sur celle-ci pour le téléchargement.

Le coin de la technique

Commenter son code: jusqu’où aller ?

Rebondissant sur une discussion qu’ont eu des programmeurs .Net de Seattle, InfoQ publie un article sur l’intérêt de commenter (ou non) son code. Le sujet, tel un éternel serpent de mer, donne toujours matière à discussion. A tel point que les interventions des lecteurs, à la suite de l’article, sont des plus intéressantes !

Le consensus semble être que les commentaires sont à éviter au maximum car le code se doit de s’auto-documenter: sans commentaires, et seulement avec le nom des méthodes et des variables, nous devons être capable de le comprendre. Ainsi, pour Thiébaut Champenier, il y a 2 types de commentaires:

  • Les commentaires documentant l’API (notés /** */ )
  • Les commentaires dans le code (notés /* */ ou // ) qui doivent un maximum décrire pourquoi le code existe plutôt que comment le code agit.

Alex Suvorov ajoute qu’une suite de plusieurs opérations successives nécessitant un commentaire devrait plutôt être extraite en une fonction nommée de manière explicite. Tim Linquist, lui va même plus loin en souhaitant disposer d’une fonctionnalité lui permettant de sortir les commentaires du code une fois la documentation (javadoc) générée. Pour contrebalancer ces avis, la palme du meilleur commentaire revient à Pete Haidinyak. Celui-ci se permet une suggestion amusante destinée à toutes les personnes « qui ne commentent pas leur code ou qui pensent qu’un commentaire toutes les 10000 lignes est suffisant ». Il leur demande de rajouter un en-tête dans leur code spécifiant: « A toute personne chargée de maintenir ce code: si vous ne comprenez pas mon code ou êtes troublé par mon style, n’hésitez pas à m’appeler à toute heure, nuit et jour, au numéro suivant: { numéro_de_téléphone_du_développeur }. Je vous expliquerai ce que j’avais en tête lorsque j’ai écrit ce code ». L’idée est bonne, avec un tel en-tête, les développeurs risqueraient de se soucier un peu plus de la façon dont les autres peuvent comprendre leur code !

Où l’on reparle de la JSR-310

La JSR-310 (Date and Time API) était initialement prévue pour le JDK 7 mais il y a un an, la roadmap de Sun l’en excluait. Cette spécification était pourtant attendue par tous ceux qui étaient lassés par les défauts de java.util.Date et qui voyaient en Jodatime (dont la JSR-310 est largement inspirée) une échappatoire tentante. L’API proposée par cette JSR est en effet beaucoup plus riche et permet de représenter tous les concepts d’instants et de durées.

Lors de l’annonce du report du JDK 7 en novembre dernier, Mark Reinhold avait laissé la porte ouverte aux fonctionnalités qui avaient été abandonnées faute de temps ; la JSR-310 en faisait partie. Courant février, questionné sur cette spécification par un spectateur d’un webcast, il disait regretter qu’elle n’ait pu être finalisée dans les temps. Dans le même temps, Stephen Colebourne, spec lead de la JSR-310, expliquait sur son blog qu’il disposait désormais de temps libre pour travailler sereinement sur cette spécification. Quelques semaines plus tard une early draft review voyait le jour. Enfin, il y a quelques jours, Stephen Colebourne répondait à un commentaire en disant que l’inclusion de la JSR-310 dans le JDK 7 dépendrait de sa finalisation et de la volonté de Sun/Oracle.

La saga de la JSR-310 semble donc renaître de ses cendres et la possibilité de son intégration au prochain JDK est bien réelle. L’affaire est donc à suivre…

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

5 réponses pour " Revue de Presse Xebia "

  1. Publié par , Il y a 9 années

    C’est vrai qu’il n’est pas rare de devoir revenir sur du code écrit par d’autres, et non commenté, notamment pour corriger des bugs. Dans ces cas là, il me semble que les fonctionnalités d’historique des SCM sont essentiels pour comprendre le contexte.

    Je pense par exemple à la vue « Team > Show annotation… » dans Eclipse, qui permet de visualiser immédiatement les différentes modifications réalisées par les différents acteurs au cours du temps.

    En général, je passe plus de temps à analyser le contexte et comprendre ce qu’a voulu faire l’auteur, qu’à corriger le bug…

  2. Publié par , Il y a 9 années

    Un jour, un professeur d’algorithmique m’a dit que le commentaire était le début de l’échec. Si on a envie de commenter, on ferait mieux de refactorer. Il avait tellement raison. Le commentaire est bien trop utilisé comme une béquille pour un code bancal.

  3. Publié par , Il y a 9 années

    C’est le même Pete qui dit dans un commentaire plus loin « I’m not one of those programmers who will artificially add a method call just to keep the calling method within a certain size limitation. Sometime a method can be complex and parts will run off the screen (even on my 30″ monitor), and I have found the ending brace comments a quick way to see where I am at without using the IDE to highlight the top.  »

    Pas étonnant qu’il ait besoin de beaucoup de commentaires !

  4. Publié par , Il y a 9 années

    Lorsque je reprend un code, je ne lit pas les commentaires. Et ce, depuis que je me suis rendus compte que les commentaires était souvent obsolètes, imprécis, incomplet, mal écrit, et faisait perdre plus de temps à être lus qu’ignorés.

    Pour comprendre un existant mal fichu, rien de mieux que de faire l’exercice d’écrire un test unitaire « passant » dessus. Une fois le bout de code maitrisé, on refactorise !

  5. Publié par , Il y a 9 années

    lol, j’aime beaucoup la suggestion de Pete ! mais c’est pas forcément un exemple à suivre s’il fait des méthodes de 1000 lignes sans refactorer !
    mais je considère que les commentaires sont nécessaires. bien sûr autant que possible, le code se doit d’être auto-documenté (bien choisir ses noms de variables, etc) mais comme vous le dites très justement dans cet article, c’est le pourquoi qui est intéressant à mettre dans les commentaires, car c’est souvent très difficile de le comprendre juste à partir du code. Il n’y a que ceux qui n’ont jamais maintenu du code qui peuvent prétendre le contraire (comme les professeurs d’algo ;) ) !
    c’est vrai que beaucoup de développeurs commentent mal : ils commentent parce qu’on leur demande de commenter mais comprennent pas le but (et s’en fichent) alors ils décrivent ce que fait la méthode…ce qui n’est pas très intéressant puisqu’on peut le déduire assez rapidement à partir du code.
    Mais quelques bons commentaires permettent d’éviter de perdre des heures à comprendre « pourquoi » une méthode fait telle chose, sans avoir à regarder l’historique SVN ou écrire un test unitaire (d’ailleurs si le test unitaire, il ne permettra pas de comprendre le « pourquoi ». éventuellement un test fonctionnel ?)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.