Jean-Denis, 29 ans, a intégré Agixis il y a 6 ans en tant qu’ingénieur d’études et développement spécialisé en C# .net, à la suite d’un IUT Génie Électrique Informatique Industrielle (GE2I) et de sa formation au sein de l’école parisienne Sup’élec.

 

Agicien depuis 2011, Jean-Denis a pu évoluer dans la société de manière permanente

Depuis mon arrivée, j’ai travaillé sur divers projets, qui étaient plutôt des projets applications industrielles. Mes premières missions de développement se sont fait sur des logiciels qui existaient déjà. J’ai œuvré sur 3 projets différents.

Au cours de plusieurs missions variées j’ai rencontré beaucoup de défis techniques et organisationnels ainsi que beaucoup de personnes ayant des compétences à transmettre. En 5 ans j’ai pu évoluer vers un poste de lead technique .net. Actuellement, je mets au profit de mes projets des compétences de développement, d’architectures logicielles, de compréhension fonctionnelle et de maîtrise de qualité logicielle. Avec plus de recul sur les challenges rencontrés je suis force de proposition pour des solutions fonctionnelles et techniques.

Grâce à mes diverses missions sur des technologies Microsoft en constante évolution, voici quelques exemples de points bloquants résolus.

 

1. Performances et fiabilité

 

Je suis intervenu sur un projet concernant une application mobile dont le rôle est de faire de la relève de données de capteurs (par radio). Un module de l’application m’a été confié car il posait problème sur les terminaux portables à vitesse de calcul réduite. En effet, ce module chargé de visualiser les capteurs sur une carte centrée sur la position GPS avait 3 problèmes majeurs :

–       performance : à partir de 50 capteurs, le temps de rafraîchissement de l’affichage dépassait plusieurs secondes, et augmentait de façon exponentielle avec le nombre de capteurs (O(n) = exp(n)).

–      évolutivité : de nouvelles évolutions étaient difficilement réalisable, le code existant manquant de bonnes pratiques de conception.

–      fiabilité : la récupération de positions GPS s’arrêtait au bout de peu de temps.

 

Pour régler les aspects de performance et d’évolutivité, la solution a été de concevoir une architecture permettant de séparer les rôles du code dans un modèle objet et de factoriser les calculs.

 

L’emploi de matrice de transformation sur les coordonnées a permis d’avoir une vitesse d’affichage beaucoup plus importante.

 

Pour calculer la position en 2 dimensions d’un point (X1;Y1) en appliquant une rotation, il faut calculer les cosinus et sinus de l’angle à appliquer. Sur des processeurs lents, ces opérations sont longues. La bonne pratique a été de calculer la matrice de rotation, puis de l’appliquer à tous les points. Quel que soit le nombre de points, la matrice est calculée une seule fois (1 seul cos et sin). L’application d’une matrice est une opération de somme et multiplication qui requièrent beaucoup moins de temps de calcul.

 

La fiabilité du traitement de signal GPS a été améliorée en cloisonnant les deux fonctions suivantes :

–       la réception du signal GPS, dépendant de la puce.

–       la mise à jour de la carte avec la position la plus la récente.

 

Chaque fonction s’exécute sur un thread d’exécution spécifique. Grâce à une synchronisation des threads utilisant le ReaderWriterLockSlim, le partage de données de position entre les threads se fait de façon fluide et sans conflit d’accès. En appliquant la séparation des responsabilités, le 1er des principes SOLID, la fiabilité et la fluidité de l’application a été amélioré.

 

2.Architecture applicative

 

Une application client lourd C# WPF, composé de plusieurs modules, à nécessité une refonte d’architecture. Le design pattern MVVM était correctement implémenté.

 

En théorie, le pattern MVVM se limite à l’interface utilisateur. Un ViewModel étant une classe permettant d’agir sur la vue sans en dépendre, il est malheureusement fréquent que la logique métier soit répartie dans la couche de ViewModels. C’est tolérable sur une petite application (par exemple des applis AngularJs contiennent parfois toute la logique métier), mais cela pose de gros problèmes dès que l’application grossit.

En effet 3 problèmes apparaissent :

–       réutilisation des règles métiers impossible

–       compréhension difficile des règles métiers dans le code

–        tests plus complexes

 

Ce problème a été réglé en mettant en place une architecture en couches définissant les règles métiers dans une couche de logique. Le pattern MVVM se trouve alors dans la couche la plus haute : User Interface. Cette architecture classique n’est pas parfaite et ne permet notamment pas d’isoler le domaine des aspects techniques. Une architecture type hexagonale est préférable sur des applications plus larges et évolutives, mais cette architecture doit être choisie au début des développements.

 

 

3. Ergonomie fluide 

 

Un projet d’application web asp.net proposait classiquement un upload et un téléchargement de fichiers, à partager entre plusieurs utilisateurs.

Dans le but de fluidifier la modification d’un fichier (Office, type Word ou Excel), une solution technique devait être trouvée.

 

Dans la solution classique les actions pour éditer un fichier sont :

–       ouvrir la page web concernée

–       cliquer sur le lien de téléchargement du Word

–       une fois que le téléchargement est terminé, cliquer sur le fichier dans la rubrique téléchargés du navigateur, Word s’ouvre.

–       après modification du document, enregistrer le fichier

–       retourner sur le navigateur et cliquer sur le bouton d’upload

–       dans la boîte de dialogue qui s’ouvre, choisir le fichier sur le disque (risque d’erreur et action pénible)

–       le fichier est renvoyé vers l’application

 

La solution retenue a divisé par 2 le nombre d’actions manuelles, en supprimant la plus risquée et la plus pénible :

–       Ouvrir la page web concernée

–       Cliquer sur le lien du Word, Word se lance et ouvre le fichier

–       Après modification du document enregistrer le fichier

–       Le fichier est automatiquement mis à jour dans l’application

 

L’architecture de l’application est plus complexe, et s’appuie sur Microsoft SharePoint, dont l’API, combinée à quelques astuces, permet d’ajouter automatiquement des fichiers et de récupérer un lien d’édition. De plus l’édition simultanée d’un fichier par plusieurs utilisateurs est possible et ne pose pas de problèmes de conflit. SharePoint fournit une gestion des droits suffisamment flexibles pour donner aux utilisateurs un accès en lecture uniquement, en écriture sans suppression, ou droits complets.