Rossi Oddet
Rossi Oddet Développeur | Formateur IT

Soirée JUG Nantes : Du SQL au NoSQL en moins d'une heure (Partie 1)

Soirée JUG Nantes : Du SQL au NoSQL en moins d'une heure (Partie 1)

Le 4 novembre dernier, j’ai eu l’opportunité de participer à une soirée organisée par le JUG Nantes sous le thème “Du SQL au NoSQL en moins d’une heure”.

Une salle pleine !

La plus grande salle de l’EPSI Nantes était un peu petite face à l’engouement suscité par l’événement.

C’est le premier événement JUG Nantes auquel j’assiste depuis la rentrée. Oui c’est avec beaucoup de regrêts que je n’ai pas pu être présent à la première soirée de cette saison 2013-2014 :) Je remarque aussi que le public a changé, il y a beaucoup plus d’étudiants comparé à la saison précédente. Ceci est probablement lié au fait que l’EPSI Nantes accueille l’événement.

Le JUG de Nantes va nous offrir 2 sessions :

  • 1 Quickie Amélioration de la qualité du code par restriction du langage
  • 1 talk Elastifiez votre application : du SQL au NoSQL en moins d’une heure

Le quickie Amélioration de la qualité du code

Hugo Wood va nous présenter son retour d’expérience sur l’amélioration de la qualité du code. Il a appris le langage Java principalement en autodidacte avec des livres et travaille récemment en société de service où il côtoie beaucoup de legacy (les connaisseurs ne seront probablement pas surpris ;)).

C’est quoi la qualité du code ?

Hugo a commencé par poser les bases de la qualité du code.

Par quoi reconnaît-on un code de bonne qualité ? => Par sa maintenabilité. Et pour avoir un code maintenable, il faut qu’il soit modulaire et testable.

Les méthodes privées => cacher la misère ?

Vous l’avez surement déjà remarqué, les méthodes privées d’une classe ont tendance à se multiplier avec le passage d’un collègue qui vous dit avec fierté que le code n’était pas lisible et qu’il a fait du refactoring. Il avait trouvé une méthode publique trop grosse, vous savez ce genre de méthode qui ne se termine pas avec 2 scrolls de votre souris. Il a alors extrait (merci les IDE) des parties de code de la méthode en plusieurs méthodes privées.

La lisibilité de la méthode s’est peut-être améliorée mais a t-on vraiment progressé sur la maintenabilité après une telle opération ?

La réponse est Non. En effet, cette opération conduit généralement à 2 catégories de méthodes privées :

  • 1 méthode qui n’interagit avec aucun champ de la classe. Que fait-elle alors dans cette classe ? Elle pourrait être static votre code fonctionnerait toujours. Il convient donc de l’extraire dans une nouvelle classe.

  • 1 méthode privée qui modifie la valeur d’un champ de la classe. Cela conduit souvent à perdre le contrôle rationnel de ce champ. En effet, lorsque vous lirez votre méthode publique à refactorer, vous verrez l’appel à cette nouvelle méthode. Vous ne vous rendrez pas forcément compte qu’il modifie un champ et que la suite de votre algorithme dépend fortement de l’exécution de cette nouvelle méthode. Comme dit Hugo, un parfum de variable globale… La bonne option est donc d’extraire ce champ et cette méthode dans une nouvelle classe.

Etes-vous prêt à arrêter de cacher la misère en vous “privant” des méthodes privées ?

L’héritage de classe => notre ennemi ?

Ceux qui travaillent au quotidien avec une grande volumétrie de code, l’admettront aisément : l’héritage de classe, quand il est mal utilisé pose quelques difficultés de maintenance :

  • Comment tester une classe fille sans effet de bord de la classe mère ?
  • Comment tester unitairement une classe abstraite sans ses classes concrètes ?
  • Utiliser des champs protected d’une classe mère dans une classe fille, une encapsulation à plusieurs vitesses ?

L’héritage de classe est malheureusement souvent utilisé, à tort, pour factoriser du code. Il est alors facile de se retrouver par exemple avec :

  • Une méthode dont l’exécution conduit à naviguer à travers plusieurs niveaux de la hiérarchie des classes
  • Une méthode vide (avec un commentaire // ne rien faire) dans certaines classes pour un traitement à ne pas effectuer dans des cas particuliers

Hugo va préconiser l’utilisation des interfaces et de la composition pour traiter nos besoins courants. Il va l’illustrer en proposant un refactoring possible de la classe abstraite AbstractCollection du JDK avec une interface et la composition (illustration présente dans ses slides).

Etes-vous prêt à ne plus utiliser l’héritage de classe ?

Les slides du Quickie

Vous l’aurez compris, Hugo encourage une restriction de l’utilisation du langage Java pour améliorer la qualité de du code. Il argumente que cela permettra aux débutants de commettre moins d’erreurs de design et aux expérimentés d’agir avec un meilleur discernement.

La suite ! La suite ! La suite !

Après ce quickie, Tugdual Grall et David Pilato ont pris le relais pour le talk Elastifiez votre application : du SQL au NoSQL en moins d’une heure. A travers un exemple de code, ils vont nous montrer comment passer du SQL au NoSQL avec CouchBase et Elasticsearch.

A suivre dans la 2ème partie de cet article dans les prochains jours…

comments powered by Disqus