Devoxx – Productive Programmer

Neal Ford nous présente pour cette première session des University, les bonnes pratiques issues de son livre Productive Programmer. Ce livre couvre les habitudes et les bonnes pratiques à adopter en tant que développeur.

Accélération

Taper au clavier est bien plus rapide que la navigation avec la souris. On perd beaucoup de temps à chercher alors que les raccourcis clavier sont bien plus rapides. Chaque OS fournit ses raccourcis claviers pour ouvrir l’explorateur Windows ou le Finder. Pour naviguer sur internet, utilisez NumberFox, il numérote les liens sur les pages et permet en saisissant un numéro d’accéder à la page associée. Pour la gestion du presse papier, utilisez par exemple jumpcut sur MacOS X qui permet de visualiser ce que vous avez coupé ou copié avec un historique des données. Le changement de contexte prend du temps également, surtout en ligne de commande. Avec les commandes pushd/popd, vous pourrez mémoriser un répertoire avec pushd pour le réutiliser ensuite à tout moment avec popd.
Lignes de commande ou explorateur ? Les explorateurs sont intéressants dans certains cas, les lignes de commandes dans d’autres. Pour switcher facilement de l’un à l’autre, vous pouvez utiliser cmd prompt explorer bar pour Windows et Path Finder pour Mac OS X. Ils proposent dans une même fenêtre la console et l’explorateur.
Quand vous codez, vous devriez toujours utiliser le clavier plutôt que la souris. Forcez vous à apprendre les raccourcis clavier. Un outil existe sur IntelliJ pour forcer les développeurs à utiliser un raccourci clavier, au bout de la troisième utilisation la fonctionnalité se grise dans le menu. Les conseils : se les répéter et se créer un aide mémoire. Accédez directement à la classe que vous cherchez par les raccourcis clavier et en utilisant les majuscules. Prenez l’habitude de créer les variables avec votre EDI. Bien que destiné au refactoring, vous pouvez aussi l’utiliser en ne déclarant que la partie gauche de la déclaration et générer le reste.

Focus

Pour commencer, il y a des choses simples à mettre en place : une chaise confortable, un double écran, les droits admin sur son poste et un bon clavier. Ensuite la concentration doit être total. Pour être productif, il faut supprimer toutes distractions tels que les pop-ups Windows de mis à jour ou autres notifications. Il existe par exemple Jedi Concentrate qui permet de mettre en noir toutes les fenêtres pour se concentrer sur une en particulier le plus longtemps possible. Désactivez toutes les notifications d’emails et de messageries instantanées, mettez des écouteurs et créez des « moments de silence » dans votre bureau.
L’idée n’est pas de s’isoler des autres mais de créer des conditions idéales à la concentration.

Focus technique

Utilisez un outil de recherche tel que Google Desktop Search pour rechercher sur votre poste au lieu de naviguer dans votre explorateur. Utilisez un virtual desktop pour séparer votre espace de travail du reste. Cela permet d’éviter l’empilement de fenêtres sur un unique bureau.

Canonicité

Faire les choses simples en évitant les répétitions. Neal Ford a un sigle de référence : DRY (Don’t Repeat Yourself).

• DRY o/r mapping : il s’agit d’une tâche assez répétitive dans le développement d’application. Optimisez la partie mapping avec la base de données en construisant celui-ci à partir des méta-données en base. Puis générez les POJOs correspondant.
• DRY documentation : Neal Ford a utilisé SVN2Wiki un petit utilitaire de SVN qui relève tous les commentaires de commits des développeurs pour les aggréger dans un wiki.

Automatisation

Les aspects visiblement automatisables sont le build en une commande, l’intégration continue, le contrôle de version et la documentation. Il recommande Selenium pour les tests automatisés. Ce dernier permet au développeurs de tester plus rapidement les applications suite à une modification.
Sa philosophie est : « Ne perdez plus de temps à faire à la main ce que vous pouvez faire automatiquement ».
Pour déterminer si une tâche est automatisable ou pas, il faut mesurer le temps qu’elle prend et analyser le retour sur investissement. Il faut éviter également d’en faire trop.

Pratique

Neal Ford nous propose ensuite 10 bonnes pratiques pour améliorer notre productivité et notre qualité de code.

1. Pattern Composed Methods

