Archives par mot-clé : Génie Logiciel

Le processus de développement agile

Quand je faisais du conseil, je parlais de l’intérêt de l’agilité.

Depuis que j’ai lancé Target2Sell, je le vis 🙂

L’équipe de développement est au taquet sur ces questions.

On fait plusieurs mises en productions par semaine.

Les mises en production ne font pas d’interruption de service.

Le processus est complètement automatisé, et met à jour une trentaine de serveurs, avec un mécanisme de rotation de manière à assurer la continuité de service.

2000 tests sont exécutés automatiquement à chaque « build ». Un build est lancé automatiquement à chaque « commit » poussé sur la branche principale de développement.

Avec un rythme aussi rapide, le risque de bug majeur est extrêmement réduit en fait. J’étais bien plus nerveux quand on faisait une mise en production par Sprint de 15 jours.

On est en mode Devops, il n’y a pas d’équipe dédié opérationnel, chaque développeur est responsable, depuis la conception jusqu’à l’exploitation.

Pas de territoire réservé non plus, chaque développeur peut agir sur n’importe quelle partie du code. Bien sûr, chacun se spécialise quand même en fonction de ses affinités Florent a pris en main Spark, Cyrille et JP ont bien investi Cassandra…

Tout cela permet d’avancer vite et bien, avec de bons échanges : le développement, c’est en permanence de la négociation, entre aller vite, et ne pas accumuler trop de dette.

You aren’t gonna need it

Comme vous le savez si vous suivez un peu ce qui se passe sur ce blog, on bosse sur le lancement d’un nouveau produit.

Quand on fait du logiciel, on doit en permanence faire des choix : fonctionnel ou architecture.

La réponse, m’a été donnée par :  YAGNI : You aren’t gonna need it

 L’idée, simple, c’est que tant qu’on n’a pas vraiment besoin de quelque chose, le mieux est de ne pas le faire !

Cela me semble un très bon guide même si dans certains cas, on doit forcément regarder « un peu plus loin que le bout de son nez » !

(merci François)

Génie Logiciel ; Génie : y es-tu ?

Le génie logiciel, c’est l’art de faire du logiciel de qualité.

D’accord, mais c’est quoi la qualité ?

Bonne question, merci.

La qualité, c’est la combinaison de plusieurs choses :

  • Un code qui répond au besoin. Et oui, pas la peine de philosopher, la première des choses est de couvrir le besoin fonctionnel.
  • Un code sans bug. Bon, c’est un « graal », tout programme a ses bug. La question est donc de réduire au maximum les bugs et surtout d’éviter les bug « mortels ».
  • Une application qui répond vite. Ce critère est particulièrement important pour le web et le e-commerce en particulier. Quelques dixième secondes de trop, et les clients sont parti…
  • Une application scallable. C’est la suite logique du point précédent. L’application doit répondre vite, même en cas d’affluence. Le système doit donc être capable d’avaler des pics de charges, et il doit être possible de faire grossir le système, en rajoutant des serveurs. ça à l’air de rien, mais si on n’y a pas pensé, la montée en charge va demandé pas mal de boulot.
  • Une application robuste. La particularité des applications Internet, c’est, entre autre, qu’elle doivent « vivre » dans un environnement instable. L’application, pour tourner, s’appuie sur tout un tas de services tiers. Et bien la robustesse, c’est que l’application garde un comportement « sain » même quand des composants tiers tombent. On appelle ça la dégradation douce (smooth degradation).
  • Une application évolutive. L’application va vivre, et il doit être facile de faire évoluer l’application, pour un cout raisonnable.

Bon, on pourrait en ajouter mais là, on a l’essentiel.

ça, c’est l’objectif.

Maintenant, la question, c’est : comment on atteint cet objectif ?

Là, la réponse n’est pas simple. Pas simple du tout en fait.

