Ce site utilise Google Analytics. En continuant à naviguer, vous nous autorisez à déposer un cookie à des fins de mesure
d'audience.
En savoir plus ou s'opposer.
Les cookies Google Analytics
Ce site utilise des cookies de Google Analytics, ces cookies nous aident à identifier le contenu qui vous interesse le
plus ainsi qu'à repérer certains dysfonctionnements. Vos données de navigations sur ce site sont envoyées à Google Inc.
Nous avons bien pris en compte votre souhait de ne pas envoyer vos données de navigation à Google Inc.
NB: ce message va s'effacer tout seul au bout de 5 secondes.
Ouh les gros mots "outils" et "processus", surtout depuis que l'agilité est devenue populaire dans notre industrie. Parler de cela n'est pas simple. C'est un sujet sensible, voire polémique, et à mon sens, surtout en raison de certaines pratiques managériales "déviantes" associées (amalgamées?) aux outils et aux processus.
Je propose dans cet article de mettre au clair mon ressenti sur tout cela. Merci de ne pas prendre tout cela de manière péremptoire ou catégorique de ma part. Le style est volontairement un peu provocateur pour susciter une réaction (positive). On verra pourquoi je parle de "schizophrénie".
Dans les deux premiers billets, nous avons vu comment écrire des tests de caractérisation et isoler les dépendances. Dans ce billet, nous allons voir quelques techniques de refactoring.
Dans le premier billet, nous avons vu comment écrire des tests de caractérisation. Dans ce billet, nous allons voir comment isoler les dépendances identifiées via les tests de caractérisation.
Après avoir suivi une journée d'atelier avec Mickael Feathers, l'auteur de Working effectively with legacy code, il fallait que je fasse un billet sur ce sujet (en français car il y a déjà beaucoup de contenu en anglais). J'en aurais même plusieurs :), voici la première partie se concentrant sur la première étape : écrire des tests de caractérisation. Nous verrons dans la suite de cette série l'isolation des dépendances, puis quelques techniques de refactoring typiques.
J'avais déjà lu le livre en 2008, j'ai souvent fait des codings dojo sur du code legacy, mais cet atelier était l'occasion de s'exercer une nouvelle fois et de voir comment Mickael Feathers animait son atelier. Voici donc un retour sur les points principaux.
J'ai mis relativement longtemps à passer à Git, j'ai démarré "seulement" début 2013. Auparavant, j'ai travaillé successivement avec Subversion et TFS Version Control. Et dernièrement, j'ai retrouvé TFS VC sur une mission. J'ai aussi croisé ClearCase. C'est l'occasion de faire un retour d'expérience et d'avancer des arguments pour ceux qui ne seraient toujours pas passés à Git (ou un autre DVCS - Distributed Version Control System - ayant le même principe de fonctionnement).
J'ai eu 2 blogs, le premier en anglais sur Blogspot et ensuite quand j'ai créé ma société DevCrafting, j'ai créé un autre site avec un blog en français avec Office365 (SharePoint).
Je n'ai jamais réussi à écrire de nouveaux billets, pour plusieurs raisons, plus ou moins bonnes, mais je voudrais à nouveau essayer avec une autre approche. Je voulais écrire ce billet pour donner un retour d'expérience sur mes 2 premières tentatives.
A noter que je voulais également pouvoir écrire parfois en anglais, parfois en français en fonction du sujet.
Enfin, j'aime l'idée de FsBlog, mais comme tout ce que je voulais faire n'était pas supporté, j'ai décidé de jouer avec F# pour recréer mon site web et un blog à l'image de ce qu'a fait Tomas Petricek.
J'avais prévu cette été une période assez large de "congés"...l'objectif était de pouvoir profiter de mes enfants, mais également d'en profiter pour avancer quelques sujets, dont me frotter de plus près à certaines technos...
Premier objectif que je m'étais fixé, aller plus loin dans le dev JavaScript. J'ai eu l'occasion de manipuler certains outils via les communautés, sur certains projets, mais je voulais tenter de les mettre en place pour m'y confronter un peu plus. Au menu initialement, j'avais prévu: AngularJS, Gulp, RequireJS, LESS, TypeScript...finalement, je ne me suis pas lancé complètement dans TypeScript, mais je me suis frotté en plus aux problématiques de SEO avec les SPA (Single Page Application), aux déploiements d'application Node.js sur Heroku, un peu de Ruby...bref, ça a été riche en apprentissages ! Ce billet reprend quelques éléments retenus de ces expérimentations.
Voici le premier billet de ce blog, dans lequel je vais rapidement résumer la création de DevCrafting. Je vous invite à lire la page Qui de ce site pour en savoir un peu plus sur l'origine de la création de DevCrafting et mon experience personnelle.
DevCrafting a été officiellement créé en novembre 2013, mais la réflexion et la préparation ont démarré bien avant : se renseigner sur les démarches (banque, comptabilité, forme juridique...), se rapprocher de pairs, préparer un budget...