La propagande initiale du langage Java était write once, run anywhere. OK c’est sympa mais dans les faits ce n’est quand même pas tout à fait vrai. Par ailleurs le confort des développeurs est très important à prendre en compte notamment pour qu’ils puissent être les plus efficaces possibles et arrêter d’être embêtés pour de mauvaises raisons (qui a dit manque d’espace disque ?). Enfin bref on va voir tout ça.
Débloque les + belles offres tech en 10 mins
Les limites du multiplateforme en Java
Il est vrai qu’un programme Java peut fonctionner pratiquement tel quel quelle que soit la plateforme. Sauf que ce n’est pas tout à fait vrai. Tout d’abord, le système de fichiers peut avoir un comportement très différent suivant la plateforme choisie. Certains seront case sensitive, les jeux de caractères interdits pourront différer et les politiques de verrouillage des fichiers vont changer. Par ailleurs la performance du système de fichiers influe grandement sur la performance de l’application, ainsi une application rapide sur les vrais systèmes peut être lente sur W—–s et inversement.
L’autre élément impactant concerne les applications graphiques, même si celles-ci sont de moins en moins courantes en Java. Le comportement peut là encore grandement changer suivant la ou les plateformes cibles, aussi dans le cas d’une application graphique multiplateforme il est capital de tester le comportement de l’application sur toutes les plateformes pour éviter les mauvaises surprises.
Enfin l’architecture matérielle cible peut avoir une grande influence sur les performances. Ainsi les processeurs SPARC gèrent très bien un grand nombre de threads, mais ont une puissance faible pour des traitements monothreadés. Ce point est à prendre en compte, même si pour du développement il apparaît difficilement envisageable d’utiliser autre chose que du x86.
L’environnement matériel pour le développement
L’environnement matériel pour le développement est capital. Un développeur compilera facilement son code une cinquantaine de fois par jour, aussi s’il met une minute à réaliser cette compilation au lieu de deux, il pourra travailler une heure de plus par jour. Alors je vois le grand chef du fond qui dit ah oui mais il n’a qu’à rester plus tard le soir, je m’en fous moi, jusqu’au jour où l’équipe de ce chef lui claquera la porte au nez justement parce que je m’en fous moi. Et ça arrive bien plus souvent qu’on ne croit, même si ce n’estp as encore assez à mon goût.
Bref il ne faut pas hésiter à renouveler régulièrement l’équipement des développeurs histoire qu’ils ne passent pas leur temps à attendre. A l’heure où j’écris ces lignes, le matériel suivant apparaît être un minimum :
– Core i7 3770 ou supérieur
– Système d’exploitation 64 bits
– 8 Go de RAM
– Un disque dur rapide voire un SSD pour le système
Si par ailleurs l’environnement de développement est vraiment lourd (qui a dit Eclipse avec 25 projets ouverts ??? ) 16 Go de RAM ne seront pas du luxe.
Notez bien cependant que dans quelques années il faudra des machines plus puissantes. Alors certes la puissance des processeurs ne va pas beaucoup augmenter dans un futur proche car on approche des limites de la physique, mais le stockage et la mémoire vive ont également une grande influence sur les performances. On pourra citer notamment l’impact des SSD sur la réactivité globale d’une machine.
Le système d’exploitation idéal
Toute application, quelle qu’elle soit, est destinée à fonctionner dans un ou des environnements cibles. Et croyez-le ou non, rien n’est pire pour un développeur que d’observer un comportement sur un environnement cible qui n’est pas reproductible sur son poste de développement à cause des changements de plateforme.
Il se trouve que les applications en Java fonctionnent principalement sur des serveurs Web, lesquels fonctionnent sous Unix ou Linux. Par conséquent pour des applications correspondant à ces caractéristiques les développeurs devraient coder sous le même OS que l’Unix cible, ou a minima sur un Linux dans le cas où des contraintes particulières s’appliquent, telles qu’un système cible sous AIX.
Dans tous les cas rien n’est pire que de travailler sur un environnement W—–s alors que votre cible de déploiement est un Unix, ou inversement. C’est un coup à se tirer une balle dans le pied, et à augmenter les coûts. Et en toute objectivité en terme de rapidité Linux est à des années lumière du machin de Bill Gates. Pour la petite histoire mon vieux PC perso qui a sept ans, un Phenom x4 9850 avec 8 Go de RAM sous Debian, est plus réactif qu’un Core i5 3470 sous W—–s 7.
Par contre dans le cas où votre application cible différents systèmes d’exploitation il est important d’avoir des développeurs qui travaillent sur chacun des systèmes ciblés. Ainsi certains travailleront sur W—–s, d’autres sur Linux, et d’autres encore sous Mac si besoin.
L’outil de codage
Actuellement dans le monde Java il existe trois environnements de développement (IDE) principaux :
– Eclipse
– IntelliJ IDEA (à noter que la version Community, gratuite, suffit amplement pour du Java)
– Netbeans
Je ne vais pas rentrer dans le débat stérile de savoir lequel est le mieux. Toujours est-il qu’il est utile de demander régulièrement à vos développeurs si leur IDE leur convient. Eclipse est devenu le standard de fait, mais de nombreux développeurs préfèrent IntelliJ ou Netbeans.
N’oubliez pas que passer sur un nouvel IDE nécessite un apprentissage, ce qui explique pourquoi je suis toujours resté sur Eclipse par flemme d’apprendre les raccourcis clavier d’IntelliJ.
Par contre au sein d’une même équipe il apparaît nécessaire d’uniformiser les outils ainsi que le système d’exploitation utilisés, et ce afin de limiter les différences de comportement entre les postes de développement. De même et pour la lisibilité du code il est nécessaire de mettre en place et d’utiliser des templates de code. Idéalement on pourra créer une distribution custom de l’IDE choisi contenant des préférences uniformisées pour tout le monde, ainsi que la liste des plugins nécessaires pour faire fonctionner le projet.
… et le reste
Il existe tout un tas de petites choses qui peuvent rendre la vie agréable ou pas pour les développeurs. Par exemple les infrastructures mutualisées se doivent d’être fiables. J’ai connu une entreprise où le SVN tombait trois matinées par semaine, et donc on pouvait jouer aux cartes pendant ce temps.
De même dans le cas où des licences sont nécessaires pour utiliser ou développer telle ou telle fonctionnalité il faut faire en sorte que les gens n’aient pas à attendre des journées entières avant de pouvoir travailler… faute justement de licence. Dans la même veine on pourra aussi citer le filtrage internet, qui bien souvent bloque des sites auxquels il pourrait être nécessaire d’avoir accès pour le travail.
Enfin bref ce sont plein de petites choses qui mises bout à bout, font qu’il sera agréable, ou pas, de travailler.
En bref
Choyez vos développeurs, ils vous le rendront, et ça commence par leur environnement de travail. De même si vous n’en prenez pas soin les premiers à partir seront ceux que vous voulez garder. Alors ne faites pas comme tous ces idiots qui pensent que le développeur est un machin interchangeable, vous risqueriez sinon de le regretter un jour…
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Développeurs, managers, clients : voici comment mener à bien un projet IT en 4 points clefs
- Ce que votre code peut dire de vous… ou de votre organisation
- Comment un manager peut-il (bien) challenger un développeur ?
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.
