Je vais aujourd’hui profiter de cet article pour vous faire un retour d’expérience sur des coding horrors que j’ai pu rencontrer lors de ma carrière. Pour les amateurs du genre, vous avez le site the Daily WTF notamment.

Nommage des tables en base de données

Une des applications sur lesquelles j’ai été amené à travailler avait décidé de nommer ses tables sur deux ou trois lettres. Sauf que, avec un tel système, on s’était retrouvé notamment avec une table nommée for et une autre nommée int. Alors ça avait marché au moment de la création de l’application car c’était sur MySQL 4 qui ne supportait pas les procédures stockées, mais un jour ils ont voulu passer le tout en 5. Curieusement ça n’a pas posé de problème directement.

Et alors, pourquoi c’est mal ?

Quiconque a programmé un minimum et notamment des procédures SQL aura tout de suite vu que bon, for et int sont des éléments du langage SQL, bref j’évite tout commentaire là-dessus. Et puis bon pour les tables il vaut mieux rendre les noms assez explicites, même si des fois on est limité en nombre de caractères, ça rend l’application plus lisible.

Aller délibérément contre une convention de codage majeure de Java

Certaines entreprises décident d’aller délibérément contre une ou plusieurs conventions de codage majeures de Java. Je ne parle pas ici de l’ordre conventionnel entre les mot-clefs static et final, même s’il existe, mais de trucs bien plus bas niveau que ça. Ainsi j’ai travaillé dans une entreprise où ils avait décidé que tous les noms de leur méthodes devaient commencer par des majuscules, comme en C#.

Et alors, pourquoi c’est mal ?

Bon déjà ça crée des soucis vis à vis des nouveaux arrivants dans l’entreprise qui en sont pas habitués à de telles conventions. Mais pire, des outils d’analyse de code comme l’excellent FindBugs ou Sonar partent du principe que vous avez respecté ces conventions et génèreront des dizaines de warnings si ce n’est pas le cas. Alors certes on peut les masquer mais bon, des fois ces filtres sont un peu trop agressifs et masquent de vraies erreurs. Et s’il n’y a pas de masquage, ces pratiques génèrent du « bruit » dans ces outils ce qui n’aide pas à retrouver les vrais problèmes.

Certains cas de break dans des boucles for

Il m’est arrivé au cours de ma carrière de tomber sur un bout de code comme ça :

label:
for (int i = 0; i < 10; i++) {
   / bla bla
   for (int j = 0; j < 100; j++) {
      / bla bla
      if (condition) {
         break label;
      }
      / bla bla
   }
}

Pour ceux qui ne connaîtraient pas ce type de construction c'est expliqué ici, mais pour dire simplement si on rentre dans le break ici on sort directement de la boucle for désignée par label.

Et alors, pourquoi c'est mal ?

Déjà pour celui qui n'a jamais vu ça la syntaxe est déroutante et fait penser à une boucle infinie où on retournerait directement à label pour reprendre la boucle for (int i = 0; i < 10; i++). Mais bon ensuite le souci est qu'on peut vite arriver à faire du code spaghetti avec des labels imbriqués et des for correspondants, un peu comme avec le sinistre goto du langage BASIC. D'ailleurs pour la petite histoire le mot-clef goto existe en Java mais n'a jamais été implémenté, précisément pour cette raison.

Utilisation incorrecte de la généricité

Dans une entreprise dans laquelle j'ai eu l'occasion de travailler, à un moment on avait deux classes à gérer, BasicSegment et InternalSegment. Il se trouve que la deuxième héritait de la première. On avait aussi le code de la classe SegmentGroup qui était le suivant :

public class SegmentGroup<E extends BasicSegment> {

   private List<E> segments;

   / bla bla

   public void addSegment(E segment) {
      / bla bla
   }

   public void checkSegment(final InternalSegment segment) {
      for (E seg: segments) {
         if (seg instanceof InternalSegment) {
            / bla bla
         }
      }
   }
}

Et alors, pourquoi c'est mal ?

L'intérêt de la généricité, c'est justement de pouvoir typer un conteneur d'objets en fonction d'un paramètre. Là il se trouve qu'on peut typer une instance de SegmentGroup mais on se rend compte que celle-ci gère des traitements particuliers en fonction du type d'instance de BasicSegment contenu, bref on perd tout l'intérêt de la généricité.

Utilisation incorrecte de classes anonymes

Dans certaines applications, on retrouve un code de ce type à des endroits très souvent appelés :

List l = new ArrayList();
/ bla bla
CollectionUtils.filter(l, new Predicate() {
   public boolean evaluate(Object o) {
      String s = (String) o;
      return s.startsWith("hello");
   }
});
/ bla bla

Je l'avoue, ici c'est déjà plus subtil, et le point est que le bout de code mentionné ci-dessus se retrouve à être très souvent appelé. Vous ne voyez toujours pas ? Allez, je vous aide, regardez donc comment fonctionne un GC.

Et alors, pourquoi c'est mal ?

La réponse est qu'à chaque fois qu'on exécutera ce code, on va instancier un nouveau Predicate, lequel ne dépend absolument pas de l'état d'une variable déterminée plus haut dans le code. On se retrouve donc à instancier un objet inutilement, celui-ci pouvant parfaitement être statique ou en singleton. Et quand on instancie des objets inutilement dans une application, ça accélère le "vieillissement" des autres objets au niveau du GC, et à terme on augmente le beson de l'application en full GC, ce qui n'est pas bon du tout. Et ce d'autant plus si le code en question est appelé souvent. Alors, convaincu ?

Ne pas utiliser de vrai constructeur dans les objets

La norme JavaBean explicite que les POJOs doivent avoir un constructeur par défaut, et des getters/setters sur leurs valeurs pouvant être lues et positionnées. Le problème est qu'après on peut avoir du code comme ceci :

MyObj monObj = new MyObj();
monObj.setPropertyA(...);
monObj.setPropertyB(...);
monObj.setPropertyC(...);
/ Bla bla bla

Et alors, pourquoi c'est mal ?

Déjà si un objet a besoin qu'un certain nombre de champs soit initialisés lors de son instanciation, ici toute personne qui veut l'instancier se retrouve à invoquer pas mal de setters, et d'autre part il n'y a pas moyen de valider que les champs devant être initialisés le sont réellement. D'autre part, cela complique les tests unitaires de l'objet, car il faudra aussi écrire toutes ces lignes d'initialisation dans les tests. Enfin, on casse l'encapsulation de ces objets. De manière générale les setters des POJO en particulier sont faits pour être appelés par les librairies du type Hibernate ou JAXB. Pour le développeur, il convient d'utiliser les constructeurs "normaux" en faisant comme si ces setters n'existaient pas. Je ne dis pas que de temps en temps ils ne sont pas nécessaires, juste que bon, initialiser un objet comme dans l'exemple ça va en C (et encore...) mais certainement pas dans un langage objet comme Java.

Des méthodes très très longues, trop longues

Dans une application en particulier sur laquelle j'ai été amené à travailler, on avait un paquet de méthodes qui dépassaient allègrement le millier de lignes de codes, dont certaines utilisaient la réflexivité intensivement. La complexité cyclomatique de chacune d'entre elles atteignait facilement les 50. Non je vous rassure, je n'ai rien codé de tel dans ma vie.

Et alors, pourquoi c'est mal ?

Coder de telles méthodes est un bon plan pour le gars qui veut verrouiller son poste. Plus sérieusement, maintenir de tels trucs est totalement impossible, sauf peut-être pour son auteur, et encore...

equals() et hashcode()