Au delà des objectifs assez factuels (moins de bug), d’autres objectifs sont plus délicats. Ainsi, « une application évolutive » est un objectif délicat. La difficulté est qu’on doit prévoir quels seront les axes d’évolutions. Ainsi, après développement, certaines parties seront faciles à faire évoluer, et d’autres non. La très mauvaise idée est de vouloir « tout faire évoluer ». Cela revient exactement au même que… ne rien dire. Dans ce cas, c’est l’équipe technique qui décide ce qui sera évolutif et ce qui ne le sera pas.

Une autre difficulté est qu’on est sur un terrain très instable. Les technologies évoluent très vite, et les demandes fonctionnelles aussi. Une application web doit donc être particulièrement souple.

Mais dans le même temps, on a rarement le temps de bien analyser, bien concevoir, bien développer. On veut faire vite, avec des équipes plus ou moins compétentes.

Ah la compétence des équipes ! C’est un bon sujet aussi. Puisque faire du logiciel, au final, c’est faire du code, la qualité du code sera directement en lien avec la qualité des développeurs.
En ce moment, la demande est très forte. La conséquence « mécanique » est de baisser le niveau d’expertise des développeurs (Il s’agit bien sûr d’une généralité, et bien sûr, il y a de très très bon développeurs).

Suite au prochain épisode 😉

De l’importance de bien utiliser une solution e-commerce

Vous avez de grandes ambitions, et vous souhaitez refaire votre site e-commerce.

Vous avez fait (ou fait faire) un cahier des charges.

Vous avez choisi une solution open source (prestashop ou magento) et vous avez sélectionné une bonne agence, qui va faire les développements.

Quelques mois plus tard, le nouveau site est en ligne.

Bien sûr, tout n’a pas été facile : certaines fonctions qui étaient dans le cahier des charge n’ont pas été développées. Le planning a dérapé, …

Mais bon, globalement, le nouveau site est là, et vous êtes plutôt content d’avoir un nouvel outil, qui va vous permettre de décrocher la lune.

…

Rapidement, vous déchantez. On vous avait vanté les mérites de la solution open source choisie, la richesse fonctionnelle, les milliers de modules, la communauté.

Votre sentiment est d’être coupé de tout ça !

Pourquoi ?

Parce qu’a chaque fois que vous voulez ajouter une fonction, qui normalement s’active d’un simple clic depuis le back office, votre site est tout cassé.

Ou alors vous installez un module, et le résultat est le même : au mieux, le module ne fonctionne pas. Au pire, il casse le site.

Pourquoi tant de haine ?

La raison est simple : l’agence qui vous a développé votre boutique n’a pas respecté les standards de la solution. Au lieu de faire des développements sous forme de modules, de respecter l’architecture de la solution, ils ont « tapé dans le dur » et modifié directement le code du coeur de la solution.

Le résultat est que la boutique fonctionne… Mais que plus rien n’est évolutif. Vous devez faire développer toute évolution.

Moralité : il est super important de bien valider que la boutique que vous développez respecte les choix d’architecture de la solution retenue.

Faire du logiciel, c’est une histoire de processus et de culture

Bon, je commence par expliquer que faire du logiciel, c’est de l’artisanat.

Et ensuite, je fait un billet ou je parle de processus ?

Oui, et les deux sont parfaitement compatibles !

Dans le billet précédent, j’explique, pour faire simple, que ce qui compte, avant tout, c’est la compétence des équipes. Chaque développeur doit être au top.

Après, il ne s’agit pas simplement de mettre X développeurs et d’attendre que le temps passe.

S’il est complètement fondamental de responsabiliser au maximum chaque développeur, il est également indispensable de mettre en place des méthodes, des processus très précis.

A ce titre, je vous conseille de regarder cette vidéo, qui explique les processus en place chez Facebook :

Facebook a un processus de mise à jour qui permet une mise en production tous les jours (!!!)

Donc, pour reprendre le titre :

La culture, c’est celle du dieu code.

Les processus, ce sont toutes ces méthodes et outils qui permettent d’automatiser au maximum la chaîne de production, tout en gardant le maximum de responsabilité entre les mains des développeurs.

Les méthodes à mettre en place sont bien sûr basées sur les méthodes agiles.

