mageekblog Le blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.

Aller au contenu | Aller au menu | Aller à la recherche

cv | twitter | linkedin subversion atoum

Codez pour être heureux !

La vieillesse est un sujet qui me préoccupe de plus en plus.

Normal, me direz-vous, puisqu’à bientôt 40 ans, je suis plus proche de la fin de ma vie que de son début, statistiquement parlant.

Sauf que même si j’ai de plus en plus régulièrement envie d’avoir à nouveau 20 ans après une activité physique un peu soutenue, ce n’est pas ma vieillesse physique qui me préoccupe réellement, mais ma vieillesse professionnelle.

En effet, cela fait maintenant 13 ans que je travaille, et bizarrement, je pense que l’expérience que j’ai acquise durant cette période est un handicap dans le cadre de mon avenir professionnel pour plusieurs raisons.

Lire la suite...

La programmation n'est pas industrialisable

Je poursuis ici ma réflexion entamée dans mon précédent billet concernant la difficulté de certaines personnes à comprendre qu’il est impossible de quantifier finement et surtout de manière fiable le temps nécessaire à la réalisation d’un logiciel.

Plus j’y pense, plus je me dis que le problème vient du fait que la personne qui demande un tel chiffrage à un développeur pense que la création d’un logiciel est le résultat d’une industrialisation.

Dans notre contexte, la définition la plus adéquate de l’industrialisation est la suivante, d’après Wikipedia :

L’industrialisation désigne le processus de transfert du processus de création de l’offre au processus de réalisation de l’offre.

En résumé, lors de la phase d’industrialisation d’un produit, l’ensemble de la phase de conception de ce produit a été réalisé et il est donc possible de définir précisément les étapes devant être successivement suivies pour l’obtenir à l’extrémité de la chaîne de production.

De plus, puisqu’au moins un exemplaire du produit existe dans le monde réel à l’issue du processus de création, il est possible de quantifier très précisément les ressources temporelles et matérielles qui seront nécessaires pour sa fabrication à grande échelle.

Enfin, pour la même raison, ses spécifications sont clairement définies et il est donc possible de s’y référer afin d’effectuer tout au long de la chaîne de fabrication des contrôles précis pour vérifier la qualité du produit final.

Lire la suite...

Programmer, c'est jouer au Lego… ou pas !

Depuis l’avènement de la programmation orientée objet, le développement d’un logiciel suivant ce paradigme de programmation peut être assimilé à la construction d’un modèle de Lego.

En effet, tout comme le joueur de Lego manipule et assemble des briques en plastiques pour réaliser sa construction, le développeur manipule et assemble des briques logicielles pour réaliser son programme.

Mais il y a cependant quelques différences importantes entre les deux.

Lire la suite...

TDD versus BDD

De plus en plus souvent, j’entends dire que le BDD est mieux que le TDD.

Et à chaque fois je ne peux m’empêcher de sourire doucement, car un développeur qui fait du BDD fait en réalité du TDD , d’après « l’inventeur » du BDD.

Le concept de BDD est en effet apparu pour la première fois en mars 2006 dans un article de Better Software, un magazine ayant pour thème principal la qualité logicielle.

Dan North, l’auteur de l’article en question, y explique en substance que pour faire face à l’incompréhension et aux difficultés que la mise en œuvre du TDD suscitait chez les développeurs, il a eu l’idée d’en changer le vocabulaire afin de le rendre plus « accessible ».

Lire la suite...

À propos de la politique de développement de atoum

Timothée Barray a écrit récemment un article à propos d’atoum dans lequel il souligne l’extrême réactivité des contributeurs lorsqu’un bug doit être corrigé.

Cette rapidité de réaction ne doit rien au hasard puisqu’elle est entre autres induite par la politique de développement mise en place depuis quasiment le début du projet.

En effet, le développement d’atoum a été piloté par des tests écrits avec atoum lui-même dès que cela a été possible.

Les contributeurs disposent donc au moment ou j’écris ces lignes d’une collection de tests unitaires qui représente un total de 20250 assertions réparties dans 1393 méthodes et 176 classes.

Grâce à cela, le code d’atoum est couvert à plus de 80 % par les tests.

Lire la suite...

- page 1 de 83