En parcourant GitHub, je suis tombé sur ceci (j'ai anonymisé le code) :

public class BadObject {
        private String name;

        public BadObject(String name) {
                this.name = name;    
        }

        @Override    
        public boolean equals(Object obj) {
                boolean equality = false;
                if (obj instanceof BadObject) {
                        BadObject other = (BadObject) obj;
                        if ((name != null) && name.equals(other.name)) {
                                 equality = true;
                        }
                }
                return equality;
        }

        /**
         * Getter for the field {@code name}
         * @return the name
         */    
        public String getName() {
               return name;
        }

        /**
         * Setter for the field {@code name}
         * @param name the name to set
         */
        public void setName(String name) {
               this.name = name;    
        }
}

Et alors, pourquoi c'est mal ?

Le equals est très mal codé ici, on a en effet new BadObject(null).equals(new BadObject(null)) qui retourne false. Mais surtout le pire est que le hashCode() manque ici, or si le equals est redéfini il faut toujours redéfinir le hashCode(), cf. l'explication ici et le fait que c'est tout simplement défini dans le contrat de la méthode hashCode() et utilisé dans les collections de type HashMap ou HashSet.

Quant au bout de code, il s'agit d'un exemple bien réel, j'ai juste renommé la classe.

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Quelques principes d'architectures d'applis Web en Java/JEE
• Si vous mélangez Hibernate avec du SQL

Vous aussi vous avez envie d'écrire des articles ?

Julien
Moi c'est Julien, ingénieur en informatique avec quelques années d'expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple - avant même ma naissance (oui ça date ). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
En savoir +

Ces dernières années, on parle beaucoup du Test Driven Development, aussi connu sous l’acronyme TDD. Ce dernier s’inscrit en fait dans une démarche d’amélioration de la qualité des applications. En effet, les tests doivent normalement être écrits avant le code et doivent commencer par échouer. Sinon, le seul intérêt des tests unitaires sera de garantir une non régression par rapport au code actuel. Autre avantage des tests unitaires : pour que votre code soit testable il faut qu’il soit un minimum bien construit, sinon l’écriture des tests devient très complexe. James Carr a d’ailleurs publié un catalogue d’anti-patterns sur le sujet.

Quelques rappels sur les tests unitaires

La première chose qui compte est la couverture de code de votre application par les tests unitaires. On considère qu’une application est correctement couvert par les tests unitaires dès lors que 80% du code au minimum est couvert, autrement dit qu’en exécutant vos tests unitaires on passe par 80% des lignes de votre code.

Considérant le programme suivant :

public String testAB(final boolean a, final boolean b) {
     if (a && b) {
           return "a et b sont vrais";
     } else {
           return "a ou b est faux";
     }
}

Si on veut tester correctement cette méthode, il faut envisager tous les cas, à savoir :

• a et b sont faux
• a est faux, et b est vrai
• a est vrai, et b est faux
• a et b sont vrais

Ici l’exemple est trivial, mais il faut quand même reconnaître que dans la vraie vie ce genre de tests peut représenter un travail énorme, d’autant que comme on peut le voir on teste en fait trois fois le même chemin de code. Dans la suite de l’article, on voit justement comment éviter ça.

Un autre cas qui peut être pire est celui où votre méthode appelle des méthodes d’autres objets. Dans ce cas, afin d’éviter de devoir tester les autres objets n fois, on fait appel à des mock objects, tels que ceux fournis par la librairie Mockito. Le principe est simple : les mock objects ont la même API que les objets réels que votre classe appelle, et dans le test vous vous contentez de spécifier comment votre mock doit réagir à un appel avec des paramètres donnés. Après, il suffit d’injecter ces mocks dans votre classe à tester pour faire le travail.

Quelques rappels sur les APIs

En Java, nous avons quatre niveaux possible de visibilité des méthodes et des variables membres :

• public : tout le monde peut utiliser ma méthode, mon champ ou ma classe.
• protected : toutes les classes qui héritent de ma classe ou qui sont dans le même package que ma classe peuvent utiliser ma méthode ou mon champ (honnêtement, je n’ai jamais vu de classe déclarée comme étant protected dans ma vie de dév).
• niveau par défaut (aucun mot-clef) : seules les classes appartenant au même package que ma classe peuvent utiliser ma méthode, mon champ ou ma classe.
• private : seule les membres de ma classe peuvent utiliser ma méthode ou mon champ.

Seuls les éléments public et protected font partie de votre API et doivent garantir un contrat. Les éléments private et avec la visibilité par défaut sont considérés comme des détails d’implémentation. Nous nous servons d’ailleurs de ce dernier point.

Les méthodes private

Afin d’éviter de dupliquer du code, on est souvent amené à écrire des méthodes private. Le problème de ces méthodes est qu’elles ne sont pas visibles en dehors de la classe. Aussi, si vous voulez les tester, le seul moyen est de tester en même temps le code appelant. A l’inverse, si votre méthode privée est appelée par plusieurs autres méthodes de votre classe, vous allez être amené à la tester plusieurs fois.

Dans tous les cas, il ne s’agit pas d’une méthode satisfaisante, et on se retrouve assez vite dans le cas de l’exemple de code ci-dessus avec trois cas de tests différents qui testent en fait le même chemin de code. L’idéal serait donc de pouvoir d’un côté tester la méthode privée, et de l’autre les méthodes y faisant appel en mockant la méthode privée.

Solution : la classe compagnon

Nous avons vu tout à l’heure que les classes avec visibilité par défaut ne sont pas visibles de l’extérieur. Dès lors, une solution permettant de résoudre d’un coup tous vos problèmes est tout simplement de déporter les méthodes privées de votre classe de base vers une classe compagnon, qui aura une visibilité par défaut, de même que ses méthodes. Ensuite vous testez individuellement ces méthodes, et au niveau de la classe de base vous n’avez plus qu’à créer un mock de la classe compagnon.

Par extension, si vous avez d’autres méthodes privées un temps soit peu complexes appelées par plusieurs méthodes privées que vous avez déportées dans votre classe compagnon, vous pouvez créer une deuxième classe compagnon qui sera un compagnon du premier compagnon, et ainsi de suite.

N’hésitez pas non plus à utiliser cette astuce si vous avez une méthode longue, afin de la découper en morceaux plus simples !

Le problème des branchements conditionnels

On peut aussi avoir des méthodes qui ont des conditions multiples dans un branchement, comme ci-dessous :

public String testConditions(final int a, final int b, final int c) {
     if (a > 50 && b < 10 && c == 5) {
           return "a et b sont vrais";
     } else {
           return "a ou b est faux";
     }
}

Là encore, on se retrouve à devoir écrire plusieurs tests pour le même chemin de code. La solution est donc de déporter l’évaluation de la condition dans une méthode de la classe compagnon, qu’on teste d’un côté et de l’autre on n’écrit plus qu’un test dans le cas où la condition est vraie, et un autre si elle est fausse. Ca donne, dans la classe compagnon :

boolean checkCondition(int a, int b, int c) {
     return a > 50 && b < 10 && c == 5;
}

Et au niveau de la classe de base :

public String testConditions(final int a, final int b, final int c) {
     if (monCompagnon.checkCondition(a, b, c)) {
           return "a et b sont vrais";
     } else {
           return "a ou b est faux";
     }
}

Au final, on n’aura pas écrit moins de tests, mais par contre ceux-ci seront nettement plus simples.

Les objets de données

Bien souvent, surtout avec des frameworks comme Spring, on sépare le code entre d’un côté les objets de données et de l’autre le code de traitement. En soi, c’est très bien, sauf qu’avec l’avènement de solutions telles qu’Hibernate ceux-ci se sont réduits à un ensemble de getters et de setters, ce qui est très mal.

Dans notre cas, c’est mal tout simplement parce que pour initialiser un objet, on se retrouve à écrire à peu près ça :

MyObject obj = new MyObject();
obj.setA(a);
obj.setB(b);
obj.setC(c);
...

C’est très gênant pour des tests unitaires car on doit dupliquer ce code ! Alors que si on avait écrit un constructeur qui prenait les bons paramètres d’un coup, cette initialisation aurait pu être écrite d’un coup et d’un seul ! Dans le cas où vous devriez avoir plusieurs initialisations possibles de votre objet, plutôt que d’écrire plusieurs constructeurs, vous pouvez passer par le pattern builder présenté dans l’excellent livre Effective Java de Joshua Bloch. Dans la même veine, c’est à votre objet de stockage de données de contrôler son état et non pas à vos services. Cela signifie que si plusieurs paramètres doivent être définis d’un coup pour assurer la cohérence de votre objet, ce dernier doit fournir une méthode permettant de les positionner d’un coup et surtout de les contrôler. Enfin, ceci permettra de séparer les responsabilités, et de tester d’un côté votre objet et de l’autre votre service d’une manière très simple.

Et dernier mot pour les frameworks du type Hibernate, configurez-les pour qu’ils aillent regarder les champs de vos classes plutôt qu’appeler les getters et setters. Ceci se fait généralement par annotation. Quant à la supposée différence de performances entre l’accès par méthodes et l’accès par champ, elle n’est pas vraie au moins pour les dernières JVMs.

Héritage d’objets, attention danger !

De manière générale, l’héritage ne doit être utilisé que pour faire du polymorphisme et pour rien d’autre. Cela se vérifie de nouveau dans le cas des tests unitaires. En effet, appeler depuis une classe fille une méthode de la classe parente revient à se retrouver dans le même cas que celui des méthodes privées présenté ci-dessus. Sauf que si vous avez beaucoup de classes qui appellent une méthode de la classe parente, le souci se trouve multiplié par 10, 100 ou 1000. Donc au risque de me répéter, utilisez l’agrégation pour réutiliser vos méthodes, et cantonnez l’héritage aux stricts cas de polymorphisme. Cet article parle du problème.

On peut néanmoins utiliser l’héritage avec des tests unitaires en respectant les conditions suivantes :

• Les classes filles doivent au maximum éviter d’appeler des méthodes de la classe parente
• L’héritage est fait parce qu’il y a un besoin de polymorphisme, et pas afin de réutiliser du code de la classe parente dans les classes filles.

A noter toutefois qu’hériter d’une ou plusieurs interfaces est totalement différent, étant donné que les interfaces ne servent que pour le polymorphisme.

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Quelques principes d’architecture d’applis web en Java/JEE
• Ecrire soi-même son API et son SDK

Cet article a été rédigé par Julien, membre de la communauté de blogueur JobProd. Julien a rejoint l’une de nos entreprises, faites comme lui :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date ). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Tous les articles de Julien

