Archives mensuelles : janvier 2015

Résumé de livre : 10 days to faster reading

10-days-to-faster-reading-imgUn titre qui me promet de pouvoir lire plus vite ne pouvait que m’intéresser. Devenir un super héros intellectuel, voir s’engouffrer dans mon esprit les flots tempétueux des fleuves d’information du 21e siècle ? Mais oui! Et le tout en 10 jours…! Wouh!

J’ai donc acheté et lu « 10 days to faster reading », de Abby Marks Beale (rien à voir avec Ally Mac Beal) en prenant des notes, ce qui me permet de présenter ici un résumé.

 

Le résumé

Constat

L’auteure fait le constat que la plupart d’entre nous n’avons pas eu d’entrainement formel à la lecture depuis l’école primaire, alors qu’il est pourtant possible de s’améliorer avec des techniques éprouvées.

Elle remet en cause une série de paradigmes, issus de notre apprentissage de la lecture :

  • Il faut lire tous les mots
  • Il faut énoncer tous les mots dans son esprit
  • Il ne faut pas utiliser ses doigts ou un bout de papier pour s’aider
  • On doit comprendre et retenir tout ce qu’on a lu
  • Il faut lire le plus possible
  • Il ne faut pas lire en diagonale
  • Il ne faut pas écrire sur les livres

Selon elle, tout cela c’était bien pour apprendre mais en tant qu’adulte on veut être efficace, et on peut s’affranchir de ces règles. Elle commence donc par conseiller la réduction de ces mauvaises habitudes.

Techniques pour lire plus rapidement

Par exemple, on peut se contenter de lire uniquement les mots les plus importants d’une phrase (souvent les plus longs), pour en comprendre le sens.

On peut se contenter de lire les mots les plus importants

On peut utiliser un morceau de papier (genre une carte de visite), pour cacher ce qu’on vient de lire, dans le but garder trace de l’endroit où on est et donc de gagner du temps (pas de scan en arrière pour retrouver l’endroit). En revanche cacher ce qu’on va lire – le premier réflexe pour l’utilisation d’un tel dispositif – n’est pas intéressant.

Bonne utilisation d’un « pacer » selon Abby M. Beale.

On peut aussi donner du rythme à la lecture, en lisant par proposition (though groups en VO) :

On peut découper les phrases en propositions

Il y en a d’autres; comme s’entrainer à « voir » le plus de mots possible de coin de l’oeil (par défaut on ne voit vraiment qu’une petite zone très au centre de notre champ de vision).

Lire moins

Une bonne technique pour lire plus vite c’est… de lire moins.

D’abord donc choisir ce qu’on va lire : « pourquoi je lis ça ? Qu’est ce que ça m’apporte ? » Et éliminer ce qui n’est pas intéressant, en filtrant à la source (newsletters, abonnements…).

The Roadmap

Ensuite, même pour du contenu intéressant, on est pas obligé de toute lire, on peut utiliser le plan (qu’il soit formel ou non), pour avoir une idée du contenu et choisir ce que l’on va survoler et ce que l’on va lire en détail.

Utiliser donc les titres, sous titres, premières phrases de paragraphes, phrases mises en valeur, graphiques, listes de points etc… Pour se faire une carte mentale du document et se frayer un chemin vers le contenu intéressant. Ainsi, on peut en théorie comprendre une bonne partie du contenu en beaucoup moins de temps.

Pour l’auteur, scanner et lire en diagonale sont deux techniques complémentaires mais distinctes pour respectivement choisir un contenu précis à approfondir et avoir une idée globale du contenu d’un document.

Meilleur compréhension

Une autre promesse du livre, en plus de lire plus rapidement est de mieux comprendre le contenu. Les conseils d’Abby pour cela sont :

  • Choisir l’endroit et les conditions où on lit, pour éviter les distractions (gens, téléphone, mail, …)
  • Prendre des notes dans la marge
  • Prendre des notes tout court (comme ce que j’ai fait pour produire ce résumé donc)
  • Savoir ce qu’on lit et pourquoi, pour le placer dans un contexte, faire des  connections avec du savoir existant
  • Avoir une idée du but de l’auteur, en sachant qui il est, l’histoire du livre, etc…
  • Ajuster sa vitesse du lecture en fonction de son but : se concentrer plus si le contenu est très important
  • Comprendre le vocabulaire

Mon impression

Le début du livre se focalise sur des gens qui n’ont vraiment pas l’habitude de lire : l’auteure parle de gens qui lisent à haute voix en chuchotant! Je ne me suis pas trop senti concerné.

Ensuite certaines des techniques, sont intéressantes, je vais creuser, mais je doute de pouvoir révolutionner ma propre vélocité à ce niveau.

Le plus efficace, mais le moins révolutionnaire est bien sur la technique de la roadmap : parcourir le plan pour se faire une idée du contenu, scanner pour en comprendre l’essentiel et voir en détail les points intéressants. Un peu évident mais j’y penserais sans doute plus souvent maintenant.

