Accueil > Java EE > Pourquoi vous devriez passer une certification Java 7

Pourquoi vous devriez passer une certification Java 7

 

Ayant passé les certifications Java SE 7 I (Associate) et II (Professional) au cours de ces derniers mois, je vous propose un tour d’horizon sur ces dernières :

  • en quoi elles consistent,
  • qu’est-ce qu’elles peuvent vous apporter,
  • et ce à quoi elles ne vous serviront pas.

Bien que sur la forme, je ne sois pas toujours d’accord,  le fond est là et ces certifications sont un bon moyen d’approfondir ses connaissances sur Java.

Voyons ce qu’elles nous apportent, leurs points forts et leurs points faibles.

 

La reconnaissance

 

Lorsqu’on m’a proposé de passer les certifications Java cette année, j’ai au départ été très enthousiaste car je trouve cela gratifiant d’obtenir son « petit diplôme ».

C’est peut-être un peu simplet de ma part, mais je pense que ça illustre finalement un manque de reconnaissance de notre travail de la part de nombreux acteurs.

Nous travaillons dans un domaine très complexe : un projet ne requiert rarement des compétences sur un langage de programmation uniquement.

Il faut être capable d’être bon en Java, mais aussi de comprendre le SI dans lequel le projet s’intègre, maîtriser les protocoles réseau, les frameworks, les serveurs d’applications, des outils, tout en conservant une longueur d’avance pour être à la page sur les nouveaux frameworks ainsi que les nouveautés des frameworks existants.

Cette veille technologique n’est pas toujours offerte et c’est souvent un investissement effectué sur son temps personnel.

Le métier de développeur ne se résume donc pas simplement à du développement. Pourtant, peu de gens semblent s’en rendre compte et estimer la valeur de notre travail…

N’avez-vous jamais entendu un product owner en sprint planning vous rétorquer après un chiffrage que cette tâche n’est « qu’un if-else à rajouter, ça ne prend que 10 minutes » (sans se préoccuper d’une quelconque analyse d’impact, de tests à rajouter ou encore de la mise à jour de la documentation) ?

Nous sommes souvent considérés comme étant les « simples » ouvriers menant à bien les projets et que le développement n’est qu’une tâche bassement technique.

C’est pourtant loin d’être le cas et je pense que toute source de reconnaissance est bonne à prendre.

 

Le désenchantement

 

J’ai donc débuté mes révisions avec enthousiasme pour l’obtention de ces diplômes.

Je me lance et passe un premier test blanc. La forme est basique : il s’agit d’un QCM dont la majeure partie des questions consistent à lire, assimiler un morceau de code et prévoir son fonctionnement.

Quelle ne fut pas ma déception en constatant à première vue la teneur ces lignes de code.

Petit exemple :

What will be the result of attempting to compile and run the following code?

import java.util.ArrayList;
import java.util.List;
package org.test;

public class Main { 
	public static void main(String args[]){
		B.C obj = new B( ).new C( ); 
	} 
} 

class A {
	char c; 
	A(char c) {
		this.c = c;
	}
} 

class B extends A {
	char c = 'a';
	B( ) { 
		super('b'); 
 	}
	class C extends A {
		List<Character> chars = new ArrayList<>();
		char c = 'c';
		C( ) {
			super('d');
			chars.add('d');
			System.out.println(B.this.c);
			System.out.println(C.this.c);
			System.out.println(super.c);
		}
	}
}

 

Quand je regarde ces quelques lignes de code, je me demande à quoi cela va pouvoir me servir dans ma vie professionnelle de tous les jours.

Le bout de code n’a aucune utilité ou intérêt particulier et les noms de variables et de classes ne veulent rien dire.

Deuxième remarque : la complexité inutile : en 6 ans de pratique Java, je n’ai jamais eu à concevoir de classe avec une classe interne, ni à mettre plusieurs classes dans le même fichier.

Au pire, une classe anonyme qui sera élégamment remplacée par une lambda dans Java 8 mais souvent, je préfère une approche simple (K.I.S.S.) et placer chaque classe dans son propre fichier, et cela ne m’a jamais empêché de mener à bien les projets sur lesquels j’ai pu participer, bien au contraire.

Bref, la question semble bête et méchante et le contexte de l’examen bien loin du contexte professionnel.

Après avoir assimilé le code, je valide ma réponse. Deuxième déception : il n’y avait même pas à lire tout ce code car il ne compile pas, la commande package étant forcément la première ligne du fichier.
Le propos de cette question est donc en fait la commande package, qui est aujourd’hui automatiquement saisie par votre IDE préféré.