Vous souhaitez devenir blogueur pour JobProd ?

On entend souvent dire en France que le métier de chef de projet est l’évolution « naturelle » du métier de développeur. Mais finalement, est-ce si certain ? Et surtout, quels sont les pièges et les situations à éviter à tout prix autour de ce métier très en lien avec les développeurs ? Nous allons le voir dans cet article.

Le métier de chef de projet technique

Ce paragraphe peut vous sembler évident, et pourtant… Si vous prenez différentes entreprises, je suis sûr que pas une seule ne vous donnera la même réponse sur le rôle qu’ont les chefs de projet techniques au sein de leurs organisations.

Tout d’abord, un chef de projet technique est un manager. Autrement dit, comme tout chef, il doit pouvoir transmettre les messages entre sa hiérarchie et les équipes qu’il encadre, ce qui implique que le chef de projet est capable de comprendre les besoins et attentes de part et d’autres.

Dit comme ça, ça paraît évident, et pourtant, dans la réalité, j’ai pu voir de nombreux chefs de projets techniques qui ne comprenaient pas grand chose à ce que faisaient les gens du projet qu’ils géraient. Par ailleurs, et c’est aussi son rôle de chef, il doit assurer un rôle de firewall en protégeant son équipe des interactions vis-à-vis du monde extérieur, mais aussi en la défendant face à la hiérarchie (en évitant de dire « c’est tel membre de mon équipe qui a fait ça »). Au risque, s’il ne le fait pas, d’être perçu comme un rôle fantôme au sein de son équipe. Enfin, vous devrez faire des arbitrages, par exemple donner la priorité à tel développement sur tel autre.

Autant le dire tout de suite, ce n’est pas un métier où vous ferez de la technique, donc si c’est cette dernière qui vous passionne, je vous conseille clairement de passer votre chemin. Néanmoins vous devez avoir un bagage technique pour comprendre vos interlocuteurs.

Un métier qui requiert une formation

Chef de projet est un métier différent du métier de développeur, et donc qui requiert une formation. Il faut notamment des compétences en management, un peu de psychologie aussi, et on n’apprend pas ça sur le tas. Pour vous donner une idée mon premier chef avait au départ très mal commencé, en prenant tout le monde de haut, et très vite il s’est fait détester par son équipe. Après une formation d’une semaine il a complètement changé, se mettant à faire un rôle d’arbitrage et à protéger son équipe, et en quelques semaines nous nous sommes mis à vraiment l’apprécier ! Bref si on vous propose de passer chef de projet sans la formation adéquate, passez votre chemin c’est un piège !

Chef de projet technique != développeur

Comme dit plus haut, l’évolution naturelle du métier de développeur est bien l’expertise technique et pas le management, alors que chef de projet est justement un métier de management. En France le chef de projet technique est mieux payé que le développeur, mais cela ne fait pas sens étant donné qu’il ne s’agit absolument pas du même métier. D’ailleurs comme le dit cet article un chef de projet est plutôt un développeur qui a échoué, alors que le développeur qui a réussi passe architecte. Pour en rajouter une couche, il n’y a absolument pas besoin d’être une brute technique pour être chef de projet, par contre il faut un bon background technique et de bonnes capacités de communiquant. De même le chef de projet ne doit pas travailler sous les ordres d’un architecte, mais avec l’architecte, ce dernier étant membre de l’équipe qu’il encadre (ou d’une autre équipe) et définissant les solutions technique de l’application.

Des trucs à faire en tant que chef de projet

Un chef de projet doit savoir motiver ses équipes, notamment en assurant une bonne répartition entre les gens des tâches intéressantes et pénibles. Par ailleurs, il doit pouvoir négocier avec sa hiérarchie suffisamment de temps pour que les projets puissent sortir dans un état qualitatif correct. Cela implique notamment de pouvoir se battre pour repousser les dates de livraison si besoin, en effet mieux vaut sortir un produit un peu en retard mais bien fini plutôt qu’à l’heure mais inutilisable. En effet les clients seront bien plus contents, et d’autre part ça coûtera moins cher en maintenance. Cela dit de temps en temps il faut aussi être en mesure d’expliquer à ses équipes qu’il faut mettre un coup de boost, ce qui est parfaitement acceptable dès que ce n’est pas trop fréquent !

Les points à vérifier avant de signer une offre de chef de projet

Tout d’abord, en tant que chef d’équipe, vous devez avoir un budget alloué pour faire votre travail, vous laissant de la marge, notamment pour recruter de nouvelles personnes si besoin. De même pour les tâches qu’on vous demande on doit vous laisser de la marge, histoire de bien faire le boulot et d’assurer les inévitables tâches de refactoring de votre application. En effet en tant que chef de projet vous êtes responsable de votre application, et serez l’interlocuteur du monde extérieur par rapport à celle-ci (et à ses dysfonctionnements…)

Par ailleurs la notion de marge est très importante car c’est ça qui vous permet d’assurer votre rôle de chef. Dans le cas contraire, vous ne serez que le fusible qui tombera au premier dysfonctionnement !

Les offres d’emploi à éviter

En France on trouve de tout sous la désignation « chef de projet technique ». On peut cependant identifier des profils type d’offres à éviter. Pour les débusquer, n’hésitez pas à interroger votre interlocuteur longuement, car une fois le contrat signé, ce sera trop tard.