Celui-ci est directement tiré du livre Smalltalk Best Practice Patterns de Kent Beck. L’idée est de diviser son programme en plusieurs méthodes, chacune ayant un et un seul rôle bien défini. De même, chaque opération dans la méthode devra avoir le même niveau d’abstraction. Le résultat : des méthodes avec un rôle précis écrites en très peu de lignes de code. Cela a pour avantage de favoriser et simplifier les tests unitaires. Cela permettra aussi de vraiment mettre en avant la vraie réutilisabilité du code.

2. TDD

Couplé avec le pattern Composed Methods, TDD nous oblige à réfléchir à notre design objet, à définir de quels objets dépend mon objet et ainsi à mocker ces objets dépendants. Un premier constat est que l’on obtient très souvent de meilleurs métriques de manière globale.

3. Analyse de code

Les outils d’analyse de code, ce n’est pas quelque chose de nouveau. Mais un petit rappel ne fait jamais de mal :-) Passer par ce type d’outils va nous permettre de détecter des bugs de type mauvaise pratique, code mort ou bien encore du code violemment copier-coller. 2 types d’analyse :

• byte code : à l’aide de FindBugs qui nous range nos bugs par catégorie comme la mauvaise pratique, le problème de performance ou du code douteux ;
• source code : par PMD qui lui nous détectera le code mort ou bien encore le fameux algorithme CPD pour Copy/Paste Detector.

4. Bonne citoyenneté

Avec une formule : getters + setters != encapsulation ! Le speaker insiste alors : ne générez pas automatiquement sans réfléchir ces fameux getters et setters. Et si vous en avez réellement besoin, il faudra peut-être les tester.
Et un exemple d’API worst citizenship in the java world selon lui : java.util.Calendar ! Et un exemple très saisissant : que donne une instance de Calendar avec 31 février ? Et bien une instance de Calendar au 1er mars ! Alors que l’on ne serait pas surprit de se prendre une petite exception à la figure… Avec un constructeur sans paramètre, un autre avec tout, encore un autre avec seulement la moitié des paramètres demandés… En bref : prenez JodaTime :-)

5. YAGNI

L’idée est simple : si vous n’en avez pas besoin tout de suite, pourquoi le faire ? Et oui, You Ain’t Gonna Need It !

6. Remettre en cause l’autorité

J’ai beaucoup aimé l’exemple cité : le nom des méthodes en Java. La norme est en effet d’utiliser le CamelCase pour le nom de nos méthodes. Mais prenons par exemple les test unitaires et par exemple ce test :
testUserCannotAccessThisPageWithHisActualGrantedAuthorities
Pourquoi, pour une question de lisibilité, ne pas le nommer :
test_user_cannot_access_this_page_with_his_actual_granted_authorities
Le nom de la méthode devient alors plus lisible et on obtient plus facilement l’information de ce que fait le test.
Autre cas : le chainage de méthode. Là où l’on écrirait des appels successifs de méthodes setXXX avec un retour de type void, pourquoi ne pas revoir l’API et utiliser le Chaining Pattern pour avoir quelque chose du type : Car.describedAs().box().length(12).includes(Equipment.LADDER);. Neal Ford insiste sur cet exemple car celui-ci remet directement en cause la spécification Java Beans.
Il ne faut donc pas forcément s’arrêter sur des phrases telle que c’est comme ça qu’il faut faire, un point c’est tout !

7. Slap

Slap pour Single Level of Abstraction Principle, ce principe rejoint fortement le Composed Pattern puisque le concept est d’avoir plusieurs lignes de code dans une méthode ayant le même niveau d’abstraction.

8. Polyglotte

Java n’est pas le seul et, pour certaines problématiques ou certains environnements, il est peut-être préférable de partir sur d’autres langages. Exemple : JRuby pour faire de l’interface graphique ou Jaskell pour écrire du code fonctionnelle. En bref, ne pas se limiter à Java.

9. Chaque Nuance

Java traîne avec lui des idées reçues bien fausse comme par exemple que l’API reflection est lente, certes vrai en fin des années 90 mais plus aujourd’hui. Il faut donc nuancer les propos, ne garder que ce qui est vrai et ne pas hésiter à faire passer le message pour que toutes ces choses ne soit plus dites !

10. Anti-objets

Neal Ford nous explique qu’un anti-objet peut-être vu comme un objet qui fait exactement l’opposé de ce pourquoi il a été créé. L’exemple du vase ou visage nous permet ainsi de voir qu’un objet vase peut voir sa réelle existence complètement détournée.

Conclusion

Une session extrêmement riche et un livre à lire de toute urgence !

NB : Les slides de Neal Ford sont disponibles sur son site : Devoxx 2010 – Neal Ford – The Productive Programmer.