Dans notre post précédent, nous avons repris la définition de Michael Feathers (depuis son livre « Working Effectively with Legacy Code ») selon lequel l’absence de tests unitaires est le facteur déterminant d’une application Legacy. Il propose le concept de test de caractérisation afin de comprendre le comportement de l’application, c’est-à-dire ce qu’elle fait réellement, et non pas de chercher à découvrir à travers le code ce qu’elle est censée faire.

Mais qu’en est-il lorsque notre application Legacy ne dispose pas déjà de tests unitaires ? La réponse à l’un de nos 3 scénarios – plan de transfert de l’application à une autre équipe – peut-elle passer par l’écriture de tests ? Est-il possible de faciliter ce transfert de connaissances avec des tests de ce type ? Continuer la lecture →

Nous avons cette application Legacy en C, la première version de Word publiée par Microsoft en 1990, pour laquelle nous nous proposons de chiffrer le coût de différentes stratégies : refactoring ou reengineering, par la même équipe de développeurs ou au contraire, par une autre équipe et donc avec un transfert de connaissances. Continuer la lecture →

Nous continuons cette série sur les différents Use Cases qui peuvent se présenter dans le cadre de la reprise d’une application Lecagy en C, à partir de l’analyse du code source de Word 1.1a, la première version de ce traitement de texte publié par Microsoft en 1990. Continuer la lecture →

Madrid DevOps est un groupe de professionnels dédié à … DevOps, comme on peut l’imaginer. Il existe un ‘Meetup Group’ où trouver les informations les plus récentes, principalement au sujet de nouvelles réunions, chaque mois.

Le 10 avril dernier, la présentation de Manuel Recena Soto et Antonio Manuel Muñiz de ClinkerHQ, s’intitulait ‘Continuous Integration’. Je leur ai posé quelques questions au sujet de cette présentation, que vous pouvez trouver ici https://speakerdeck.com/clinkerhq/integracion-continua (en espagnol). Continuer la lecture →

Suite de notre série sur l’analyse du code source de Word 1.1a, la première version de ce traitement de texte publié par Microsoft en 1990.

Dans le premier post, nous avons vu les métriques quantitatives de taille (LOCs), de complexité (CC), le niveau de commentaires et de duplication. Le second post était consacré aux différentes Issues’ de type Blocker, Critical, Major et Minor. Continuer la lecture →

Nous avons examiné  dans le post précédent, les premiers résultats de l’analyse du code source de Word 1.1a (1990).

Nous avons compté 349 fichiers, ce qui n’est pas énorme, mais avec une taille assez élevée : en moyenne plus de 470 LOC (Lines Of Code), et nombre d’entre eux bien au-delà des 1 000 LOC. Les métriques de complexité sont élevées également, et le taux de commentaires assez bas, mais c’était probablement normal à l’époque, il y a plus de 40 ans.

Le très faible niveau de duplication amène à penser que tous les composants nécessaires à l’implémentation d’une même fonctionnalité se retrouvent dans un même fichier, ce qui explique donc la taille et la complexité de nombre d’entre eux. Il semble que le mot d’ordre ait été : priorité à l’efficacité, au second plan la lisibilité et la compréhension du code.     Continuer la lecture →

Microsoft a publié cette semaine le code source de Word 1.1a (1990) via le Computer History Museum : http://www.computerhistory.org/atchm/microsoft-word-for-windows-1-1a-source-code/.

Il s’agit d’une des premières versions de Word for Windows, de Janvier 1991 :
http://blogs.technet.com/b/microsoft_blog/archive/2014/03/25/microsoft-makes-source-code-for-ms-dos-and-word-for-windows-available-to-public.aspx.

Je me suis amusé à analyser le code source de cette version. J’étais curieux de voir quels seraient les résultats tant d’un point de vue quantitatif – nombre de lignes de code, niveau de complexité, etc – que qualitatif : violations aux bonnes pratiques de programmation, défauts de type Blockers, Criticals, etc. Continuer la lecture →