Mar 222010
 

Après un bon accueil du premier article orienté code, voilà un second article sur la Théorie du Développeur, cette fois ci orienté Principes Fondamentaux dont voici le sommaire :

  • 1. Priorité au Client
  • 2. Qualité du code
  • 3. Responsabilisation
  • 4. Intégration Continue
  • 5. Itérations
  • 6. Tests automatiques
  • 7. Refactoring
  • 8. Architecture informelle
  • 9. Communication
  • 10. Éviter le gaspillage

Les plus avertis auront remarqué que j’ai repris les différents points énoncés par cet article de l’excellent blog making good software et que j’ai librement interprétés.

Même si parfois, on retrouve des sujets communs avec le premier article, ils sont exprimés d’une autre façon ici.

A vous de juger!

1. Priorité au Client

Si tu ne prend pas soin de ton client… quelqu’un d’autre le fera

Ce point, Priorité au Client, signifie de mettre l’accent, en collaboration avec le client, sur la valeur ajoutée réelle du produit à developper.

Le but initial de tout projet informatique est de créer un produit qui permet de répondre aux besoins définis par le client. Cependant pendant trop longtemps, d’autres aspects comme les contrats, les technologies, les hiérarchies, etc… ont pris une importance considérable. Il est donc nécessaire de recentrer la problématique sur la valeur ajoutée, que seul le client est en capacité de nous transmettre. Une totale transparence de part et d’autre est de ce fait nécessaire pour générer un climat propice à une telle collaboration.

2. Qualité du code

Même si la qualité du code est quelque chose de très subjectif, elle ammenne à réfléchir à de nombreux aspects importants comme :

  • La difficulté de maintenir l’application
  • La difficulté d’intégrer un nouvel arrivant

Pour tenter de résoudre ces deux eccueils, les principaux indicateurs de la qualité du code à mettre en place sont:

  • la simplicité
  • la lisibilité
  • la robustesse
  • la testabilité

Il existe bien évidemment une quantité astronomique d’autres indicateurs de qualité (comme par exemple la performance ou l’extensibilité), cependant, si ils ne sont pas requis, ils ne provoqueront que de la “sur-ingénieurie”.

3. Responsabilisation

Les personnes sont la ressource la plus précieuse dans le développement logiciel, et non les technologies. Ce sont eux qui font la différence entre un produit médiocre et un excellent produit, mais elles doivent être responsabilisées.

La responsabilisation est le processus où les gens sont encouragés à être proactifs et à prendre des décisions. Certains des mécanismes les plus efficaces pour la responsabilisation sont :

  • le coaching
  • le travail en binôme
  • la délégation

Il y’a un excellent article de Tony Morgan (dont est extrait le tableau suivant) expliquant la différence entre une approche classique de délégation et de responsabilisation.

Délégation Responsabilisation
Voici ce que j’attend de vous Qu’attendez vous de moi?
Voila comment vous devez faire Voila votre rôle
Voila à quoi je veux que cela ressemble C’est là que nous allons
Voila ce que vous devez faire ensuite Voilà comment cela s’inscrit dans la vue générale
Je vais vous donner les derniers 5% Je vais vous permettre de contribuer sur les derniers 5%
Cela m’appartient Cela vous appartient
Voila comment je vois les choses Comment voyez vous les choses?
Précis Souple
Alignez-vous sur l’entreprise Prendre du recul est encouragé
Tâches Résultats
Pas de place pour d’autres dirigeants De la place pour d’autres dirigeants
Guidée par la préférence Guidée par des valeurs
Voici mon opinion Quel est votre opinion?

 

4. Intégration Continue

L’intégration est, de mon expérience, un enjeu majeur dans le développement logiciel. Attendre d’intégrer, à la fin du projet ou après qu’une grosse partie de la fonctionnalité soit complétée, est toujours un processus traumatisant.

L’intégration continue est le processus qui garantit que chaque partie du code commité est automatiquement intégré dans le système. Rappelez-vous que l’intégration continue va au-delà de compilation en continu.
Cet article de Martin Fowler, est l’une des meilleures références en ligne sur l’intégration continue.

5. Itérations

Les itérations ont l’avantage de fournir un feedback régulier et continu. C’est important car cela réduit le taux d’incertitude lors du développement d’un produit.

Bien que les itérations soient généralement liées aux méthodologies agiles, il est important de se rappeler qu’il existe d’autres méthodes comme le RUP qui utilisent également des itérations et qui pourtant ne font pas partie de la famille agile.

6. Tests automatiques

Permettre le refactoring et les itérations, apporte de la confiance. De plus si tout est bien mise en œuvre, cela permet d’améliorer l’exactitude du produit final. Pour automatiser les tests vous devez considérer certains aspects des tests :

  • Il est impossible de déceler tous les bugs d’une application
  • Les bugs les plus importants sont dans la couche de base et dans la couche d’intégration
  • L’utilisation de tests automatisés d’Interface Utilisateur rend plus difficile la détection de bugs
  • Il faut absolument prioriser ce qui va être testé

et quelques conseils sur la façon d’écrire une bonne suite de tests :

  • les tests sont aussi important que le code lui même
  • tester dès le début et aussi souvent que possible
  • tester à des niveaux différents (tests unitaires, tests d’acceptation, tests d’intégration)
  • utiliser des outils d’automatisation

7. Refactoring

Peu importe le soin que vous apportez pendant le codage, à votre première tentative, vous allez avoir tort. Le Refactoring est la pratique par laquelle nous ne cessons de changer le code pour répondre à l’évolution nécessaire d’un système.

8. Architecture informelle

La technique du Big design upfront (BDUF) est, sauf si vous êtes de la NASA et que vous pouvez consacrer 50-60 % de votre temps sur un projet, un gâchis total; Mais ça l’est aussi de coder sans aucune préparation. L’architecture informelle est une solution de compromis où l’architecture est examinée dans le cadre des préoccupations en cours et est décrite dans des documents légers, des paperboard ou des tableaux blancs.

9. Communication

Le développement de logiciel n’est QUE de la communication. Le client explique à l’équipe de développement ce qu’il veut voir accomplir puis l’équipe de développement tente de traduire le besoin à travers un code compréhensible par l’ordinateur.

Cette désormais célèbre image évoque bien les difficultés de compréhension entre les différents intervenants d’un projet, qu’il soit informatique ou non :

10. Éviter le gaspillage

Les postes de gaspillages sont les plus importants tueurs de productivité dans le développement logiciel, les plus courantes et dangereuses étant :

  • les réunions inutiles
  • des exigences inutiles
  • des processus inutiles
  • de la documentation inutile
Imprimer cet article Imprimer cet article

  3 Responses to “Le code d’honneur du développeur”

  1. J’ai en effet repris les points de ce post. Par contre j’ai fait une libre adaptation des explications en fonction de mon expérience.

    Je m’en vait de ce pas ajouter cette explication dans le corps du billet, c’est effectivement plus juste de citer cette belle source d’inspiration qu’est le site Making Good Software. Je m’excuse d’avoir oublier.

  2. Une remarque qui rejoint le premier point (priorité au client) et qui finalement, est oubliée par le client lui-même…priorité à l’utilisateur! Mais pour ça il faut savoir faire des sacrifices et des efforts (oublier IE6 par exemple…)

Leave a Reply