Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Appliquer les principes du « 5 S » dans votre code – Ranger

Publié par David Beaumier, Jean-Francois Gilbert le jeudi 9 avril 2015 à 07:45

Dans ce second article de la série sur l’application de la méthode 5S en développement logiciel nous abordons le second concept : ranger (ou Seiton, en japonais). On peut résumer le concept de cette façon : « Une place pour chaque chose, et chaque chose à sa place » (source : Wikipedia).

Le but derrière cette notion de rangement est de s’assurer que les équipiers ne perdent pas de temps de travail à chercher les éléments dont ils ont besoin dans le cadre de leur travail. Dans le cas du développement logiciel il peut s’agir autant des classes communes, d’utilitaires pour effectuer certaines opérations que de documentation sur les patrons de conception. Quoi de plus frustrant que de chercher pendant plusieurs minutes où a été déposé l’utilitaire qui permet de convertir une base de données!

Vous trouverez ci-dessous quelques suggestions pour optimiser le rangement dans votre équipe de développement logiciel.

Bien structurer votre projet

Le découpage (dossiers) de votre projet devrait s’appuyer sur le vocabulaire du domaine d’affaires. Il est important d’avoir une uniformité dans le langage utilisé et cela doit se refléter dans le code aussi. Si on parle de « gestion des accès » dans votre application on ne devrait pas retrouver un dossier « autorisations » dans le projet.

Dans un projet Web, il peut être aussi intéressant de penser à une structure qui permette de rapidement distinguer les artéfacts selon qu’ils s’appliquent à la structure du document (html), aux styles (CSS) ou au code (JS).

Assurer une cohérence physique des dossiers et des paquetage

Des outils comme Resharper vous indiqueront s’il existe des écarts entre les dossiers physiques et le nom des paquetages (namespaces dans ce cas-ci). Avec le temps, on peut avoir renommé quelques dossiers, mais avoir oublié de faire les ajustements dans le code.

5S Ranger Resharpernamespacelocation

Valider la dépendance entre les paquetages

 La dépendance entre les paquetages devrait,  elle aussi, respecter le découpage fonctionnel. Ces dépendances sont souvent exprimées en UML sous forme de diagramme de paquetages.

Les fonctionnalités de Dependency Graph et de CodeMap de Visual Studio permettent de dresser une cartographie des dépendances qui vous permettra de valider que celles-ci sont conformes à la cible.

5S Ranger Dependencygraph

5S Ranger Vscodemap

Des outils comme JArchitect peuvent produire diverses métriques sur le niveau de dépendance entre les différentes parties du code. Celles-ci vous permettront de vérifier si les principes architecturaux ont été respectés et vous éviteront d’avoir un couplage trop fort entre les entités de votre système, ce qui a tendance à rendre l'entretien et la réingénierie plus difficile à long terme.

5S Ranger Dependencymatrix

N’oubliez pas la documentation

On ne parle pas ici de la documentation du code source en lui-même (bien qu’elle soit importante), mais plutôt de celle qui forme la base de connaissances de votre équipe. Comment un nouvel équipier saura quel outil utiliser pour produire un script de mise à jour de la base de données relationnelle? Où trouvera-t-il les règles de nomenclatures à respecter?

Que vous utilisiez un wiki ou un autre outil de gestion documentaire, assurez-vous d’y consigner les informations importantes. Souvent, un bref résumé et quelques liens pertinents permettent de conserver une documentation suffisante sur un sujet. Comme le disait Albert Einstein, « Ne mémorisez pas une information que l’on peut facilement retrouver ».

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

Appliquer les principes du « 5 S » dans votre code: Ordonner

Publié par David Beaumier, Jean-Francois Gilbert le jeudi 19 février 2015 à 13:32

Un de mes derniers billet présentait comment la méthode 5 S  peut s’appliquer au développement logiciel autant que dans un environnement de travail "physique".  Aujourd’hui, mon collègue Jean-François Gilbert et moi avons pensé donner suite à ce billet en vous proposant quelques outils et références fort utiles pour celui ou celle qui souhaite rendre sa base de code 5 S.

Notre objectif n’est pas ici de dresser une liste exhaustive des outils disponibles, mais bien de démonter comment chacun des concepts 5 S peuvent être mis en œuvre en tirant profit des facilités à notre disposition. Aujourd'hui, nous débutons la série avec le premier concept : ordonner (ou Seiri, en japonais). Cette première opération nous demande de supprimer l’inutile.

Retirer le code mort

Heureusement, plusieurs outils permettent maintenant d’identifier en temps réel si un bout de code est utilisé ou non. Il devient ainsi facile de prendre l’habitude de valider si une partie du code qu’on touche pourrait être éliminée.

Voici un exemple où Resharper est configuré de façon à fournir un indicateur visuel qui permet de voir en un clin d’œil les parties inutiles du code source. On peut d'ailleurs établir un parallèle entre ce type d'indicateurs et le management visuel, fortement utilisé en Lean management.

Resharper Indicateurvisuel Codemort

Identifier le code dupliqué

À bien des égards, le code dupliqué est pire que le code mort. Surtout si l'ensemble de ces rejetons n'évolue pas au même rythme. On risque de se retrouver avec des variantes du code de base qui peuvent être difficiles à réconcilier à terme. Et que dire du risque de bogues si on oublie de modifier une de ces copies!