Faire du logiciel, du développement, c’est de l’artisanat

Je déjeunais ce midi avec un ami de longue date.

On échange souvent sur le développement logiciel (entre autre sujets, je vous rassure 😉 )

Notre conviction commune, c’est que faire du logiciel, du développement, c’est un processus artisanal et pas industriel.

Je me suis déjà exprimé là dessus.

Dans la pratique, dans mon (mes ?) métier(s), quand je dis ça, je sens bien que c’est « contre productif » :

  • Les boites qui vendent du « processus industriel » à tour de plaquettes commerciales se sentent agressées, et se défendent en m’agressant à leur tour ;
  • Les clients qui connaissent mal tout ça (et c’est bien normal, ce n’est pas leur métier) se disent que l’artisanat, ça fait moins pro que « processus industriel ».

D’un point de vue rationnel, pourtant, c’est assez basique :

Un processus industriel, cela consiste à fabriquer un produit, avec un processus bien défini, qui permet d’accélérer la production, et de multiplier le nombre de produits fabriqués, en garantissant que tous les produits sont bien conforme au cahier des charges, tout cela avec un coût maîtrisé.

Cela passe par une séparation très forte, entre différents métiers.

L’ingénieur, qui conçoit le processus, décompose la chaîne de fabrication, et conçoit des machines, qui permettront de reproduire les mêmes actions, rapidement et sans faute.

De l’autre côté de la chaîne (c’est le cas de le dire), l’ouvrier derrière la machine a un travail répétitif, travail qui est d’ailleurs de plus en plus souvent remplacé par des machines, des robots.

Dans le monde du logiciel, cela n’existe pas, et, pire, quand on tente d’appliquer de telles méthodes, on arrive à des catastrophes.

Au final, ce qui marche, au contraire, c’est le recrutement des meilleurs développeurs, et de leur confier des missions ou ils pourront avoir le maximum d’autonomie.

On est donc bien dans un processus artisanal, ou ce qui compte, c’est la qualité de l’artisan.

Un exemple parmi des centaines :

Apple a eu besoin de 60 personnes pour créer iOS.

Motorola, qui essayait de faire la même chose, avait mis sur les rang 1500 personnes.

Qui a réussi ?

On est donc dans une industrie ou ce qui compte, c’est la grande qualité de quelques personnes clés. Et je ne parle pas des managers, mais bien des développeurs !

Quand tu veux Yves, pour poursuivre ce passionnant sujet 😉

Les outils pour enrichir le CSS

Le CSS, c’est le langage qui permet de faire la mise en forme des pages web.

Cela permet de séparer le fond de la forme : le HTML contient le fond (le texte en particulier), et la décoration se fait via le CSS (la police, la taille, les bordures, …).

Bon, ça, c’est la théorie ;).

Dans la pratique, écrire une couche présentation en CSS est très technique, avec certaines parties plutôt répétitives et impossible à factoriser. Exemple : un site utilise une palette de couleurs. Impossible, en CSS, de définir des constantes avec ces codes couleurs.

Sinon, quand on n’arrive pas à faire ce qu’on veut en CSS, on le fait en Javascript.

Certains proposent d’améliorer tout ça avec des « méta langages » au dessus de CSS.

Exemples : SASS, LESS, …

SASS est une technologie côté serveur, on passe son code CSS enrichi dans la moulinette SASS et ça ressort un code CSS standard.

Si j’ai bien compris, LESS permet à peu près la même chose, avec une technologie Javascript, qui peut être côté client ou serveur.

Je ne rentrerais pas dans le détail, ce n’est pas l’objet de ce blog.

Je trouve que c’est une super bonne idée, que de proposer des langages, ou méta langages, qui permettent de programmer plus propre, plus court.

Mais cela ouvre la voie suivante :

Le code que j’écris n’est pas le code envoyé côté client.

Avantage : le code que j’écris est plus court, de meilleure qualité.

Inconvenient : ce que je vais débuggé n’est pas ce que j’ai écrit.