Le chef de projet technique Excel

Le chef de projet technique Excel passe son temps en réunion à noircir des fichiers Excel et à participer à des réunions, mais n’assure absolument pas son rôle. En fait, il n’a pratiquement pas de contact avec son équipe, ce qui retire l’essentiel de l’intérêt du job. Par contre en cas de souci, c’est lui qui prend. Bon, pas la peine de faire un dessin, je crois que vous avez compris.

Le chef de projet technique à tout faire

Ce type d’offre est bien plus redoutable, mais en même temps plus facile à discerner. En effet, dans l’intitulé, on demandera au chef de projet de s’occuper en plus du reste de tâches de développement et de tâches de mise en production, ce qui sort de son domaine de compétences ! Un tel chef de projet doit en fait assurer le travail de trois ou quatre personnes, avec des horaires à rallonge et tout le reste. Dans une telle situation attention au burn-out !

Un petit mot sur moi

J’ai tenu à écrire cet article car j’ai moi-même été chef de projet dans une entreprise où l’on m’a demandé d’assurer les tâches de dév, de mise en prod, de maintenance, de correction des bugs de prod, de planning, et aussi de négociation des specs avec la MOA, le tout sur fond de réduction drastique des effectifs dans l’équipe. Lorsque j’ai demandé des ressources supplémentaires on me l’a refusé au motif que « les budgets ont été votés et il n’y a pas le budget », alors que dans le même temps on me submergeait de demandes et on me reprochait les dysfonctionnements de l’appli que j’avais remontés au moment d’entrer en fonction. Et pour rire un peu à un moment j’ai demandé une barrette de 2 Go de RAM pour mon ordi et même pour ça j’ai bataillé pour l’avoir… Lorsque j’ai quitté le poste j’ai parlé avec le DSI de la situation pour éviter à mon successeur ce qui m’était arrivé, et il m’a répondu « de toutes façons si le projet change tous les trois mois de responsable on trouvera du monde pour te remplacer ». Enfin bref tout ça pour dire que je ne souhaite à personne ce qui m’est arrivé, et qu’il s’agit à un niveau caricatural d’un poste de chef de projet à fuir. D’ailleurs en deux ans il y a eu six personnes différentes à occuper mon poste, c’est dire…

Un dernier mot aussi pour remercier Nicolas Martignolle du blog le touilleur express qui m’a donné l’idée de cet article.

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Une société de services où il fait bon travailler
• Le battle développeurs commerciaux n’aura pas lieu

Cet article a été rédigé par Julien, membre de la communauté de blogueur JobProd. Julien a rejoint l’une de nos entreprises, faites comme lui :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date ). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Tous les articles de Julien

Vous souhaitez devenir blogueur pour JobProd ?

1. Vous êtes passionné de développement. Quelqu’un vous a-t-il “initié” ou auriez-vous aimé que ce soit le cas ?

Quand j’ai commencé à coder c’était il y a environ 5 ans, je souhaitais simplement créer un site internet pour partager des informations à propos d’un jeu vidéo. Mais petit à petit j’ai voulu améliorer ce site en ajoutant des « modules », mais en modifiant le code source pour qu’il corresponde à mes besoins. Puis j’ai appris le langage HTML/CSS pour créer mon premier site personnel. Enfin j’ai appris les autres langages PHP, MySQL, Javascript, etc. pour mes sites professionnels et personnels.

J’ai donc appris seul, je n’ai pas cherché à avoir un tuteur pour m’apprendre. Au final ce n’est pas plus mal car je suis tombé sur beaucoup d’erreurs qu’aujourd’hui je sais régler rapidement car je les connais déjà. J’ai pu apprendre en « sautant » des étapes des tutoriels pour apprendre que ce qui me convient et revenir plus tard sur les notions sautées.

Si on a un professeur, on doit donc suivre un programme spécifique, il n’est pas possible de sauter une étape et si on est bloqué le professeur vient et nous débloque. L’avantage d’être seul, c’est de mieux comprendre les erreurs, car il n’y personne à côté de vous,vous êtes obligé de chercher comment réparer/corriger cette erreur, on en apprend beaucoup plus que si quelqu’un vous donne la réponse. Il y a donc des avantages et inconvénients à ces deux modes d’apprentissage. A plusieurs il y a de l’interaction. Chaque mercredi quand je travaille avec les enfants, ils veulent tester de nouvelles choses et le font sans craintes car s’il y a un problème, on est là pour les aider.

2. Vous transmettez votre passion du code en donnant des cours au travers du programme “Les Voyageurs du Code”, qu’est-ce qui vous a donné envie de vous inscrire dans cette démarche ?

Une annonce a été postée sur l’intranet de mon école, je me suis donc inscrit à l’association pour partager mon savoir mais également montrer aux gens que ce n’est pas si difficile et compliqué qu’il n’y paraît.

Beaucoup de personnes prennent peur dès que les lignes de codes apparaissent (code source d’une page web, écran de démarrage d’un ordinateur (boot), messages de debug dans certains jeux, etc.). Or en connaissant la base de la programmation, on se rend compte que toutes ces lignes veulent dire quelque chose : elles donnent des ordres à l’ordinateur.

Le but de l’association est d’initier les gens à la programmation. Nous leur montrons HTML/CSS pour qu’ils comprennent la structure/le squelette des sites internet, mais aussi du Javascript qui montre la vraie base de la programmation : les variables, les fonctions, les conditions, les opérateurs, les différents type de variables,etc.

Ce qu’il faut travailler en tant que bénévole, c’est la capacité à simplifier ce domaine si vaste et complexe pour que tout le monde puisse s’y retrouver. On va donc dans la mesure du possible prendre des exemples du quotidien pour illustrer qu’est-ce que la programmation aux différents publics.

3. Pouvez-vous nous en dire plus sur ces exemples du quotidien ?

Pour la compréhension générale de l’ordinateur et d’un programme informatique, on prend l’exemple d’une machine à café ou d’un distributeur. Quand l’utilisateur appuie sur un bouton, le système va éxécuter une commande pré-définie. Un programme obéit toujours à des instructions. C’est le principe d’action-réaction. L’utilisateur demande quelque chose, l’ordinateur éxécute l’ordre.

La personne voulant coder doit alors donner des instructions pour que l’ordinateur les éxécutes. Généralement on ouvre le code source d’une page web et on leur explique que chaque ligne correspond à un ordre (le doctype, les balises de titres, les liens, etc.).

Pour expliquer les différents langages du web, j’aime bien donner l’exemple d’une voiture. L’HTML correspond à la structure, au squelette, le CSS au design et aux couleurs. À partir de là tout est optionnel : le Javascript pour ajouter un toit décapotable par exemple,etc. Chaque langage est différent et à des utilités propres. Il faut donc expliquer les différences simplement avec des exemples.

4. Le programme a été lancé par Bibliothèques Sans Frontières qui est à l’origine de la version française de Codecademy. Il a pour but d’initier un plus grand nombre de personnes et de « faire émerger des générations de citoyens éclairés, créatifs, inventifs ». Au sein de vos cours, quel public rencontrez-vous ? Vous adressez-vous également à des personnes qui ont vocation à devenir développeurs ?

L’association essaie de toucher le plus de personnes possible. Chaque mercredi nous apprenons aux enfants la logique de la programmation en leur faisant développer de petits jeux (avancer, reculer, tourner, jouer un son, etc.).

Lors des séances d’initiation, n’importe quel public est invité, enfants, ados, adultes, nous adaptons le cours suivant le niveau. Pendant ces séances nous présentons le but de l’association en leur montrant des exemples, et s’il reste du temps nous essayons de les faire coder. Si certaines personnes sont intéressées, elles peuvent s’inscrire à des séances de formation, où 2 heures par semaine on se retrouve pour apprendre à coder. Il existe également une formation intensive où pendant 4 jours consécutifs, nous apprenons à coder et réalisons de petits travaux.