Plusieurs IDE, tel que RubyMine, offrent des fonctionnalités pour identifier les parties de code qui se retrouvent dupliquées.

Rubymine Analyserduplication

Les utilisateurs de Visual Studio ne sont pas en reste avec la fonctionnalité Code Clone Detection.

VS Code Clone Detection

Voilà quelques exemple d'outils qui devraient vous permettre de mette en application la règle des scouts : « laisser le campement plus propre en partant qu’à l’arrivée ».

Et vous, avez-vous des outils préférés pour garder votre code ordonné? N'hésitez pas à partager vos coups de coeur en nous laissant un commentaire ci-dessous.

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

Le professionnalisme en développement logiciel illustré!

Publié par Anis Berejeb le jeudi 29 janvier 2015 à 16:50

Bonjour! c'est mon premier billet sur developpementagile.com et j'en suis honoré!

J'ai quelque chose à vous raconter! Mettons que vous allez voir un menuisier pour qu'il vous construise une armoire, et que vous lui demandiez ceci :

Profdevlogiciel BD1

Que croyez-vous que le menuisier va penser de vous? ..

Profdevlogiciel BD2

Ok.. et si nous inversions la question, que penseriez vous si le menuisier AVAIT accepté de vous livrer cette armoire?

Profdevlogiciel BD3

Quand vous allez voir n'importe quel professionnel, vous supposez qu'il agira en tant que tel. d'ailleurs généralement, son attitude  professionnelle est principalement la raison pour laquelle vous l'auriez choisi.

Le métier de développeur est une profession. il ne doit y avoir aucune différence en terme d'attitude professionnelle entre un professionnel du logiciel et un professionnel de la santé par exemple.

En tant que professionnels du développement logiciel, nous sommes supposés avoir la meme attitude, agir de la même façon et livrer du travail de qualité digne de notre métier.

En s'inspirant fortement du courant de l'artisanat logiciel ou "software craftsmanship" fondé par Bob. C. Martin, je vous présente la bande dessinée "les 9 principes du développeur agile professionnel".

Profdevlogiciel Recap

Téléchargez la bande dessinée gratuitement sur www.berejeb.com

Souligner les succès…

Publié par Vincent Crépin le lundi 3 février 2014 à 20:11

J’ai récemment été appelé à effectuer une intervention à La Capitale et c’était la première fois que l’occasion se présentait à moi. J’avais eu de bons mots de plusieurs personnes ayant effectué des interventions auparavant mais rien de précis. Bien évidemment j’ai été impressionné par leur nouvel édifice vert qui vaut le détour à lui seul. Mais ce n’est pas le sujet de mon article…

Lors de rencontres avec les architectes d’affaires et organiques, j’ai pu prendre connaissance du niveau d’implantation des techniques agiles dans le département du développement et je dois dire que j’ai été impressionné. Je n’avais jamais vraiment entendu parler de cet aspect de La Capitale mais parmi les endroits que j’ai visités, ils sont au sommet de la liste selon ce que j’ai vu.

Salle de développement à La CapitaleJe parle surtout ici des pratiques de développement (TDD, refactoring, intégration continue). Ils utilisent TDD pour tous leurs développement qui utilisent la plateforme Ruby on Rails. Ils possèdent actuellement une base de tests qui se comptent en plusieurs milliers et dont la couverture frôle le 100%. Ils ont une salle de développement dans laquelle la première chose que l’on remarque, c’est la présence intimidante d’un écran géant qui donne en temps réel l’état des builds (il y avait une tuile rouge quand je suis passé ;-)). Voici d’ailleurs une photo de cela.

On sent dans cette salle la très grande complicité entre les développeurs et tous ces facteurs se matérialisent par des mises en production exemptes de défauts.

Il va sans dire que cet accomplissement est un travail acharné d’équipe, comme on le devine tous. Je félicite ces personnes qui se sont battues pour leurs idées et qui ont accompli quelque chose de bien et qui peut servir de modèle pour notre communauté.

Présentation: Esclave de votre dette technique?

Publié par Félix-Antoine Bourbonnais, Pascal Roy le vendredi 15 novembre 2013 à 12:00

 

Description

Votre code est un trou noir? Chaque fonctionnalité est de plus en plus difficile à développer? Vous ne voulez plus toucher à un module sous peine de voir toute votre énergie aspirée?

Cette présentation vous permettra de prendre conscience de l’impact de la dette technique sur votre quotidien et sur votre capacité à livrer du logiciel fonctionnel et de qualité à chaque itération.

Comment soutenir le même niveau de productivité? Comment garder son codesimple et facile à changer?

La présentation sera en trois volets : identifier ce qu’est la dette et ses impacts, quelles sont les techniques et pratiques pour éviter la « patrimonialite aigüe» (infection d’un système vieillissant) et finalement, comment gérer la dette déjà accumulée, y compris quelques trucs pour votre PO.

Non, la déprime n’est pas le destin de tous les projets vieillissants…

  • Niveau : Tous
  • Public cible : Équipes de développement et gestionnaires

Présentation

Archive