Un environnement de developpement Java

J’ai eu envie de faire un petit développement personnel en Java et comme j’avais réinstallé mon ordinateur, je devais refaire mon environnement depuis le début. Ce n’est d’ailleurs pas un si grand mal et l’exercice serait même intéressant car il arrive que nous devions le faire quand par exemple une défaillance de notre IDE survient comme un crash d’Eclipse réduisant à néant la configuration du workspace.

En partant d’une distribution classique Ubuntu 64 bit avec les dépôts officiels, peut-on monter un environnement de développement Java ? Est-il nécessaire d’installer des logiciels manuellement et donc maintenir par soi-même les mise-à-jour ? Est-ce que l’installation est accessible ou nécessite-t-elle une équipe système ? Pour réponde à ces questions il faut commencer par définir ce dont nous avons besoin.

Le système d’exploitation est un Linux abordable: Ubuntu. Nous supposons qu’il est déjà installé et fonctionnel. C’est une supposition très raisonnable. A partir de là il nous faut obtenir un environnement de développement Java complet comprenant :

  • un outils de modélisation
  • un éditeur de source
  • un compilateur
  • un outils de versionnage
  • un outils d’intégration continue

L’outil de modélisation sera bien pratique pour les phases préliminaires avant tout codage et devra permettre au moins la génération de code. L’opération inverse sera aussi utile car une fois emporté dans le code on risque bien d’oublier l’architecture générale et voire même la galvauder dans notre élan. Nous pouvons soit opter pour outils dédié  comme BOUML ou bien se contenter des fonctions UML de l’IDE. LEs 2 IDE open-source majeurs propose de l’UML.

L’IDE doit permettre d’écrire du code, d’apporter la coloration syntaxique, l’assistance à la frappe, le debogguage et le support de plusieurs JVM. L’IDE ne doit pas nous enfermé dans un système propriétaire de build et devra donc s’interfacer simplement avec notre outil de build préféré : Maven. Nous porterons notre choix sur Netbeans dont l’offre “packagée” estplus complète que Eclipse et mieux adapté que ce dernier pour une utilisation avec Maven.  La version 6.0 est installable directement depuis Ubuntu en utilisant Synaptic. Il faudra ajouter les plugins Subversion, Maven et UML pour completer l’installation de base. Cela ce fait directement depuis l’ID.

La partie compilateur dans le cas de java se compose du JDK  qui est l’ensemble des outils pour compiler et debugger des programmes écrit en Java. Le JDK contient aussi un JRE qui permet d’éxécuter les programmes Java. C’est le point de départ de notre environnement. Les dépots officiels d’Ubuntu propose OpenJDK 1.6 donc son installation se fera le plus simplement du monde via le gestionnaire de paquet Synaptic.

L’outils de versionnage devra permettre un refactoring constant du code et devra gérer le renommage les déplacements de fichiers sans perte d’historique sans avoir recours à l’administration du serveur. On choisira naturellement subversion dont l’installation est possible depuis les dépôt Ubuntu.

L’intégration continue est une pratique obligatoire dans les projets nécessitant plusieurs développeurs ou plusieurs module devant être assemblés. Cependant même dans le cas d’un seul développeur il aura besoin de découper le projet en modules qui devront être assemblés. Un outils permettant d’assurer le que l’ensemble “fonctionnent” correctement est nécessaire. Afin de simplifier l’intégration nous allons choisir Continuum qui se marie à merveille avec Maven. Son installation se fera manuellement en décompressant l’archive trouvé sur le site officiel de continuum

Enfin pour terminer la liste des outils nous mentionnerons l’outils de build maven qui est avec l’intégration continue les éléments le splus importants de l’environnement de developpement d’un point de vue structurel. Nous allons installer maven par le biais de Synaptic. Pour simplifier et offrir une évolutivité maximal dans l’utilisation de maven nous allons utiliser le gestionnaire de repository Apache Archiva

Maintenant que tout est installé, il faut s’assurer que tout fonctionne bien ensemble. Pour cela l’article suivant traitera de la création initiale du projet.

Etes-vous agile ?

Les méthodes de développements sont assez nombreuses et vont de la classique méthode du cycle en V aux méthodes dites agiles en passant par une étrange mais néanmoins utilisée méthode dite “pas de méthode”. Bien-sûr le dégrée de maturité de l’organisation conditionne la méthode utilisée. Il est courant donc de voir des organisations de très petites tailles, dont le cÅ“ur de métier n’est pas le développement de logiciel, opter pour l’étrange méthode avec un succès qui dépend uniquement de la capacité du responsable à gérer sans méthodes son activité. Il est étonnant de constater que cela marche… parfois. Il suffit simplement d’avoir confiance en l’extraordinaire faculté d’adaptation de celui qui dispose d’une bonne volonté à gérer le désordre. Au contraire une organisation plus mature dont le but est le développement de logiciel aura sans doute adopté une méthode : cycle en V pour certaines ou méthodes itératives pour d’autres mais avec toujours un penchant pour la mise en place de processus écrasant pour le développeur.

