Catégorie : Génie logiciel

Quand l’oubli des fondamentaux du code finit par coûter cher

J’utilise MongoDB comme base de données principale et j’en suis globalement satisfait. Mais j’ai l’impression que depuis un certain temps la tendance consiste à le dénigrer. Souhaitant comprendre ce qu’on lui reproche réellement, je suis à l’affût de retours d’expériences. C’est ainsi que j’ai récemment lu cet article publié le 21 novembre 2017 : Why We Moved From NoSQL MongoDB to PostgreSQL.

Je n’ai malheureusement pas appris grand chose sur MongoDB en le lisant, mais je trouve que cet article est un cas d’école qui nous montre ce qu’il se passe quand on s’assoie sur les bonnes pratiques de développement. Je vous propose donc dans cet article d’étudier ça plus en profondeur. Continuer la lecture de Quand l’oubli des fondamentaux du code finit par coûter cher

AssertJ pour des assertions plus expressives

Écrire des tests, c’est bien, écrire des bons tests c’est encore mieux. La technique given when then est une des bonnes pratiques pour écrire des tests (unitaires ou pas d’ailleurs). Les 3 concepts sont en effet nécessaires, y-compris le dernier qui correspond aux assertions. En effet, un test n’apporte vraiment de la valeur que si il procède à des vérifications sur le résultat de son exécution. Ça parait évident mais je suis tombé à plusieurs reprises sur des tests qui exécutaient du code sans rien vérifier…

En Java, les outils de base les plus populaires pour écrire des tests (JUnit et TestNG) sont assez pauvres pour écrire les assertions. Heureusement, il existe des outils permettant de gagner à la fois en puissance et en expressivité pour exprimer les assertions. Continuer la lecture de AssertJ pour des assertions plus expressives

Mock ou pas mock ?

C’est quoi un mock ?

Avant de rentrer dans le vif du sujet, il me semble important de faire une mise au point sur les concepts dont je vais parler dans cet article.

Dans le jargon du développeur, le mot mock a tendance à être utilisé à toutes les sauces. Martin Fowler, dans l’article Mocks Aren’t Stubs, parle de différents concepts :

  • Test double : objet factice qui prétend être l’objet attendu mais dont le comportement est adapté spécifiquement aux besoins du test. Le mot double fait allusion à la doublure au cinéma. Le mot mock est souvent utilisé dans ce sens-là.
  • Dummy : objet demandé par l’API qu’on teste mais qui n’est pas utilisé lors de l’exécution du code.
  • Fake : objet qui remplit le contrat (interface) mais dont l’implémentation peut faire abstraction de certaines contraintes, ce qui fait qu’il n’est pas adapté à la production (les bases de données en mémoire en sont un bon exemple).
  • Stub : objet au comportement éventuellement configurable qui peut ne répondre que très partiellement au contrat qu’il est censé remplir. Souvent écrit spécifiquement pour un ou ensemble de tests, il peut parfois enregistrer les interactions qu’on a avec lui dans l’objectif de les vérifier par la suite.
  • Mock : objet magique au comportement pré-câblé très spécifique. Dans la plupart des langages il est nécessaire d’utiliser un outil pour générer ce genre d’objets, cet outil permettant souvent de configurer au moment de l’exécution le comportement de l’objet sous la forme : «quand on te demande ça tu fais ça».

Continuer la lecture de Mock ou pas mock ?

Puis-je avoir confiance en mes tests ?

Il existe un certain nombre d’outils permettant de fournir des métriques qui visent à mesurer la qualité d’un logiciel, notamment à travers l’analyse statique dont j’avais eu déjà l’occasion de parler. Ces métriques sont plus ou moins représentatives de la qualité du code. Mais nous permettent-elles de savoir si nous pouvons avoir confiance en notre code ?

Jusqu’à nouvel ordre, pour s’assurer que du code remplit correctement les besoins, nous n’avons pas vraiment d’autre solution que de le tester, et nous le faisons de manière aussi automatique que possible pour augmenter notre productivité. Mais nos tests sont-ils fiables ? Puis-je sortir une nouvelle version de mon produit en toute confiance ou dois-je croiser les doigts à chaque mise à jour ?

Il existe un certain nombre de façons permettant de savoir si nous pouvons avoir confiance en nos tests. Continuer la lecture de Puis-je avoir confiance en mes tests ?

Architecture multi-tenant, une fausse bonne idée ?

Les concepts de Software as a Service ou de Cloud Computing sont de plus en plus répandus dans l’informatique d’aujourd’hui. Cela a pour conséquence que les éditeurs de logiciel ne vendent plus directement un logiciel mais le service que rend leur logiciel. Cette nouvelle façon de déployer du logiciel a changé la donne dans la façon dont sont conçus ces mêmes logiciels.

Vers un déploiement simplifié

Les architectures multi-tenant (multi-entités ou multi-locataires en français) ont vocation à faire en sorte qu’un logiciel soit capable de gérer un certain nombre de clients en une seule installation. Au lieu d’installer le logiciel une fois pour chaque client, ce dernier est capable de créer des environnement virtuels distincts pour chaque client de sorte à ce que de l’extérieur les autres environnements ne soient pas du tout visibles. En fin de compte, le logiciel répond lui-même aux problématiques de déploiement.

