Architecte

J'ai récemment assisté à une formation d'architecture sur le framework maison. J'étais super enthousiaste. À vrai dire, je ne savais pas trop ce que c'était qu'un architecte logiciel et comment il pouvait occuper ses journées.

Alors, un archi c'est quoi ?
Et bien, c'est une personne qui va concevoir une solution pour répondre à un besoin de son client. Cette solution peut être technique, inscrite dans le SI de l'entreprise avec une description allant jusqu'au niveau serveurs, versions de logiciels à utiliser, etc. Un architecte peut aussi être orienté métier : les solutions ne sont en effet pas systématiquement techniques (même si elles sont techniquement systémiques !).
Par exemple, imaginons que l'objectif d'une entreprise est d'accroitre sa présence à l'international. Elle peut pour cela revoir son portail Internet mais aussi ouvrir des points de vente dans des pays clés. Tout dépend de la culture, des valeurs et des principes de l'entreprise. Tous ces éléments constituent le contexte d'étude de l'architecte.

C'est la partie qui m'a le plus intéressé : l'importance du contexte. Il est nécessaire de connaître l'entreprise cliente en profondeur pour modeler la façon dont on va répondre à sa demande. Toutes les étapes par lesquelles passe l'architecte au cours de sa démarche doivent être développées en fonction de cette analyse contextuelle.

Clairement, cette formation m'a donné un nouveau regard sur mon métier. L'objectif n'est pas de chercher la meilleure techno du moment et essayer de l'imposer. Au contraire, il s'agit de s'imprégner de son client et de son métier, de sa culture pour lui proposer les solutions qui lui conviennent le plus et qu'il pourra lui même porter. Le but ultime est de présenter des solutions au client et qu'il choisisse sa solution, celle qu'il pourra défendre auprès des parties prenantes.

Mais qu'est-ce qui m'arrive ? Au lieu de codeur, je deviens consultant ou quoi ?

Dernière remarque culturelle : vous avez peut-être entendu parler de la loi de Conway. Je pensais au départ que c'était une fatalité liée à la difficulté des organisations à changer et à innover. Maintenant, je comprends que c'est simplement parce que c'est là le but recherché de l'architecture d'entreprise...

Faites vos pâtés dans le bac à sable, les jeunes

Quelque chose m'attriste quand je vois la méthodologie employée par certains pour travailler sur du code shell ou PL/SQL. On ne vous a pas appris : c'est normal de faire des conneries !

• Pour le code shell, ils éditent directement sur le serveur de développement et ne récupèrent leurs sources que quand leur code fonctionne.
• Pour le PL/SQL, ils modifient le code directement en base de données et copient/collent ou enregistre le code en local lorsqu'il fonctionne.

Je n'ai qu'une chose à dire :

== You're doing it wrong! ==

Au boulot, nous travaillons (classiquement) avec Subversion. Svn, comme tous les gestionnaires de code source modernent utilise une sandbox qui est l'endroit ou vous modifiez localement le code source avant de la valider dans le dépôt central. Les jeunes et moins jeunes : vos modifications doivent d'abord être faites dans votre sandbox et toujours prètes à être commitées.

Avec la méthode évoquée plus haut, vous vous exposez simplement à perdre tout votre travail.

• Pour le shell, vous pouvez accidentellement écraser votre copie de travail sur le serveur avec votre copie locale en faisant une bête erreur de FTP.
• Un collègue peut involontairement supprimer vos modifications en faisant une installation(ce collègue peut se prénomer Hudson ou Jenkins, il y en a peut-être un dans votre équipe)
• Le point précédent est valable pour le PL/SQL.
• Pour le PL/SQL, comme pour le shell, en cas de crash ou d'indisponibilité du serveur, vous pouvez au mieux être dans l'incapacité de récupérer votre code, au pire vous le perdez. Vous êtes dans l'incapacité de livrer : c'est comme si vous n'aviez pas travaillé.

En synthèse, votre poste de développement est plus stable que le serveur. Vous en avez le contrôle total. Développez sur votre poste et testez sur le serveur. Vous pouvez également prendre le temps (10 minutes) d'automatiser le transfert et vos tests.

Remarques complémentaires