Quel intérêt ? Cette question ressemble de plus en plus à un piège bête et méchant.

Viennent ensuite des questions sur des parties qu’on n’utilise jamais ou presque, ou qui ne semblent pas pertinentes.

Quelques exemples :

  • la nouvelle façon d’utiliser JDBC en Java 7 –> qu’importe, j’utilise Hibernate ou Spring Data (ou n’importe quel autre framework) et je n’aurai pas à m’inquiéter des RowSet et autres objets bas niveau ;
  • des generics étranges : List –> je n’ai encore vu aucun cas d’usage du super dans les generics, bien que je comprenne l’intérêt théorique d’offrir cette possibilité, symétrique à extends;
  • les paramètres possibles sur des surcharges inconnues de quelques classes jugées comme étant clefs, mais dont vous n’avez jamais entendu parler.

La frustration s’installe : le premier test est un échec criant alors que je suis sensé avoir abordé des sujets basiques (déclarer des classes, utiliser les modifiers). Et bien que j’ai illustré des questions pièges avec l’exemple ci-dessus, toutes mes erreurs n’étaient pas dues à des pièges de ce genre, mais aussi à des méconnaissances des bases.

 

 La redécouverte du langage

 

Au fur et à mesure de mes échecs et des corrections sur les tests blancs, je redécouvre petit à petit les bases du langage, les parties mal connues, mal apprises, mal comprises.

Un premier exemple flagrant est l’héritage : Java rend son usage très simple, voire magique. Pourtant les mécanismes de shadowing, d’overriding (couplez tout cela avec des modifiers private/protected/public pour corser la situation) ne sont pas si triviaux que cela, et un usage simple au quotidien amène finalement à une compréhension simpliste du sujet.

De même, les questions sur les generics m’ont apporté énormément sur la compréhension de leur fonctionnement et de ce qu’il est possible ou non de faire avec, même si je les utilisais déjà avant.

Un exemple simple et concret :

public class GenericsTest {

    static class Fruit {}
    static class Apple extends Fruit {}

    public static void main(String[] args) {
        Apple apple = new Apple();
        List<? extends Fruit> listOfFruits = new ArrayList<>();
        listOfFruits.add(apple);
    }
}

 

La variable listOfFruits ne peut contenir que des objets étant des Fruit ou des sous-classes de Fruit, comme la classe Apple.

Que pensez-vous qu’il se passe ici ?

Avec la compréhension des generics que j’avais, j’ai répondu que le code compilait et que listOfFruits contenait un objet Apple. Pourtant, la ligne listOfFruits.add(apple) est refusée par le compilateur.

Un dernier point très important : les « classes-clefs » mentionnées plus haut, celles dont vous n’avez jamais entendu parler.

Ces certifications nous en parlent pour une bonne raison : elles sont réellement importantes. Les connaître approfondira considérablement votre connaissance du JDK et votre capacité à proposer une réponse adaptée et élégante au problème posé.

Certes, je n’utiliserai peut-être pas dès demain la nouvelle façon d’utiliser un driver JDBC. Tout n’est pas nécessairement utile dans un avenir proche ou lointain.

En revanche, ces certifications m’ont fait redécouvrir les bases, m’ont apporté une meilleure compréhension de ce que je fais au quotidien et m’ont permis de découvrir une multitude de classes et d’interfaces (pas seulement de Java 7 mais aussi des versions antérieures).

Nous n’utilisons souvent qu’une petite fraction du JDK et c’est certainement un tort, la découverte de ces objets et la redécouverte du fonctionnement de Java ont considérablement enrichi ma vision du langage.

 

Conclusion

 

Ces certifications ne feront pas de vous un développeur accompli.

Vous n’apprendrez pas à mieux concevoir l’architecture de votre projet, à penser vos classes pour quelles soient testables, ni quelles sont les bonnes pratiques de build, de déploiement, etc.

Toutes ces problématiques que nous avons à résoudre en tant que développeurs sont hors du cadre de ces deux certifications Java qui sont vraiment orientées uniquement vers le langage Java.

On peut faire un parallèle entre un mécanicien et un pilote de F1 : ce n’est pas parce que vous êtes un mécanicien aguerri que vous serez pour autant un excellent pilote de formule 1.
Cela dit, une meilleure compréhension de votre véhicule pourra vous aider à en tirer les meilleures performances pendant la course.

Bien que d’un premier abord potentiellement rebutant, ces certifications sont un vrai gain pour ceux qui souhaiteront améliorer leur compréhension du langage Java et de son fonctionnement.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


+ huit = 10