Actuellement le public visé est plus les personnes ayant peu accès à l’informatique et qui n’ont pas forcément de travail, pour leur apprendre la base du code et pouvoir s’en sortir avec ce peu de bagage (pour créer par exemple son CV au format HTML, une page internet de présentation de ses travaux, etc.). Mais n’importe qui peut s’inscrire pour profiter des cours.

5. Que pensez-vous que la découverte du développement informatique apporte aux personnes novices ? Cela ouvre-t-il les esprits par rapport à l’image du métier de développeur en France ? Cela fait-il naître des vocations ?

La première fois que l’on montre un code source d’une page web à quelqu’un, celui est très étonné et presque dégoûté car selon lui c’est très compliqué et incompréhensible. Mais après lui avoir expliqué que chaque ligne signifiait quelque chose et en le faisant coder sa propre page internet, il se rend compte que c’est plutôt simple car il suffit d’écrire ce qu’on veut pour que l’ordinateur exécute l’action. Certaines personnes qui au départ avaient peur se retrouvent à la fin en train de coder.

La base que nous apportons permet de créer de simples choses mais qui peuvent être utiles, en entreprise par exemple. Si ce sont des personnes en difficulté et qu’elles sont capable de créer un CV ou une page internet en HTML, ça fait des connaissance en plus. Il faut persévérer pour en apprendre davantage ! Une personne que j’ai eu en formation m’a confié vouloir créer un site internet pour partager ses photos. Avec de simples bases en programmation c’est tout à fait possible, on peut créer ce qu’on a besoin et adapter selon ses envies. Si après les personnes trouvent ça amusant et veulent en savoir plus c’est un bonus.

6. Pensez-vous que cela fait avancer la reconnaissance et la compréhension du métier de développeur ?

Actuellement il est encore trop tôt pour voir les réactions sur les personnes de notre association. Le but étant de leur montrer que l’informatique et en particulier la programmation n’est pas uniquement destinée aux érudits. Même si les membres n’arrivent à faire que de petits morceaux de code, ils fonctionnent, c’est déjà bien, il faut les encourager.

Si après les formations cet apprentissage se transforme en passion, c’est super. Et si ce n’est pas le cas, ils auront néanmoins appris que chaque objet informatisé est en fait une succession d’ordre que quelqu’un à écrit dans un fichier ! Lors d’une des formations, l’une des personnes présente s’est rendue compte qu’en fait, toutes les choses informatisées que l’on utilise au quotidien sont réalisées par une ou plusieurs personnes, qui ont ordonnées au système de réaliser des tâches très précises.

7. Qu’est-ce que ces cours vous apportent à vous personnellement ?

Ça me permet de simplifier au maximum les explications. Expliquer quelque chose de complexe est un exercice très difficile, mais prouve que l’on comprend bien de quoi l’on parle.  »Si vous ne pouvez expliquer quelque chose simplement, c’est que vous ne l’avez pas bien compris » – Albert Einstein

Bien sûr, nous ne pouvons pas tout connaître, quand une personne nous pose une question et que l’on ne connait pas la réponse, on ne va pas lui mentir. Nous avons chacun des connaissances différentes sur plusieurs sujets.

Mais également, quand je vois que les personnes au départ souhaitaient abandonner parce que « c’est trop compliqué » et qu’au final elles arrivent à créer de petit programmes, c’est super. Il n’y a qu’en s’accrochant que l’on peut y arriver. Je suis tombé et je tombe toujours sur beaucoup d’erreurs, mais c’est en persévérant que l’on arrive à ses fins.

C’est vraiment une joie de partager ses connaissances avec d’autres personnes, mais c’est beaucoup plus gratifiant quand celles-ci réussissent.  »C’est le rôle essentiel du professeur d’éveiller la joie de travailler et de connaître. » – Albert Einstein

Max est étudiant à Epitech, et bénévole au sein des Voyageurs du Code : www.maxprudhomme.fr. JobProd est un intermédiaire atypique du recrutement pour développeurs passionnés qui sélectionne des entreprises IT où il fait bon travailler : www.jobprod.com/fonctionnement-developpeurs/

Merci Max d’avoir répondu à nos questions !

Et vous, qu’en pensez-vous ? Pour ou contre enseigner le code à tous ? Est-ce que cet article vous donne envie de passer à l’action ?

Cet article vous a plu ? Vous aimerez sûrement aussi :

• La parole aux développeuses
• Et toi, t’es développeur ou tu travailles dans l’informatique ?

(Je précise que ce qui suit vaut tout autant pour les développeurs qui recherchent un emploi en CDI. Sauf peut-être pour ceux qui postulent dans de très grandes SSII.)

Je lui propose d’oublier ce terme et lui explique que la lettre de motivation a pour objectif de commencer à dévoiler qui il est, et de montrer que ce qu’il a à apporter peut justement matcher avec l’entreprise. Il se trouve qu’en plus d’être passionné de code, il est musicien, il adore dessiner, et il postule dans une entreprise qui développe un jeu vidéo de zombies. A la fin de la discussion, je sens qu’il n’a pas vraiment envie de rentrer dans le moule des lettres de motivation habituelles, mais que des idées folles commencent à émerger chez lui. Ma réponse est « tu peux te lâcher ». Une heure plus tard il m’envoie sa lettre avec en signature :

.

.

.

(suspens)

.

.

.

Si je suis une entreprise et que je vois cela, je suis sure de lire le reste de sa lettre, de prêter attention à son CV, et de me souvenir de lui. Je ne dis pas que ce dessin suffit, mais s’il est accompagné d’éléments qui tiennent la route, il constitue une accroche et un vrai capital sympathie.

Il ne s’agit pas de vous mettre tous à dessiner, mais d’oser mettre de vous dans vos lettres de motivation, pour faire la différence et marquer les esprits dès le début. Vous êtes créatifs et surprenants au jour le jour dans votre métier de développeur. Nous le voyons au travers de chaque entretien et chaque rencontre avec vous, servez-vous en dans votre communication.

On vous en dit plus sur le coeur des lettres de motivation dans un prochain article. N’hésitez à vous abonner à notre flux RSS (en haut à droite) ou à nous suivre sur twitter : Suivre @JobProdDev

Sinon, vous pouvez aussi passer par JobProd pour chercher un job (un CDI la plupart du temps) : on s’occupe de tout

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Comment améliorer sa visibilité d’expert dans sa techno ?
• Réussir un entretien d’embauche

De nombreuses applications ont recours aux threads. Ceux-ci permettent notamment de lancer des opérations asynchrones, ou tout simplement d’éviter de bloquer la GUI. Seulement, la facilité de lancer un thread fait qu’on est tenté d’appeler directement new Thread() dès qu’on veut en lancer un. Or il s’agit d’une erreur pouvant avoir de fâcheuses conséquences sur les performances de l’application pour plusieurs raisons :

• Lancer un nouveau thread coûte très cher en terme de CPU. Rien que la commutation volontaire d’un thread vers un autre coûte 80000 cycles CPU, car il faut passer d’une pile à l’autre, vider certains registres, etc, etc.
• Si on n’y prête pas garde, le nombre de threads lancés par votre application peut dépasser le nombre de coeurs d’exécution disponible sur la machine sur laquelle l’appli est déployée. Et là c’est catastrophique car le processeur passera alors plus de temps à effectuer des commutations de threads qu’à exécuter votre code.

Dès lors, voyons quelques bonnes pratiques pour l’usage des threads.

Implémentation d’une classe devant tourner dans un thread

Quand on implémente une classe devant tourner dans un thread, il est tentant d’hériter directement de java.lang.Thread. Or il s’agit là d’une erreur de design, car si votre classe a besoin d’hériter d’une autre classe, vous ne pouvez pas le faire. Le mieux est que votre classe implémente directement l’interface java.lang.Runnable, qui contient directement la méthode public void run() appelée par java.lang.Thread.