Qu’est-ce que l’agilité ? L’agilité est la faculté de pouvoir s’adapter en changeant rapidement d’orientation, de position afin de répondre plus rapidement au besoin du milieu. Les informaticiens de la nouvelle génération c’est-à-dire ceux qui sont arrivés sur le marché après 2000 sont assez au courant des méthodes agiles mais sont souvent contraints d’appliquer les méthodes que leur organisation aura mis du temps à éprouver.  Cela ne veut pas dire que le choix d’une méthode ou l’autre est le simple fait de la génération car si les méthodes agiles paraissent modernes, il ne s’agit rien d’autre que la formulation de principes issus  du bon sens et de l’expérience acquise par la pratique de développeurs chevronnés durant les années 90. L’agilité semble aujourd’hui être de plus en plus utilisée comme une évidences qui s’impose.

Quelles sont les raisons de cette adoptions ? La difficulté de prendre en compte les modifications de spécification en cours de projet quand sont utilisées des méthodes à effet tunnel. La difficulté de détecter les incompréhensions des développeurs à cause de l’effet tunnel. A ces raisons parmi d’autres visant directement la réussite du projet , s’ajoute de véritables raisons sociologiques. Ce qui est frappant des les méthodes agiles, notamment XP, c’est la mise au centre du développeur qui avait peu à peu pris une place d’éxécutant dans le processus de plus en plus complexe et encadré de la production de logiciel. C’est d’ailleur un des arguments des détracteurs des méthodes agiles qui disent que c’est la méthode des nostalgiques du temps de l’informaticien dans sa tour d’ivoir. C’est un argument simpliste car les méthodes agiles au contraires rapproche le développeur de l’utilisateur et visent améliorer l’adéquation entre le besoin et le logiciel, la perception de l’avancement et l’état réel de l’avancement. Les méthodes agiles sont des méthodes pragmatiques et efficaces car elles partent d’une approche “down-top” et non pas “top-down”.

Nous abordons alors un point très controversé dans notre culture française. En effet le système français globale est organisé autour de l’élite. Nous avons un système politique et éducatif qui prône l’élitisme c’est-à-dire la mise en avant des individus plus par l’origine corporatiste que par la démonstration de compétences dans un domaine donnée. Mais cette tendance est d’ailleur en train de changer comme le montre l’exemple de l’actuel président qui n’est pas sorti de l’ENA. Si dans la politique on assiste à une “américanisation”, il est intéressant de remarquer que ce n’est que la consécration d’un mouvement général qui touche aussi le monde de l’informatique dans sa dimension “sociologique”. Il est en effet remarquable de voir comment les méthodes agiles commencent à faire leur chemin en plaçant la compétence première de l’informaticien au centre du processus de production de logiciel. Il est en effet plus facile de contrôler une machine quand on est à l’intérieure de celle-ci.

L’agilité en informatique relève d’une culture particulière des individus, qui je pense, ne se décrète pas. Est-ce que cela s’apprend-t-il ? Peut-être. L’informaticien agile est réaliste, courageux, honnête et possède un certain sens de la qualité de travail. Ce sont là des qualificatifs que l’on attribuerait volontiers à un amoureux de son métier, à un simple travailleur de la base… Le concept de méthode agiles dans son côté très pratique serait-il à rapprocher de celui de la lutte syndicale… L’idée m’effleure souvent. Prenons l’exemple de la charge de travail. En méthodologie agile, on admet que le développeur doit conserver un rythme de travail régulier et ne jamais recourir aux heures supplémentaires pour satisfaire au délai. Si un dépassement survient, on enlève des fonctionnalité pour tenir le délai. C’est une gestion résolument tournée vers le bien être de l’individu.

Je pense que c’est la dimension sociologique des méthodes agiles qui freine leur adoption dans les organisations. L’évangéliste doit alors appliquer une conduite au changement à une population d’informaticien du “middle au top management”. Cette population est souvent culturellement non ouverte aux méthodes agiles. L’évangéliste doit alors user de tout son pouvoir de démonstration et de persuasion pour parvenir à ces fins. Et vous, êtes vous agiles ?