Mon avis, très clairement, est que c’est bien l’avenir !

Je pense depuis longtemps qu’à moyen terme, les langages du web n’ont pas vocation à être manipulés directement : ce sont, de mon point de vue, des langages de trop bas niveaux, avec des contraintes beaucoup trop complexes. Je pense bien sûr en particulier au problème de multi-terminal / multi navigateur.

Pour prendre une analogie, cela me fait penser au Postscript : c’est un langage de bas niveau pour piloter les imprimantes (ou autres interfaces d’ailleurs). Mais personne n’aurait l’idée d’écrire à la main du code Postscript !

J’ai donc la conviction qu’il devrait sortir des systèmes qui vont bien plus loin dans cette voie :

C’est une voie étroite, parce que, de mon point de vue, ces systèmes doivent être spécifiques web, alors que ce qu’on voit bien souvent, ce sont des frameworks génériques, et je ne crois pas du tout à cette approche.

C’est pour cela que je trouve les initiatives type LESS ou SASS particulièrement intéressantes : on améliore la qualité, de manière très spécifique au Web.

Et vous, qu’en pensez vous ?

Quel futur pour les systèmes e-commerce

Assez rapidement, quand on développe un système e-commerce (à ma connaissance, je suis le seul à utiliser ce terme, je devrais le déposer 😉 ), on doit découper le système en plusieurs composants.

Mais le découpage est rarement satisfaisant.

Rarement satisfaisant ?

  • La plupart du temps, une bonne partie des fonctions se recoupent entre les différents composants ;
  • L’expérience des utilisateurs métier n’est pas cohérente. Chaque composant propose son propre back office, et les équipes métiers, qui travaillent sur ces interfaces, doivent jongler d’un système à l’autre
  • Les mises à jours deviennent complexes, avec des coûts et des délais difficile à bien anticiper, parce que, comme chaque composant propose sa propre logique, il faut adapter « profondément » l’évolution à chaque composant

Alors, ou est le bug ?

Est-ce une erreur de découper un problème en sous parties ?

Non, bien sûr, le problème n’est pas là.

Le problème est assez simple en fait :

Les modules qu’on assemble ne sont pas réellement fait les uns pour les autres, tout simplement.

L’assemblage est donc un « bricolage ». Je ne mets pas en doute le travaille technique (c’est un autre sujet). Mais brancher ensemble deux systèmes qui ne sont pas fait pour ça, ça ne peut pas faire une solution de qualité (malgrés les promesses commerciales…). Ou alors, le cout devient rédhibitoire.

Alors, quelle est la solution ?

Il faut être pragmatique. Cette solution n’est pas complètement satisfaisante, mais c’est bien souvent la meilleure qu’on ait sous la main. Cette réflexion est donc plus une réflexion « moyen terme » qu’autre chose.

Pour aujourd’hui, une bonne tactique, c’est bien souvent d’identifier un composant « leader », et d’effectuer un assemblage autour de ce composant central.
Un autre élément de qualité, c’est de monter une architecture SOA. Cela permet au moins de définir des contrats clean entre les composants.

Demain, je suis convaincu que les choses vont/doivent changer…

Un des éléments qui doit bouger, j’en ai la conviction, c’est la couverture fonctionnelle d’un composant.
Pour moi, c’est la base d’une architecture à base de plusieurs « briques » : chaque brique doit répondre à une description fonctionnelle très précise. Et qu’on arrête de mélanger interface et coeur du système !
Je n’invente rien en disant ça, j’applique simplement les fondamentaux de la conception modulaire, qui n’ont pratiquement pas bougés depuis 20 ans :
Un module doit définir clairement son interface métier (son API quoi) : c’est le contrat qui doit être rempli par le module.
D’ailleurs, sur des briques plus anciennes, et donc plus mûres, la promesse est bien plus claire. Exemple : un système de gestion de bases de données… gère des données. Les choses sont bien séparées entre le moteur et l’interface. On devrait avoir ce type de séparation, pour monter notre système e-commerce de demain.