Ensuite, pour lancer le thread, il convient d’appeler la méthode start() et non la méthode run(), cette dernière n’exécutant pas de thread mais exécutant simplement le code de votre méthode run().

Trucs et astuces sur l’implémentation des threads

Si vous lisez la doc des threads, vous verrez qu’il y a quelques méthodes qu’il ne faut en aucun cas appeler :

• suspend()
• resume()
• stop()

En fait c’est tout simplement parce qu’elles ne sont pas considérées comme sûres. Dès lors voici une petite implémentation permettant d’avoir tout de même ces fonctionnalités. Comme vous pouvez le constater, tout n’est pas idéal non plus car le stop et le suspend n’ont pas d’effet immédiat. D’un autre côté on évite ainsi d’interrompre un traitement en cours brutalement, ce qui permet de ne pas avoir d’état indéfini lorsqu’on suspend l’exécution de notre thread.

public class MyRunnable implements Runnable {

   /**
    * The lock monitor, used to manage suspend/resume.
    */
   private final Object lockMonitor = new Object();

   /**
    * Flag indicating that the thread must be stopped. Note that it is volatile to ensure that all threads
    * always take the last value written into account.
    */
   private volatile boolean isStop;

   /**
    * Flag indicating that the thread must be suspended. Note that it is volatile to ensure that all threads
    * always take the last value written into account.
    */
   private volatile boolean isSuspend;

   /**
    * Constructor.
    */
   public MyRunnable() {
      this.isStop = false;
      this.isSuspend = false;
   }

   /**
    * Stop the thread.
    */
   public synchronized void stop() {
      this.isStop = true;
      lockMonitor.notifyAll();
   }

   /**
    * Suspend the thread.
    */
   public synchronized void suspend() {
      this.isSuspend = true;
   }

   /**
    * Resume the thread.
    */
   public synchronized void resume() {
      this.isSuspend = false;
      lockMonitor.notifyAll();
   }  

   /**
    * {@inheritDoc}
    */
   public void run() {
      while (!this.isStop) {

         synchronized(lockMonitor) {
             while (this.isSuspend) {
               try {
                  lockMonitor.wait();
               } catch (InterruptedException e) {
                  / Log exception
               }
               if (this.isStop) {
                  return;
               }
            }
         }

         / Do your stuff
      }
   }
}

Gestion manuelle des pools de threads

Pour gérer manuellement un pool de threads, le plus simple à faire est d’avoir d’un côté votre implémentation de java.lang.Runnable qui contient un traitement, et de l’autre côté une BlockingQueue qui contient la liste des tâches à exécuter, sur laquelle on aura bien pris soin de définir une taille.

L’idée est en fait qu’un ou plusieurs threads vont produire des descripteurs de tâches, et un ou plusieurs threads vont les traiter. La blocking queue va mettre les producteurs en attente quand elle sera pleine, et les consommateurs en attente quand elle sera vide.

Le dernier truc à faire est d’ajouter à tout ce beau monde un flag permettant de savoir quand tout doit être arrêté.

J’ai mis ici un exemple de code pour la gestion manuelle d’un pool de threads.

L’ExecutorService

Le rôle de l’ExecutorService, apparu avec Java 5, est de permettre de gérer plus simplement un pool de threads. L’idée est qu’au départ on dimensionne l’ExecutorService pour un certain nombre de threads, et ensuite on lui passe des Callable our des Runnable à exécuter de manière asynchronie.

Un bon article (en anglais) présente de manière plus détaillée l’ExecutorService.

Et alors, que choisir entre une gestion manuelle des pools de threads et l’ExecutorService ?

Il est vrai que la gestion manuelle de pools de threads demande d’écrire un peu plus de code, par contre son point fort par rapport à un ExecutorService auquel on soumettrait en peu de temps un grand nombre de tâches est de permettre d’éviter de saturer la mémoire. L’ExecutorService utilise aussi une BlockingQueue de Callable et Runnable pour obtenir le même résultat, mais sans qu’on ait directement la main dessus, bref après c’est selon les goûts et les couleurs.

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Les toolkits graphiques et les threads
• De la nécessité d’utiliser des structures de données thread safe en environnement multithread
• Quelques principes d’architecture d’applis Web en Java/JEE

Cet article a été rédigé par Julien, membre de la communauté de blogueur JobProd. Julien a rejoint l’une de nos entreprises, faites comme lui :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date ). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Tous les articles de Julien

Vous souhaitez devenir blogueur pour JobProd ?

Commentaires sur l’étude

Vous pouvez accéder à toutes les questions de l’étude en cliquant ici.

1) Salaire par technologie de prédilection

Voir en grand le graphe

Note importante : Les questions qui étaient posées dans l’étude étaient : « quelles sont vos technos de prédilection » et « quel est votre salaire actuel, variable compris ». Si un tech a répondu « .NET » et « Python », alors son salaire compte pour les deux catégories. Il ne s’agit donc pas des technos « principales » (utilisées dans leur emploi par exemple), mais bien des différentes technos « usitées » par les techs. Par ailleurs, ici on parle de l’ensemble de la communauté des « tech », donc c’est très global. C’est pour cette raison que l’on a préféré afficher un pourcentage d’écart à la moyenne plutôt qu’une valeur absolue (un salaire moyen sur la communauté des techs pour telle techno). On peut se rendre compte que :

• Maîtriser Ruby ou Python paie bien (+11,6% par rapport à la moyenne des techs). En effet, il y a une forte demande de la part des entreprises sur ces technos (et leurs frameworks très en vogue comme Rails ou Django) mais peu de techs les maîtrisent (faible apprentissage à l’école, beaucoup de passionnés ou d’autodidactes dans ces catégories).
• Les bonnes vieilles « technos objet » comme java, C#, .NET… sont au dessus de la moyenne (+3,1%). Sans grande surprise, les techs qui les maîtrisent sont mieux payés par les recruteurs. C/C++ est pile à la moyenne.
• JavaScript est au dessus de la moyenne aussi (+1,3%) : dans le web, c’est quasiment un incontournable à présent (avec tous ses frameworks). Cette techno est difficile à maîtriser mais vos efforts paieront !
• Fréquemment, pour iOS ou Android de forts salaires sont pratiqués. Alors pourquoi ces technos sont un brin en dessous de la moyenne (ou disons dans la moyenne) ? Une explication possible est que c’est une techno que beaucoup de techs découvrent et utilisent de façon « amateur » et qu’ils insèrent à leurs « technos de prédilection » (question du sondage). Pourtant ce n’est bien souvent pas la techno essentiellement utilisée dans leur emploi. Si vous voulez être bien ou très bien payé dans le mobile, faîtes en votre passion et votre coeur de métier !
• PHP est en dernière position : techno utilisée par tout le monde où souvent l’on peut observer une disparité de niveau très forte (entre ceux qui maîtrisent réellement et codent « objet » et ceux qui bidouillent). Rassurez-vous, l’expérience montre que si vous êtes spécialistes, vous serez certainement dans la moyenne des salaire (un peu comme les technos mobiles).

2) Salaire par métier

Voir en grand le graphe

Note importante : au vu du faible nombre de réponses côté directeur technique, nous avons décidé de les intégrer aux experts techniques / architectes (en les enlevant, cela n’influe pas -moins de 0,1%- sur les salaires présentés dans cette catégorie).

Plus l’expérience augmente, plus la qualification « lead développeur » (responsabilités) ou « expert technique » (expertise) influe sur le salaire.