Dans le contexte d’un prestataire de service qui souhaite vendre son service à différents clients, l’architecture multi-tenant semble être la réponse évidente. Il suffit de déployer le logiciel une fois et de créer autant d’environnements que nécessaire, et le tour est joué. L’administration d’un tel système est, du coup, relativement simple. Continuer la lecture de Architecture multi-tenant, une fausse bonne idée ?

Ceylon la route vers le langage idéal

L’informatique est une science jeune et en perpétuelle évolution. Même si ses fondamentaux n’ont pas changé depuis ses balbutiements, des concepts nouveaux, des langages, des technologies et bien d’autres concepts apparaissent et disparaissent au fil du temps.

Yet another language

Un des principaux axes dans lesquels l’informatique évolue au fil du temps est sans conteste les langages de programmation.

Des principes fondamentaux

Les principaux paradigmes de programmation existent depuis très longtemps (1957 pour le procédural avec Fortran, 1969 pour l’orienté objet avec Smalltalk, 1958 pour le fonctionnel avec Lisp d’après Wikipédia).

Les langages se distinguent également par la façon dont le code qu’ils produisent est exécuté. Certains sont des langages compilés directement en code machine, d’autres nécessitent un interpréteur. Là encore, les concepts principaux existent depuis longtemps. Par exemple, la première machine virtuelle avec compilation à la volée (Just In Time) a été créée en 1980 pour exécuter du Smalltalk.

Les langages sont aussi caractérisés par d’autres critères. On peut évoquer le typage qui peut être statique, dynamique ou inféré mais aussi plus ou moins fort. La syntaxe est également un critère qui compte énormément dans la mesure où elle représente sa partie visible.

L’ensemble de ces axes permet d’envisager des possibilités absolument infinies en terme de diversité. Les langages modernes sont nettement différents de leurs ancêtres même si ils reposent sur des principes identiques. Ils ne sont ni plus ni moins que des assemblages de ces différents concepts de base qui ont gagné en maturité depuis leur création. Ils sont généralement conçus en capitalisant sur leurs grands frères. Continuer la lecture de Ceylon la route vers le langage idéal

L’héritage, un concept usé et abusé

Un outil puissant

L’héritage est un concept du célèbre et populaire paradigme de programmation dénommé orienté objet. Ce concept est le moyen qui permet en orienté objet de supporter le polymorphisme, principe qui consiste simplement à faire en sorte d’avoir plusieurs comportements (implémentations) différents derrière un même objet (contrat).

Le polymorphisme est un outil redoutablement efficace en orienté objet. C’est d’ailleurs lorsqu’on travaille dans des langages qui ne disposent pas de ce concept qu’on se rend compte à quel point il est pratique.

Dans la suite de cet article, la notion d’héritage qui est utilisée est celle qui correspond à l’héritage d’état (donc au mot-clé extends sur des classes en Java). La notion d’héritage de comportement (implémentation d’une interface en Java) ne rentre donc pas dans le terme héritage. Certains langages ne distinguent pas ces deux notions mais dans les faits ces deux types d’héritage apparaissent aussi. Continuer la lecture de L’héritage, un concept usé et abusé

La dette technique, l’épée de Damoclès de l’éditeur logiciel

Le terme de dette technique est devenu monnaie courante dans le jargon de l’informatique. Et pour cause, c’est un enjeu important dans la vie de tout logiciel car c’est une menace omniprésente qui peut à tout moment mettre en péril un projet.

La notion de dette est une métaphore basée sur un parallèle avec la dette financière. Je trouve personnellement que ce parallèle avec le monde de la finance est particulièrement pertinent et cet article devrait permettre de le montrer. Continuer la lecture de La dette technique, l’épée de Damoclès de l’éditeur logiciel

L’optimisation prématurée, le péché mignon du développeur

J’ai pu constater que la plupart des développeurs ont en tête le fait que le code qu’ils écrivent doit s’exécuter vite. Je ne sais pas vraiment pourquoi, mais moi aussi, quelque part en moi, dans mon inconscient, j’ai également cette idée. Comme si on allait se faire radier du métier si on écrivait du code qui s’exécute lentement !

Pourtant, rares sont les cas où on nous pose réellement comme contrainte le fait que le logiciel doive fonctionner vite. Souvent, la première chose que les utilisateurs vont apprécier, c’est que le logiciel fonctionne. C’est seulement si le logiciel fonctionne que le temps d’exécution commencera à rentrer en compte.

Mais, rien à faire. Nous avons tous tendance à nous inventer des contraintes sur le temps d’exécution. Et lorsque nous commençons l’écriture du code, ces fausses contraintes peuvent vite devenir une obsession. Continuer la lecture de L’optimisation prématurée, le péché mignon du développeur

Tester c’est douter

Je suis développeur depuis quelques années maintenant et je commence à avoir un peu d’expérience.  Je suis donc un bon développeur, fort et intelligent. Quand j’écris du code, il n’y a pas vraiment de raison pour qu’il ne fonctionne pas. En fait, je suis maintenant persuadé de la chose suivante :

Tester c’est douter

Continuer la lecture de Tester c’est douter