En fait à part quelques petits trucs au début, il s’agit surtout d’une formalisation de demi évidences. Le livre est assez répétitif, avec des passages un peu hors sujet (il y a un chapitre sur le fait qu’il faut lire avec son esprit critique par exemple), et on se retrouve à appliquer les propre techniques d’Abby M Beale, et en fait à scanner durant le dernier tiers pour trouver d’éventuelles pépites.

Au final, lecture intéressante, mais le contenu aurait pu tenir en quatre fois moins de pages.

Les interfaces ça sert à rien

Enfin quasiment toujours, les interfaces dans les projets java moyens ne servent à rien.

Pourquoi toujours ajouter une interface, pour tous les services, repositories, raton-laveurs ? C’est beaucoup plus une habitude qu’une nécessité.

Ca ne devrait pas être un sujet, mais mission après mission je vois des centaines de classes, avec à chaque fois une interface associée, qui ne sert à rien.

Rappel : c’est quoi une interface ?

La notion d’interface en java est un contrat. Une interface définit un ensemble de méthodes, et les classes implémentant l’interface sont tenues d’implémenter ces méthodes.

Par exemple l’interface Comparable définit une méthode compareTo, et toutes les classes implémentant Comparable peuvent être utilisées pour des traitements impliquant des comparaisons, comme être ajoutées dans un SortedSet. Les interfaces permettent un polymorphisme plus riche que ce qu’on aurait avec l’héritage linéaire en java et permettent la réutilisation de code (eg : le SortedSet sus mentionné).

Un service java typique

Après ce bref rappel, prenons notre service Java typique :

1
2
3
4
5
6
7
public interface BiduleService {
    void save(Bidule bidule)

    void computeComplexeLogic(Bidule bidule1, BiduleInfos infos);
}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Service
public class BiduleServiceImpl implements BiduleService {
    @Override
    public void save(Bidule bidule) {
        // implem
    }

    @Override
    public void computeComplexeLogic(Bidule bidule1, BiduleInfos infos) {
         // implem
    }

    // ...
}

Là je suis à 99,99% sur qu’il n’y aura absolument jamais d’autre implémentation de l’interface BiduleService. Ce service est hyper spécifique à mon application. Il s’agit d’un sac de procédures (oui quand on fait des services on ne fait pas de la POO…) liées à mon métier, pas d’un concept pouvant avoir un contrat comme Comparable ou Serializable.

Au niveau Java, cette interface n’a pas de raison d’être. Elle est là parce qu’on a toujours mis des interfaces pour ce genre de classe, et que c’est comme ça dans le reste du projet.

Pourquoi a-t-on a pris l’habitude de mettre des interfaces partout ?

Cela date en fait d’un temps que je n’ai pas pu connaitre, mais à l’origine les interfaces (dans ce cas précis) servaient à créer des proxys JDK pour les EJB 2.

Par proxy JDK j’entends des proxys dynamiques, (comme dans le design pattern proxy) créés à partir de l’API éponyme de Java (note : il s’agit d’une fonctionnalité de Java SE, Standard Edition, même pas Java EE, et encore moins d’une dépendance). Les proxys dynamiques permettent d’ajouter du comportement aux classes, comme les transactions, ou de l’AOP.

L’API proxy de Java SE impose à la classe proxifiée d’avoir une interface que le proxy peut implémenter, afin de pouvoir être interchangé avec la classe.

Les EJB 2 imposaient donc ces interfaces.

Cela permettait également de créer plus facilement des mocks pour les tests.

Donc plutôt intéressant en effet.

Sauf qu’il est depuis longtemps possible de faire tout cela sans interfaces.

Spring peut par exemple utiliser cglib plutôt que les proxys JDK pour créer ses proxys, il y a de petites différences mais en gros ça se comporte de la même façon. Pour les mocks, Easy mock class extension existe depuis longtemps, sans parler de Mockito (et bien d’autres) qui a toujours supporté le mocking de classes. Et même les EJB, depuis la version 3.1 n’imposent plus l’utilisation d’interfaces.

Depuis quand ça ne sert plus à rien ?

Spring : Depuis la 1.0.0, en novembre 2003.

EJB 3.1 : Sortie officielle en décembre 2009.

Easy mock class extension : la plus ancienne version dont j’ai trouvé la date, la 2.2, date d’avril 2006.

Mockito : la plus ancienne version dont j’ai trouvé la date, la 1.3, date d’avril 2008.

En résumé

Depuis une bientôt une décennie, on garde une habitude héritée des EJB 2, qui double presque le nombre de fichiers des projets, sans aucune raison (en général).

Donc avant de créer une interface pour une classe dont les instances seront gérées par le conteneur, assurez vous d’avoir vraiment une contrainte qui l’implique.