Maintenir du code sur le long terme ..

Salut QuanticPotato,

Les questions que tu te poses sont des questions que peuvent souvent se poser les développeurs. Retomber sur du vieux code et se dire "Je ne comprends absolument plus rien à ce que j'ai fais" ou alors "Bordel, j'étais bourré quand j'ai codé ce truc ou quoi ?!", ça peut malheureusement arriver.

Pour éviter de devoir se replonger dans du code et perdre de la productivité, il y a plusieurs solutions et même si il y aura des points communs dans les réponses des développeurs que tu interrogeras, il y aura très certainement des différences dans les réponses mais voici la mienne :

Je pensais ajouter des tests unitaires, pour éviter de tout casser. Est-ce une bonne-idée pour cette problématique ? Si oui, faut-il en faire beaucoup ?

D'abord, pour les questions que tu te poses, oui les tests sont utiles. Non, ils n'ont pas vocation à t'aider à devenir plus productif, juste à t'éviter d'avoir des régressions. Tu auras l'impression de perdre du temps pendant l'écriture du test mais tu le gagneras quand il passera au rouge et que tu te rendras compte que tu as cassé quelque chose en codant une autre. Sans compter que développer des tests donne une impression de stabilité à ton projet et à juste titre. Par contre, gaffe à se dire beaucoup de tests = meilleur stabilité. Ce n'est pas la quantité des tests qui doit jouer mais la qualité.

Après, il existe l'approche TDD, du développement dirigé par les tests. En résumé, avant de développer ta fonctionnalité, tu vas d'abord développer le test. Certains vont même très loin en développement le test le plus convenable possible mais en développent la fonctionnalité la plus simple possible pour faire passer le test au vert. Par exemple, si nous avons le test suivant (en Java, excuse moi si tu n'es pas un développeur dans ce langage) :

1
2
3
4
5
6

@Test
public void testGiveGoodChange() {
  final Store store = new Store();
  double money = store.buy("newspaper", 10.0d); // where first param is the product and second money given at the store.
  assertEquals(8.9d, money);
}

Une implémentation tout à fait correct de ce test serait de renvoyer uniquement 8.9 à tous les appels de la méthode buy :

1
2
3

public double buy(String product, double money) {
  return 8.9d;
}

Il faut alors des tests supplémentaires pour faire varier les produits et la monnaie donnée pour arriver à la fonctionnalité finale. Adopter ce type de développement ne convient pas à tout le monde mais elle a de nombreux avantages : sauf si les spécifications évoluent, tu ne retoucheras plus jamais à du code que tu as écris parce que tu seras sûr à 100% qu'il est correct ; il suffit de regarder les tests pour savoir où tu en es dans le développement et reprendre là où tu en étais ; C'est particulièrement adapté pour le travail en équipe et encore plus pour le pair programming ! Par contre, cette philosophie a aussi des désavantages comme les nombreux changements dans les tests à faire si tu as des changements de spécification ou la difficulté de réduire tes tâches à faire dans des tâches atomiques pour pas devoir développer des tests énormes sous peine de rendre le TDD impraticable.

Bien sur j'essaye de commenter au maximum mon code, mais ça reste très "local" … (Ce qui me préocuppe le plus, c'est la structure "fonctionnelle" de l'ensemble du code).

Il y a des gens qui adorent mettre des commentaires partout. Je n'ai rien contre mais il faut qu'ils soient vraiment utile. Ma philosophie c'est "Le meilleur commentaire, c'est celui que tu n'as pas écris". Il faut absolument que ton code se suffit à lui même. Si nous reprenons le code précédent. Tu comprends directement que tu as un magasin avec la classe Store et que tu peux y acheter des produits avec la méthode buy. C'est inutile de commenter cette méthode, elle est plus que explicite.

Par contre, je fais exception à un cas c'est dans mes interfaces. Mes interfaces étant mes contrats dans toute l'architecture de mon projet et nécessaire dans le développement d'un projet avec plusieurs contributeurs, je me force à bien les documenter. Pour ce qui est de leurs implémentations, il y a extrêmement peu de commentaire. Les rares commentaires que je place, ce sont des liens vers des issues parce que j'ai dû utiliser un hack à cause d'une dépendance foireuse dans mon projet (si les contributeurs du compilateur d'Eclipse JDT me lisent …).

Et pour finir sur ce point en le rattachant à ta question initiale, non les commentaires n'ont pas vocations à te faire gagner en productivité. Simplement à te rappeler ce que faisait un bout de code. Mais fait attention à l'usage des commentaires, des commentaires entre chaque ligne de code ou des commentaires obsolètes pour une raison X ou Y te ferra perdre plus de temps qu'il ne t'en fera gagner !