• Lead dev/dev. Les « lead dev » sont mieux payés de 9,6% par rapport aux « dev » pour les moins de 2 ans puis cela double à 18,2% pour les 2-5 ans, puis 20,4% pour les plus de 5 ans.
• Expert technique / dev. 10,3% d’écart pour les moins de 2 ans, puis 19,4%, puis 28,7% !
• Expert technique / lead dev. Salaires très proches pour les moins de 5 ans, 7% d’écart salarial observé pour les plus de 5 ans. L’expertise paie donc un peu mieux.

Ce qui est intéressant de voir c’est que l’on peut faire carrière dans la technique avec un salaire et des responsabilités ou un niveau d’expertise qui évoluent vraiment. Le route « développeur > Chef de projet au bout de 2 à 5 ans » est loin d’être la seule. Si l’on est passionné de technique, on peut en faire toute sa vie !

3) Salaire par taille et type d’entreprise

Voir en grand le graphe

Note importante : les salaires sont « hors avantages en nature » (tout comme dans la totalité de l’étude).

• Effectivement les petites entreprises (moins de 20 salariés) paient moins que les autres (même si l’écart n’est pas énorme), surtout en comparaison avec les entreprises de 201-500 employés quelque soit l’expérience.
• Les petites PME (21-200 salariés) paient clairement mieux que les autres pour les 2-5 ans (plus de 10% d’écart !). Une explication possible est que cette catégorie d’entreprise a un besoin plus fort en techs de 2-5 ans d’expérience que les autres tailles d’entreprises. En tout cas, chez JobProd, nos clients sont constitués à 80% de ce type d’entreprises et ils cherchent à croître avec des techs déjà expérimentés, mais difficiles à trouver sur le marché (donc salaire plus élevé). Nous entendons très fréquemment : « nous cherchons des 3 ans minimum ! ».

Voir en grand le graphe

Note importante :  Deux biais peuvent venir de cette étude par type : 1) la notion de startup, agence, SSII, éditeur peut être subjective 2) les sondés pouvaient répondre plusieurs catégories (tout comme les technos), par exemple « startup » et « agence web » s’ils considèrent que leur agence est aussi une startup, du coup leur salaire compte dans les 2 catégories.

• Il est intéressant d’observer que les éditeurs paient les mieux globalement, en tout cas jusque 5 ans d’expérience. En effet ils cherchent souvent les meilleurs techs car le logiciel EST leur métier.
• Les SSII, contrairement aux idées reçues, paient « dans la moyenne » et ne sur-paient pas leurs jeunes collaborateurs (moins de 2 ans) pour les attirer. Ce sont plutôt les startups qui pratiquent un salaire élevé pour les jeunes. En revanche, effectivement l’écart est important entre une agence web et une SSII (17% d’écart salarial) pour les moins de 2 ans d’expérience, et c’est peut-être de cet écart que l’on parle communément.
• La progression des salaires (depuis les moins de 2 ans jusqu’aux plus de 5 ans) dans les SSII est vraiment faible comparé aux autres types d’entreprises : 31% pour les SSII, contre 45% dans les startups, 73% dans les agences et 40% les éditeurs.
• Les startups sont en tête du peloton, voire sont premières pour les plus de 5 ans. Les fleurons IT de l’économie de demain paient bien leur techs et c’est une bonne nouvelle !

4) Salaire par lieu géographique

Voir en grand le graphe

En Ile-de-France, le salaire des techs est plus élevé de 18% par rapport à la province. Ceci est à rapporter à une étude réalisée par l’INSEE en 2006 (il y a 8 ans) indiquant que le coût de la vie est de 13% supérieur en IDF qu’en province. Si vous trouvez une étude plus récente, n’hésitez-pas à nous en faire part dans les commentaires. Sinon en ce qui concerne les techs :

• Les salaires sont quasi-identiques pour les moins de 2 ans (2,6% d’écart)
• On observe 25,8% d’écart pour les 2-5 ans d’expérience (écart le plus fort).
• Et 12,4% pour les plus de 5 ans d’expérience.

5) Différences homme/femme

Voir en grand le graphe

Note importante : au total 33 femmes ont répondu à l’étude en donnant leur salaire, soit 6,2% des personnes interrogées, hors apparemment, en 2011, les femmes ingénieures dans l’IT représentaient 20,3% de la population (« Ingénieurs de l’informatique et des télécom » page 12 de cette étude.)

• Ce qui est intéressant c’est que, chez les techs, les hommes gagnent en moyenne (toutes expériences confondues) 15% de plus que les femmes. Selon cet article de l’Express publié en 2012, l’écart dans la population des cadres en France est de 20% entre les hommes et les femmes (tous les techs qui ont répondu à l’étude ne sont pas des cadres, mais ceci permet de donner un comparable). Malgré ces disparités (dont une des explications est la discrimination sans raison), les tech-girls paraissent mieux loties que la moyenne.
• Par ailleurs, dans ce même article il est indiqué que « L’écart de salaire médian « augmente avec l’âge ».
  

« Peu élevé chez les cadres les plus jeunes (2%), il croît entre 30 et 34 ans (7%), puis entre 40 et 44 ans (16%) pour se stabiliser à un niveau élevé (22%) à partir de 45 ans. »

Il est intéressant de retrouver cette tendance (croissance de l’écart avec l’expérience) dans notre étude : nous avons 1% pour les moins de 2 ans, puis 5% pour les 2-5 ans, puis 20% pour les plus de 5 ans.

6) Variable dans le salaire

28% des techs ont un salaire avec un variable. Donc 72% des techs ont un salaire purement fixe. Maintenant, voici plus de détails par taille, puis type de sociétés :

• Par taille de société. Quand le variable n’est pas nul, il est le plus élevé chez les entreprises de moins de 20 personnes (15%), assez logique, car le risque est important et donc partagé avec les collaborateurs.
• Si l’on prend en compte les techs dont le variable est nul (non affiché dans cette image), cela donne : 2% pour les moins de 20 employés, 3% pour les 21-200, 2% pour les 201-500 et 3% pour les 500+ salariés. Globalement le variable est faible chez les techs, contrairement aux commerciaux où le variable peut représenter la moitié ou plus du salaire global. Les techs ont pourtant des objectifs tout aussi importants que les commerciaux, mais il est fréquent de rencontrer des entreprises qui ne savent pas sur quels objectifs indexer le variable des techs. Vous avez des commentaires ? Commentez

• Par type de société. Quand le variable n’est pas nul : il représente 14% pour les agences contre 7% pour les SSII, soit 2 fois plus de variable côté agences. Avez-vous une explication particulière ?
• Si l’on prend en compte les techs dont le variable est nul (non affiché dans cette image), cela donne : 4% pour les agences, 1% pour les startups, 3% pour les éditeurs et 2% pour les SSII.

7) Salaire, épanouissement et prétentions salariales

Ce qui ressort de cette étude c’est que 43% des techs se déclarent satisfaits ou très satisfaits de leur salaire (donc 57% ne le sont pas). Mais si l’on considère les 2 diagrammes ci-contre, on se rend compte que :

• Parmi ceux qui se déclarent satisfaits (les 43%), nous avons 85% de techs qui se déclarent « épanouis » dans leur emploi.

• Parmi ceux qui se déclarent insatisfaits (les 57%), nous avons 74% de techs qui se déclarent « épanouis » dans leur emploi.

Apparemment, le salaire n’est pas un critère prépondérant dans l’épanouissement au travail chez les techs (pour en savoir plus, il suffit d’attendre le 3ème volet de notre étude !). On peut se risquer à dire que le salaire « contribue à 11% » (85%-74%) dans l’épanouissement des techs. Nous attendons vos commentaires

Voir en grand le graphe

Enfin, dernier point, en moyenne les développeurs souhaitent voir leur salaire évoluer de 19% :

20,7% pour les moins de 2 ans
17,6% pour les 2-5 ans
18,6% pour les plus de 5 ans

• « Où est la French Tech, celle des développeurs ? », par Kwame Yamgnane, de l’Ecole 42,
• « Développeur, le plus beau métier du monde »
• « Donnons aux développeurs la place qui leur est due »
• « Les développeurs un atout pour la France », le rapport de Tariq Krim