C’est un sujet excitant, parce qu’il y a beaucoup à faire, et beaucoup de valeur à apporter !

Si cela vous intéresse d’en savoir plus sur ce sujet passionnant, que vous avez une expertise d’architecte, vous connaissez bien la technique, et vous vous dites que l’aventure est peut être pour vous, contactez moi !

Evolution du modèle de programmation du web – Retour vers le futur

Au début, avant Internet, il y avait des ordinateurs qui fonctionnaient en mode client serveur.

Le serveur gérait principalement les données, et l’applicatif tournait sur le client.

Après, il y a eu Internet.

Comme les premieres versions du HTML étaient très pauvres, l’application c’est naturellement déportée vers le serveur. C’est ce qu’on appelle le serveur d’appication.
Dans ce modèle, le serveur fournit à peu près tout : il livre au client une page complète, que le client n’a qu’à afficher. L’intelligence côté client est très légère.
Cela ressemble à ce qu’on fait sur les gros système (CICS par exemple : vous savez, ces écrans textes avec les caractères en vert qu’on voit si on regarde les écrans des vendeurs dans pas mal de boites…).

Mais le web s’est enrichi, avec le Javascript, et la possibilité de développer des applications bien plus intelligentes, bien plus sophistiquées, et surtout bien plus agréables à utiliser.
Cela veut dire que, dans ce modèle, l’intelligence est répartie entre le serveur et le client. Plus la couche Javascript est évoluée, et plus l’intelligence est déportée vers le client.

Avec les évolutions actuelles du web, on peut légitimement penser que c’est bien le sens de l’évolution pour les prochaines années : revenir en fait à un modèle ou l’intelligence applicative est principalement sur le poste client.
Côté serveur, on gère principalement la couche des données.
Sur un modèle en trois couches MVC (modèles / vue / contrôleur), les deux autres couches, vue et contrôleur sont donc déployée sur les postes clients.

Prenons un exemple : un site e-commerce au hasard 😉

Ce que doit gérer le serveur, c’est bien l’ensemble des données du système :

  • Le catalogue, avec l’ensemble des produits, et toutes les informations associées à ce catalogue : description, prix, stock, …
  • La base des clients
  • La base des commandes

Certaines de ces données peuvent, pour des raisons de performance, être gardées sur le poste client. Exemple : la hiérarchie des produits. Mais les données qui « bougent » doivent absolument être stockées côté serveur. Exemple : le stock produit.
Tout le reste pourrait très bien être géré côté client.

Avantages de ce modèle :

L’application peut être bien plus évoluée que ce qu’on fait en web classique. On peut avoir une bonne idée de ce modèle, avec, par exemple, la navigation dans un catalogue en Ajax : quand on applique un filtre, la page n’est pas raffraichie, seuls les produits changent. C’est un peu la préhistoire du modèle que je présente.

Autre avantage : la consommation, en bande passante, est bien plus optimisée. Une fois l’applicatif chargé sur le poste client, on n’échange que les données nécessaires. Pas besoin de renvoyer l’ensemble de la template du site à chaque page.

Les technologies sont assez développées pour permettre de mettre en oeuvre ce modèle dès aujourd’hui.

En fait, ça ne serait pas une bonne idée ;).

Pourquoi ?

Parce que ce modèle n’est pas très « SEO friendly ». Comment google peut il indexer un truc pareil ?

La réponse est connue, c’est la même que pour le Flash : il faut faire deux versions du site. Une « dynamique » et une sans javascript. C’est accepté par Google, car la version sans Javasript est bien accessible à ceux qui le souhaitent, et c’est en particulier le cas pour les mal et non voyants.

L’autre problème, c’est que, même si les technologies permettent « théoriquement » de mettre en oeuvre ce modèle, les outils, les frameworks ne proposent pas encore les bons outils pour faire ça sans avoir à tout réinventer.

Donc, c’est un peu tôt pour se lancer à fond là dedans, mais cela donne, je pense, une bonne idée de « là ou l’on va ».

(article issu d’une discussion passionnante avec Pieroxy)