Avez-vous des astuces/conseils/outils qui permettent de garder une cohérence dans le code sur le long terme, sans devoir se replonger dans tout le code à chaque fois ?

Ouais, la question principale !

Ce que j'ai essayé de faire passer comme message dans mes réponses à tes autres questions, c'est la difficulté de répondre à cette question. Il existe beaucoup de méthodologie pour développer ses projets comme l'approche TDD, Pomodoro dans le quotidien du développement, SCRUM pour la gestion complète du projet et vraiment beaucoup d'autres. Ils ont tous des avantages et des inconvénients et il faut souvent faire avec.

Si je peux simplement répondre à ta question sans parler des différentes méthodologies, ça se résume en quelques points :

• Construit un backlog précis. Un backlog est la liste des fonctionnalités que tu dois développer pour ton projet. Grâce à ça, tu sais exactement ce qu'il te reste à faire dans le développement de ton projet.
• Tente de terminer les tâches que tu as commencé. Les tâches dans ton backlog doivent être assez petites pour que tu puisses en faire une dans un laps de temps de quelques heures (2-3 maximum). C'est d'autant plus vrai si tu développes ton projet sur ton temps libre. Ca t'évitera de devoir t'arrêter dans le développement d'une tâche en plein milieu de de devoir la continuer une semaine plus tard. Tu seras perdu et tu vas perdre énormément de temps.
• Utilise un outil comme Trello pour le travail coopératif. Si vous êtes plusieurs sur le projet, vous devez savoir ce que fait les autres contributeurs pour éviter de vous marchez sur les pieds et pour gérer votre projet.

Voilà, j'espère que ma réponse t'aura aidé !

y a-t-il un équivalent aux tests unitaires pour des "tests globaux" ?

Tu as plusieurs niveaux de test :

• Les tests unitaires : Ces tests ont généralement un scope plus petit qu'une fonctionnalité entière. Par exemple, si nous avons la fonctionnalité "Créer un compte", on ne va pas avoir un seul test unitaire pour tester la création d'un compte. On va en avoir beaucoup plus (surtout avec l'approche TDD qui utilise exclusivement les tests unitaires). Par exemple, le test unitaire va tester si le champ email est bien rempli ; un second test si l'e-mail est conforme à l'expression régulière d'un e-mail ; etc.
• Les tests d'intégration : Nous montons d'un niveau. Les tests d'intégration sont les tests qui vont tester une fonctionnalité entière. Tu prépares un environnement entier, tu appelles la fonctionnalité dans son ensemble et tu vérifies que le résultat est correct. Puis, tu fais varier les tests pour t'assurer que la fonctionnalité réagit bien selon tous les paramètres identifiés. Généralement, si tu as bien conçu ton application, tu vas tester tes interfaces en fait (au sens code du terme, pas ton interface graphique). Pour te donner un exemple concret, les tests de Zeste de Savoir utilisent beaucoup plus ce type de test que les tests unitaires (au grand bonheur de certains contributeurs et au malheur d'autres comme moi qui préfère les tests unitaires).
• Les tests fonctionnels : Nous montons d'un cran encore. Les tests fonctionnels ne vont plus tester le code mais ton interface graphique. En Java, tu as des solutions comme Selenium qui exécute les scénarios que tu lui demandes. Par exemple, tu lui demandes de cliquer sur le champ e-mail, de rentrer la valeur "clementine@zestedesavoir.com", puis de cliquer sur le champ password, de rentrer la valeur "azerty" et tu termines par lui demander de cliquer sur le bouton "Envoyer". C'est vraiment un niveau de test très élevé, tu t'en doutes bien puisqu'on ne fait plus aucun appel direct au code source.
• Les tests d'acceptation : Moins courant dans les projets persos mais très courant dans l'entreprise, les tests d'acceptation sont les tests que tu passes avec le client. A partir d'ici, il n'y a plus rien d'informatisé. Tu vas à la rencontre du client, tu lui exposes la fonctionnalité et il te valide ou non la fonctionnalité. Engager le client dans le cycle de développement d'une application est une pratique de plus en plus courante avec les méthodologies agiles du type SCRUM. Bien entendu, dans le cadre d'un projet perso, tu es toi même le client et le développeur mais c'est toujours mieux de faire valider ton code/fonctionnalité par une tierce personne. Dans ton cas, puisque tu travailles avec une autre personne, tu peux lui demander de valider la fonctionnalité que tu viens de développer. Ca permet d'avoir un regard extérieur sur ton travail.

Voilà, n'hésite pas si tu as d'autres questions et bonne chance dans tes recherches sur le TDD. Il y a vraiment beaucoup de versions différentes dans l'application de cette méthodologie de la plus extrême à la plus souple.