L’idée commence à se répandre que la technique n’est pas assez valorisée, qu’elle est utilisée pour «maintenir» des systèmes existants avec des pansements au lieu de tirer partie de tout son potentiel : créer de la valeur et de l’innovation. Heureusement, il y a tout un tas d’entreprises du numérique qui se saisissent de ces enjeux. Mais combien d’autres, très grandes ou moins grandes, restent dans ce mode de fonctionnement ? Et de combien de développeurs ne met-on pas en valeur le réel potentiel ?

Nous sommes de ce combat ! C’est ce qui nous a mené en combinaison de ninjas à La Défense, c’est ce qui nous anime dans notre mission au quotidien.

Mais je sens aussi fleurir dans la tête de certains l’idée qu’après tout, les développeurs seraient bien tout seuls pour créer les entreprises du numérique. Vous imaginez le rêve ? Il n’y aurait plus d’incompréhensions.

Certes. Cependant :

- On entend partout que Mark Zuckerberg était un développeur. On omet de dire qu’il avait étudié la psychologie et que c’est ce qui a permis a Facebook de comprendre de quoi les gens avaient besoin.

- On parle de Deezer fondée par un développeur. On ne dit pas au passage que le co-fondateur est un Essec.

- Etc. etc.

Alors, oui, il y a des entreprises montées par des personnes uniquement techniques. Mais ces personnes ont avec elles un grand nombre d’atouts business, une compréhension des besoins de leurs utilisateurs, une capacité à manager, des envies commerciales, des compétences pour diriger une entreprise, etc. Car non, un produit développé se vendra rarement tout seul, ou alors il faudra qu’il ait été conçu dans cet objectif (et on en revient aux compétences business).

Les VC qui sont intervenus lors du “Meilleur Dev de France” étaient formels : une bonne équipe sur laquelle investir, c’est une équipe qui allie des compétences techniques et business et des profils complémentaires. Ne nous faisons donc pas d’illusion : que ce soit en tant que développeur entrepreneur ou en tant que salarié, la solution ne réside pas dans le fait de se couper des autres, mais bien de s’allier à ceux qui sauront voir la force de la complémentarité des compétences techniques et business et y accorder toute son importance.

Voici donc Zenika interviewée par JobProd :

Dans quel esprit se crée une société de service où il fait bon travailler ?
Zenika est née de la volonté de ses fondateurs, anciens consultants Java, de créer l’entreprise au sein de laquelle ils auraient aimé travailler : des valeurs humaines fortes (transparence, partage et convivialité), une expertise technique tout aussi forte, et la possibilité d’être multi-activités : les développeurs ont l’occasion d’exercer 3 métiers : le développement, le conseil et la formation.

Quel a été votre sentiment lorsque vous avez appris votre classement à la 7ème place de Great Place to Work ?
C’est tout d’abord une belle reconnaissance et c’est intéressant de connaître l’avis de tous ceux qui composent Zenika. Nous étions contents d’apprendre, par exemple, que 92% des collaborateurs sont très épanouis chez nous ! Nous prenons aussi très à coeur les axes d’amélioration qui ont été soulevés. Nous avons organisé dans la foulée, lors de la présentation trimestrielle dans chaque agence, des sessions en mode Agile afin de prendre l’avis de tous les collaborateurs sur comment faire mieux, et mettons en place une guilde, composée de salariés, pour prendre en compte ces retours.

Quels sont, selon vous, les critères importants pour devenir une Great Place to Work pour les développeurs ?
S’améliorer en permanence, se remettre en question, demander l’avis des collaborateurs et partager.

Vous êtes aujourd’hui 120 collaborateurs, comment faites-vous pour maintenir cet esprit et vos valeurs en grandissant ?
La clef réside tout d’abord dans le recrutement, nous nous assurons au préalable que le candidat et Zenika partagent les mêmes valeurs. Ce qui rend le recrutement plus difficile et parfois plus risqué, mais cela nous permet de nous inscrire dans la durée.
Nous veillons également à garder un équilibre au sein de notre organisation afin de fluidifier les process.

Vous inspirez-vous d’un modèle pour vous développer ?
Le modèle de la société s’inspire en partie de ce qui est décrit dans le livre de Vineet Nayar « Employees First, Customers Second ». Chez Zenika, le Salarié est au centre de toutes les préoccupations et son épanouissement est fondamental pour la réussite de l’entreprise et maintenir un service de qualité auprès de nos clients.
Les entreprises lauréates du Palmarès Great Place to Work sont également d’excellentes sources d’inspirations. Nous les rencontrons lors des matinales ou journées organisées par GPtW et échangeons autour de nos bonnes pratiques managériales.
Les collaborateurs en interne sont aussi une source d’inspiration : les dirigeants font en sorte de se rendre disponibles pour discuter avec eux et proposent des rendez-vous Zenika spécifiques de partage : des réunions autour de la culture de l’entreprise, des chats hebdomadaires, des zAfterworks etc.

Lors de vos recrutements, quelles sont les qualités que vous recherchez chez les développeurs ?
- La passion,
- Avec un bon relationnel et l’envie de partager son expertise et ses compétences avec les autres collaborateurs de Zenika et la communauté,
- Un très bon niveau technique ou une forte capacité à monter en compétence.

Qu’apportez-vous aux développeurs ?
- Une communauté
- Un environnement challengeant et apprenant, au fait des dernières technologies (la veille se fait automatiquement chez nous, via l’échange, des NightClazz, des TechnoZaures, etc.)
- Une évolution professionnelle : le management ne se fait pas par les commerciaux mais par les consultants.

En terme de bien-être au travail, quel est le sens de votre partenariat avec JobProd ?
Zenika a commencé à travailler avec JobProd en décembre 2012 parce que nous nous sommes retrouvés sur l’attention portée au bien-être au travail et sur l’exigence envers les candidats. De plus, de la même façon que nous nous inspirons de modèles vertueux pour construire Zenika, JobProd étant plus jeune, elle a pu aussi s’inspirer de nous dans sa construction, grâce à la relation qui s’est établie entre nos dirigeants respectifs, notamment entre Carl Azoury et Romain Brouard.

Quels sont vos prochains projets pour poursuivre votre objectif de bien être au travail ?
Nous souhaitons continuer à nous remettre en question en permanence, apprendre des retours de nos consultants, bénéficier de nos coachs agiles et des méthodes agiles et chaque année, se faire challenger par un classement comme Great Place to Work.

Merci Laure Vallade, Responsable Recrutement, pour vos réponses !

Vous souhaitez en savoir plus sur Zenika ? Cliquez ici.

Vous souhaitez découvrir d’autres sociétés de service, PME et startups où il fait bon travailler pour les développeurs :

Si comme moi vous avez (encore) un PC sous Linux avec chipset Nforce 5xx (MCP55), vous aurez peut-être remarqué que quand vous tentez de passer le PC en veille ce mode ne fonctionne pas sur les noyaux récents.

En fait vous allez voir sur l’écran un curseur qui clignote et au bout d’un moment le PC va revenir à son état initial ou faire un freeze. Le problème vient en fait d’un bug kernel qui fait que le mode asynchrone pour la mise en veille ne fonctionne pas avec ce chipset.

Le fix est en fait relativement simple à appliquer, il suffit d’ouvrir un terminal et de taper la ligne suivante :

echo 0 > /sys/power/pm_async

La mise en veille devrait alors fonctionner de nouveau. Et pour rendre les changements permanents, copiez cette ligne dans le fichier /etc/rc.local juste avant la ligne exit 0.

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Trucs et astuces Linux
• Réparer l’erreur 0×80070002 du Windows Store

Vous aussi vous avez envie d’écrire des articles ?

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date ). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
En savoir +