Dans des situations plus particulières, le code que vous travaillez peut être également modifié par un tier simultanément (c'est fou le monde moderne... OK, ça arrive souvent.). Travailler dans votre sandbox vous permet d'intégrer les modifications au fil de l'eau plutôt qu'en fin de dev (si vous travaillez avec un refactoreur psycopathe comme moi ça peut vite être le drame).

Vous pouvez compléter l'utilisation de Svn par un gestionnaire de code source décentralisé (comme Git ou Mercurial) que vous faites fonctionner en local. Git vous permet de faire des commit intermédiaires (c'est sur votre PC alors OSEF), de tester des choses dans des branches locales sans risquer de perdre ou de casser quoi que ce soit. À l'inverse, le dépôt central Svn ne devrait contenir que du code valide (mais ça ne vous empèche pas de commiter votre code baclé avant votre départ en congés).

Pomodoro Technique

Je m'essaie depuis quelques semaines à la pomodoro technique.

Il s'agit d'une pratique de gestion du temps. Les principaux éléments proposés sont les suivants :

Ce qu'on a à faire doit être divisé en tomates (pomodoros). Une tomate ayant une durée de 30 minutes, c'est à dire 25 minutes de travail et 5 minutes de pause.

Une pause plus longue (entre 15 et 30 minutes) est accordée toutes les 4 tomates.

Lorsqu'on commence une tomate, on règle un minuteur sur 25 minutes. Tant que le minuteur tourne, on se force à éviter les interruptions externes (un collègue nous demande quelque-chose) comme internes (envie de traîner sur twitter). Lorsque le minuteur sonne, on arrête la tâche en cours et on prend 5 minutes pour faire quelque chose sans rapport avec la tâche : gérer les interruptions, marcher, traîner sur twitter,...).

Cette méthode nous permet de réserver un temps pour ce concentrer sur les tâches à réaliser. Limiter le temps permet d'éviter une certaine forme de fatigue, la perte de concentration et de productivité. Combien de fois, dans le cadre d'un développement informatique, vous êtes-vous plongé dans votre code, faisant des sessions de 3 heures ou plus ? Vous en sortez fatigué et vous avez l'impression que sur la fin, vous n'avez pas été aussi productif que vous l'auriez souhaité. Vous avez en quelque sorte piétiné. D'autre part, il peut vous arriver aussi que des personnes viennent vous poser des questions ou demander un coup de main lorsque vous travaillez sur une tâche, voire que vous ayez besoin de chercher une information sur Internet et que vous divaguiez de lien en lien dans une spirale de procrastination. Je suis souvent confronté à ces cas de figure. La pomodoro technique vise à éviter cela.

Dans un second temps, la méthode propose de se faire un plan de tomates (!) à réaliser par jour et de répertorier le nombre de tomates nécessaires pour accomplir vos tâches. Cette pratique vise plusieurs objectifs. Tout d'abord, vous pouvez tenter d'améliorer votre organisation afin de réaliser un maximum de tomates par jour. Si deux tomates font une heure, vous devriez théoriquement être capable de réaliser 12 tomates par jour, si on prend en compte des pauses de 30 minutes. Essayez et vous verrez que ce n'est pas si simple. D'autre part vous pouvez tenter d'améliorer votre productivité sur les tâches récurrentes, de battre votre score. Enfin, si vous enregistrez à peu près tout ce que vous faites, vous serez capable d'estimer avec précision le temps qu'il vous faut pour réaliser une tâche donnée même si vous avez plusieurs tâches à réaliser dans le même laps de temps. Je trouve cet aspect assez génial sur le papier.

L'étape ultime sera d'utiliser la technique en équipe, d'une part parce que vous n'aurez ainsi plus l'air d'être le seul cinglé à compter des tomates, d'autre part, parce que cela donne une certaine culture d'équipe et permet de découper les séances de travail collaboratif, comme des réunions ou du développement en binôme.

Pour finir, peut-être considérez-vous comme irréalisable l'idée d'avoir un minuteur qui fait tic tac et qui sonne en plein openspace. Sachez qu'il existe une kyrielle d'applications pour vous minuter. J'utilise personnellement Flow Keeper, qui permet d'écouter le click au casque (j'ai toujours un écouteur dans l'oreille, tant pis). Les réels challenges de cette technique est de bien penser à démarrer les tomates, de bien penser à faire les pauses et surtout de savoir gérer les interruptions tant interne qu'externe. Il faut y aller progressivement et se laisser le temps de bien faire.

Autre lien :
Site officiel de la Pomodoro Technique.