Maintenir du code sur le long terme ..

.. quand on n'y consacre que quelques heures par semaine !

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous !

J'ai développé intensément pendant les vaccances scolaire un site web. Avec la rentrée ça a radicalement changé ! Je ne passe plus que 2-3 heures sur le projet par semaine (Je savais très bien que le rythme allait changer, et là n'est pas la question ;) ).

Le problème c'est que pendant ces 2-3 heures j'ai l'impression d'être 100 fois moins efficace que pendant du développement "continu" (tous les jours) :( ! C'est sans doute normal (le temps de se replonger dans le code etc), mais ce qui me gène particulièrement, c'est que j'ai l'impression de casser la cohérence du projet ..

C'est à dire que j'ai l'impression de bricoler quelques trucs de droite à gauche, sans me soucier du reste (ce que je fais normalement en "dev continu", mais ça me prend plus de temps). On en vient donc à la raison d'être de ce sujet :D :

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 ?

  • 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 ?
  • 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).

Merci d'avance pour vos suggestions/remarques ! :)

NB : quelques précisions sur mon cas :

  • Je développe ce projet principalement avec une autre personne, et occasionnelement avec une autre.
  • La semaine je fais des maths dans ma taupinière de math spé, donc ce projet me sort totalement de la tête durant cette période !
+4 -0

Cette réponse a aidé l'auteur du sujet

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é ! :)

Édité par Andr0

+4 -0
Auteur du sujet

Tout d'abord merci pour cette réponse très utile ! :)

Je ne connaissais pas du tout la méthode TDD, mais c'est exactement ce genre de réponse que je cherchais ! Je vais creuser un petit peu et je te fais un retour si j'ai des questions.

Au passage, juste une petite question ^^ : y a-t-il un équivalent aux tests unitaires pour des "tests globaux" ?

+0 -0

Cette réponse a aidé l'auteur du sujet

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.

Édité par Andr0

+7 -0

Lu'!

Je vais me contenter de modérer un point.

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

Andr0

Les tests permettent de déceler la présence de bugs, jamais de montrer leur absence. En l'occurrence, ils sont capables de montrer qu'il y a un problème dans les cas auxquels on a pensé, et donc pas ceux auxquels on n'a pas pensé (même avec une spécification correcte).

Il existe des techniques de preuve de code ou inversement de génération de code correct par construction (on peut combiner les deux pour gagner encore en confiance), mais elles sont plus compliquées à mettre en place (et on reste dépendant de la qualité de la plateforme de vérification).

Pour renforcer les points les plus importants à mon sens.

Ecrire du code clair est de loin le meilleur moyen de le rendre compréhensible. Cela passe par donner des noms parfaitement clairs aux variables, fonctions et types pour que d'un coup d'oeil on comprenne leur rôle. Et par le fait de bien découper les fonctionnalités, une bonne fonction est une fonction courte qui fait un job simple et précis.

Une bonne habitude à prendre est également de faire du code qui soit facile à étendre tout en ne nécessitant pas de modification lors de son extension. En objet, c'est le principe OCP, il existe des équivalents dans les autres styles de programmation.

Édité par Ksass`Peuk

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein

+0 -0

Les tests permettent de déceler la présence de bugs, jamais de montrer leur absence. En l'occurrence, ils sont capables de montrer qu'il y a un problème dans les cas auxquels on a pensé, et donc pas deux auxquels on n'a pas pensé (même avec une spécification correcte).

Je suis tout à fait d'accord, le 100% correct est peut-être un poil exagéré mais nous en sommes pas loin. Ce que je voulais faire passer comme message, c'est la plus grande confiance que tu peux accorder à ton projet testé grâce à une méthodologie TDD. Le principe du développement par TDD est de faire évoluer ton projet par rapport aux tests et pas l'inverse.

Par exemple, si on reprend mon exemple dans mon premier message avec l'achat d'un produit dans un magasin, la méthode buy n'aura jamais aucun bug en l'état, pourtant elle fait passer un test utile au vert. Après, c'est à toi de t'imposer l'exigence nécessaire pour les tests que tu écriras pour faire évoluer ton projet.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte