Qu'est-ce qu'un code "propre" selon vous ?

**Matthieu Brucher** · 20/05/2009, 11h16

Envoyé par souviron34

Avec les algos de maths, c'est nettement plus compliqué de découper en fonctions.. Tu fais un site Web, tu fais une appli de gestion, peut-être que c'est assez facile... Mais dans énormément de cas de programmation, ce n'est pas le cas....

Pour avoir fait des code de calcul assez alambiqués pour ma thèse et actuellement pour mon travail, je ne suis pas d'accord. Si tu penses à la conception de ton code de calcul dès le départ, c'est faisable. Mais pour ça, il faut des gens qui maîtrisent leur outil (ce qui n'est pas toujours le cas).

**souviron34** · 20/05/2009, 12h22

Je re-dis qu'il y a aussi une question a) de reponsabilité et b) de temps..

Lorque tu as besoin d'un code (pas en thèse, en production de code), et que ce code est une méthode de math complexe, il n'est pas évident que tu aies : a) le droit et b) le loisir de le regarder suffisamment à fond pour le modifier...

Et si un gros contrat dépend de cette partie, et que tu la récupères dans une bibliothèque quelconque, de quelqu'un de reconnu, il n'est pas évident de re-factorer tout en gardant une certaine garantie... (voir les codes figurant dans Graphics Gems, dans les USENET newsgroup sérieux (comp.algorithms par exemple), etc etc..)

Quand on a le temps, ça peut le faire..

Pas évident ..

Maintenant un autre thread ici-même qui est relié :

Projets informatiques : les bonnes pratiques

**el_slapper** · 20/05/2009, 14h09

Envoyé par souviron34

(.../...)
Lorque tu as besoin d'un code (pas en thèse, en production de code), et que ce code est une méthode de math complexe, il n'est pas évident que tu aies : a) le droit et b) le loisir de le regarder suffisamment à fond pour le modifier...

Et si un gros contrat dépend de cette partie, et que tu la récupères dans une bibliothèque quelconque, de quelqu'un de reconnu, il n'est pas évident de re-factorer tout en gardant une certaine garantie... (voir les codes figurant dans Graphics Gems, dans les USENET newsgroup sérieux (comp.algorithms par exemple), etc etc..)(.../...)

Je dirais que c'est l'argument ultime. Je vois les tenants du no comment parler de "refactorisation" à tout bout de champ. Mais ça part du principe que l'on dispose du temps pour le faire, ainsi que des compétences pour tester la non-regression de l'ensemble.

Parceque faire des classes de test, c'est bien, c'est beau, c'est utile, ça permet de faire des tests unitaires rapidement, etc..... Mais il ne faut pas croire que ça teste tout, et surtout pas l'intégration de l'ensemble dans un ensemble plus grand, dont on ne maîtrise pas tout (une banque, c'est des milliers d'informaticiens de tout poil). En bref, on ne peut pas se permettre de refactoriser 173000 programmes(chiffre authentique, quoique vieillissant et donc sans doute sous-estimé) juste parcequ'ils ne sont pas beaux. Ou pire, beaux, mais la norme a changé.

Evidemment, coder propre, c'est d'abord s'assurer que le code est facile à comprendre sans commentaires. Je crois qu'on est tous d'accord là-dessus. Simplement, si j'ai 35000 lignes de code pour faire un traitement complet, un titre, aussi maousse soit-il, sera insuffisant à faire comprendre l'ensemble des actions du programme. Quand à descendre les 35000 lignes(pas obligé de faire un programme unique, hein.....) à la mano, c'est gentil, mais ça me parait longuet. Je ne parle même pas de refactoriser.

A ce titre, des commentaires qui présentent le traitement, et ses principales fonctions sont très utiles. Même si le code était très lisible(ce qui n'était pas le cas, mais admettons que ça aie été le cas), avoir une idée globale en entrée du traitement, puis en détail de chaque procédure, sans avoir à lire tout le code, c'est très utile.

Je reviens sur la refactorisation : quand on touche à des fonction métier complexes, si il n'y a personne du métier qui connaisse, on laisse tel quel. Peu satisfaisant? Evidemment. Mais vaut-il mieux se faire plaisir et rendre un code impeccable, ou bien garantir la continuité du service garanti au client, quitte à garder quelques horreurs qui ont la désagréable qualité d'avoir été validés?

**sleepy2002** · 20/05/2009, 14h09

Envoyé par souviron34

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
/**
 * Hough Transform
 * 
 * @author Xavier Philippeau
 *
 */
public class Hough {
 
	private int Width,Height;
 	private double maxRho;
 	private int maxIndexTheta,maxIndexRho;
	int[][] acc;
 
	public Hough(int width,int height) {
	   ...
	}
 
	public void vote(int x,int y) {
	...
	}
 
	public double[] winner() {
		...
	}
 
	public double[] rhotheta_to_ab(double rho, double theta) {
		...
	}
}

Très nettement plus difficile à comprendre que le code avec les commentaires exposé dans l'article image detecteur de lignes de Hough

Cela rejoint mon point sur les commentaires en entête de méthodes publique d'une classe en écrivant la formule mathématique mis en oeuvre. du coup, on peut éviter les commentaires intra méthodes

Envoyé par souviron34

Code Fortran :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
C***********************************************************C
C       SOLVE LINEAR SYSTEM VIA GAUSSIAN ELIMINATION        C
C          ORDER UP TO 10                                   C
C             ( 10.01.1979 K. BANSE )                       C
C                              (SACLAY - HPCCD - 1982/84)   C
C***********************************************************C
        SUBROUTINE LNSYS(ARRAY,X,NORDER,IERR)
         ...
        END

Je ne ne suis pas expert en fortran (TP à l'université seulement). En lisant un peu, n'y a t'il pas moyen de découper en sous fonctions pour améliorer la lisibilité.

En ce qui concerne la lisibilité d'un code, vous connaissez peut-être l'article de Martin Fowler sur les Fluent Interface.

**sleepy2002** · 20/05/2009, 14h23

Pour en revenir aux commentaires intra méthodes, je travaille dans une équipe où l'on fait évoluer un parc d'applications financières basé sur un framework composé de plus 30 librairies internes. Aucun commentaires intra méthodes, seulement sur les API du framework. En même temps, c'est du java donc on peut se permettre d'être plus expressif (ah les 80 colonnes de Fortan...)

**sleepy2002** · 20/05/2009, 14h34

A el_slapper,

je comprends ton appréhension face au refactoring. Cette phase est possible uniquement si ton code est bien couvert par des tests qui eux respectent les cas d'utilisation de base et extrême.

Les tests unitaires donnent confiance au développeur dans sa démarche de refactoring. Que le projet comporte 17500 classes ou 5 classes, la problématique est identique : Est-ce que mon code est bien couvert ?

D'abord boucher les éventuels trous puis entamer le refactoring de manière progressive (méthode -> classe -> module -> API -> Programme final).

**souviron34** · 20/05/2009, 14h38

Envoyé par el_slapper

Je reviens sur la refactorisation : quand on touche à des fonction métier complexes, si il n'y a personne du métier qui connaisse, on laisse tel quel. Peu satisfaisant? Evidemment. Mais vaut-il mieux se faire plaisir et rendre un code impeccable, ou bien garantir la continuité du service garanti au client, quitte à garder quelques horreurs qui ont la désagréable qualité d'avoir été validés?

Je suis bien entendu d'accord avec tout ce que tu dis, mais j'insisterais sur ce point souligné ici..

On a l'impression,à entendre (!!) les gens ici, qu'en fait on peut faire ce qu'on veut avec un code : le ré-écrire, le refactorer, etc etc..

Mais l'argument fondamental de la majorité des cas c'est : on ne peut pas re-tester NI avoir une (100) personne(s) à disposition pour re-tester...

Et on ne peut pas se permettre de laisser tomber un cas (par inadvertance).

Or doncques, comme tu le dis, dans 90% des cas on laisse tel quel...

Et même si c'est nous qui avons écrit le code, si c'est un code opérationnel (que ce soit une banque, un avion, ou n'importe quel autre métier "dur"), juste le fait que ça ne marche peut-être pas aussi exactement que la veille suffit à faire rejeter l'ensemble, ce qu'évidemment personne ne peut se permettre...

(sans compter, comme tu le mentionnes, les N parties (> 100 ou 1000) impliquées et les M (> 10 ou 100) programmeurs (ou générations de programmeurs) travaillant dessus...)

Mais pour terminer là-dessus, il est extrêmement rare, voire totalement inédit, qu'un pool d'utilisateurs (et de machines et de cas réels) soit mis à disposition pour retester...

Et il est par conséquent essentiel (je me répète) de documenter TOUT ce qui peut nécessiter une explication...

**souviron34** · 20/05/2009, 14h42

Envoyé par sleepy2002

A el_slapper,

je comprends ton appréhension face au refactoring. Cette phase est possible uniquement si ton code est bien couvert par des tests qui eux respectent les cas d'utilisation de base et extrême.

Les tests unitaires donnent confiance au développeur dans sa démarche de refactoring. Que le projet comporte 17500 classes ou 5 classes, la problématique est identique : Est-ce que mon code est bien couvert ?

D'abord boucher les éventuels trous puis entamer le refactoring de manière progressive (méthode -> classe -> module -> API -> Programme final).

comme mentionné, cela n'est valable que si ça n'implique que toi...

Dès qu'il y a d'autres que toi (programmeurs par exemple), et surtout pour toute application industrielle, c'est quasiment impossible (sauf si la Direction le souhaite, auquel cas elle y met les moyens).

Nous ne sommes pas des testeurs "métier", et l'immobilisation d'une équipe de testeurs métiers coûte une fortune... (sans parler des machines nécessaires).

J'ai l'impression que vous ne parlez que de projets quasi-personnels...

**Matthieu Brucher** · 20/05/2009, 14h51

Personnellement, je me rends compte que si les ingénieurs qui développent les codes que je reprends par la suite avaient un début de culture informatique, avec des tests et tout et tout, on aurait beaucoup moins de crashs...

**pseudocode** · 20/05/2009, 14h53

Envoyé par souviron34

Or donc, comme tu le dis, dans 90% des cas on laisse tel quel...

Sur un projet "one shot" c'est effectivement très courant. On fait de la maintenance "ad minimina" pour eviter les effets de bords.

Sur des projets évolutifs c'est différent. Ne pas refactorer le code est un risque. L'ajout de nouvelles fonctionnalités (ou même des upgrades de librairies) sans toucher au code existant finit par transformer un projet "simple" en véritable usine a gaz. Les évolutions successives sont de plus en plus complexes et la difficulté devient exponentielle.

Il faut essayer autant que possible de faire du refactor sur ce genre de projet. Même si le temps de développement s'en trouve allongé, c'est du temps de gagné pour plus tard.

Le plus dur est de faire accepter ce travail supplémentaire par le chef de projet, qui est souvent pressé d'avoir un programme qui marche sans se soucier des problèmes futurs.

**rad_hass** · 20/05/2009, 14h54

Donc on commente parce que le code n'est pas propre, car on a ni le temps, ni les moyens de le rendre meilleure, parce que les architectures sont mal conçu, parce que les autres sont cons (je caricature un peu

) ...

Donc ça reviens à mettre du déodorant et éviter le pire, sachant que dans un monde parfait on aurait pu se passer de certains commentaires ... Mais comme le monde est loin d'être parfait il faut commenter, partout, tout le temps ...

Je caricature c'est sûre, dire que commenter n'a aucun intérêt dans tout les contextes, c'est un peu extrémistes à mon goût ... Donc comme la plupart du temps, il faut ni beaucoup commenté, ni pas du tout, juste commenter quand il est nécessaire de le faire ... Et ceux seulement quand on a déjà user de l'extraction de méthode, bien renommer nos variables et nos méthodes, introduit des assertions ...

Le commentaire est important pour comprendre un code un peu pourrit ou mal structuré (pour certains une classe de plusieurs milliers de lignes est un code un peu pourrit), mais l'est il pour un bon code ?

Je n'ai pas l'expérience de certains, mais mon avis compte beaucoup pour moi, alors permettez moi de l'exposer

**white_tentacle** · 20/05/2009, 14h59

Mon expérience est aussi qu'à force de n'avoir pas voulu toucher des choses qui marchaient, on se retrouve à devoir faire mal pour ne pas prendre le risque, et avec le temps, tout devient beaucoup plus complexe.

Evidemment, il faut distinguer plusieurs types d'applications :
- les applications internes, ou hébergées (SaaS). Généralement, elles évoluent en continu, avec de petites modifications par ci par là, et une volonté de minimiser les risques de régressions.
- les applications déployées, vendues (type éditeur de logiciel classique), où là, on a à chaque sortie de version une grosse phase de tests. L'occasion d'une bonne phase de refactoring et de nettoyage.

Il est clair qu'en fonction de ce qu'on fait, les contraintes ne sont pas les mêmes, et en conséquence, ce qui est valable d'un côté ne l'est pas de l'autre.

Personnellement, je me rends compte que si les ingénieurs qui développent les codes que je reprends par la suite avaient un début de culture informatique, avec des tests et tout et tout, on aurait beaucoup moins de crashs...

C'est marrant comme j'ai souvent la même impression

**sleepy2002** · 20/05/2009, 16h17

A souviron34,

j'apprécie cette discussion car la problématique d'un projet "legacy" à faire évoluer reste entière.

Dans mon équipe, nous avons hérité d'une application legacy qui avait été "touchée" par plusieurs programmeurs. Il y avait de la duplication de code partout, du code mort, des singletons "à état" de partout.

Il y avait très peu de TU mais les fonctionnalités clé étaient testées (tests end user black box).

Nous avions donc 2 chantiers : augmenter la couverture du code existant et remanier le code.

Nous y sommes allés progressivement et à présent dès qu'une nouvelle tâche fonctionnelle est exécutée, nous ajoutons si besoin des tests unitaires et remanions le code. Ainsi, on ne se tape pas 3 mois d'écriture de tests et le binôme qui travaille dessus reste motivé.

Attention, le refactoring n'est utile que s'il apporte de la valeur au programme (performance ou extensibilité) et à l'équipe (lisibilité).

**souviron34** · 20/05/2009, 16h34

Envoyé par pseudocode

Sur un projet "one shot" c'est effectivement très courant. On fait de la maintenance "ad minimina" pour eviter les effets de bords.

Alors que ce serait là que ce serait facile de le faire

Envoyé par pseudocode

Sur des projets évolutifs c'est différent. Ne pas refactorer le code est un risque.

Tout dépend de savoir si c'est toi qui a la majorité du projet ou qu'une petite partie...

Tout dépend si c'est toi qui gère l'évolution ou non..

Envoyé par pseudocode

L'ajout de nouvelles fonctionnalités (ou même des upgrades de librairies) sans toucher au code existant finit par transformer un projet "simple" en véritable usine a gaz. Les évolutions successives sont de plus en plus complexes et la difficulté devient exponentielle.

Idem que ci-dessus...

Envoyé par pseudocode

Il faut essayer autant que possible de faire du refactor sur ce genre de projet. Même si le temps de développement s'en trouve allongé, c'est du temps de gagné pour plus tard.

Le plus dur est de faire accepter ce travail supplémentaire par le chef de projet, qui est souvent pressé d'avoir un programme qui marche sans se soucier des problèmes futurs.

Je prend le cas du truc sur lequel je bosse : le coeur est secret, privé, et nous n'avons pas le droit d'y toucher. On refait tout le tour, mais pas l'intérieur .. Et même si il va falloir que je le touche pour le rendre compatible avec l'évolution actuelle, je ne me risquerais pas à toucher quoi que ce soit des algos et découpages et noms (trop de vies en jeu, alors que cela marche comme ça depuis 25 ans).

Je vais juste permettre d'accepter nos nouvelles données en entrée et récupérer les sorties... Mais je n'ai pas envie de me retrouver avec 20 000 morts à mon actif, donc je ne re-factore rien du tout

**el_slapper** · 20/05/2009, 16h40

Envoyé par sleepy2002

(.../...)Nous y sommes allés progressivement et à présent dès qu'une nouvelle tâche fonctionnelle est exécutée, nous ajoutons si besoin des tests unitaires et remanions le code. Ainsi, on ne se tape pas 3 mois d'écriture de tests et le binôme qui travaille dessus reste motivé.

Moi, ce qui me fous les jetons, c'est cette manière de dire "on couvre tous les tests unitaires, donc on est OK". Parceque bon, exemple vécu, on développe une appli en marge du système bancaire, qui va créer des comptes "indisponibles"(i.e. bloqués hors l'application créatrice), faire des transferts dessus, transférer l'argent qui est dessus, et les fermer.

Bon, on a des specs pour appeler le module de gestion de compte, on fait un truc nickel, qui passe tous les TU. On passe en intégration. Bang, y'a un cas qui n'était pas prévu, on recommence, on itére, et puis ça marche. Et puis on oublie parceque ça marche. 5 ans plus tard, on doit créer des comptes, mais avec une nouvelle norme de numérotation des comptes. Personne ne me fera croire que des tests unitaires suffiront pour garantir la bonne marche des comptes créés. Non, il faut passer une nouvelle fois en intégration, et vérifier avec les gens qui gèrent les comptes que la nouvelle numérotation ne met pas la grouille dans leur système.

Ce qui exige de la main d'oeuvre disponible de leur coté, tant technique que fonctionelle. Si cette main d'oeuvre n'est pas disponible, eh bien la nouvelle numérotation attendra. Même si elle passe tous les tests unitaires possibles et imaginables. Et ce, indépendament de la perfection qui a pu être atteinte avec la première version. Ca ne suffit pas - sauf à réaliser une appli tout seul dans son coin.

**sleepy2002** · 20/05/2009, 16h42

Envoyé par pseudocode

Il faut essayer autant que possible de faire du refactor sur ce genre de projet. Même si le temps de développement s'en trouve allongé, c'est du temps de gagné pour plus tard.

Je travaille exactement dans ce cadre-là. Maintenance évolutive et donc implique un cycle de développement itératif incrémentale que nous maîtrisons assez bien puisque que l'on travaille en mode XP (TDD, binômage).

Le refactoring n'est pas systématique, cela dépend des besoins. Privilégier une conception simple marche et qui évoluera au fil du temps plutôt que de vouloir sortir tout de suite un truc "méta générique".

**souviron34** · 20/05/2009, 16h45

Envoyé par white_tentacle

Mon expérience est aussi qu'à force de n'avoir pas voulu toucher des choses qui marchaient, on se retrouve à devoir faire mal pour ne pas prendre le risque, et avec le temps, tout devient beaucoup plus complexe.

C'est vrai, mais la plupart du temps nous n'y pouvons rien (les contraintes sont en dehors de notre champ de décision).

Envoyé par white_tentacle

Evidemment, il faut distinguer plusieurs types d'applications :
- les applications internes, ou hébergées (SaaS). Généralement, elles évoluent en continu, avec de petites modifications par ci par là, et une volonté de minimiser les risques de régressions.

Oui, mais déjà dans celles-là, dès que le gugusse s'en va, démissionne, part à la retraite, ou meurt, ben t'es dans la panade..

Et si finalement toute l'équipe a changé, et que tu refiles à l'externe, c'est pas mieux...

Envoyé par white_tentacle

- les applications déployées, vendues (type éditeur de logiciel classique), où là, on a à chaque sortie de version une grosse phase de tests. L'occasion d'une bonne phase de refactoring et de nettoyage.

Non, là tu prends l'exemple de "petites" applications..

Que ce soit l'application sur laquelle j'ai travaillé l'an dernier (environ 500 exemplaires vendus dans le monde, 2 millions de lignes de code, 4 millions d'euros pièce) ou celle sur laquelle je bosse aujourdhui (25 ans d'existence, 150 000 lignes de code, mais plus d'équipe originale, pas de docs, développement pendant 22 ans en interne, beaucoup de vies en jeu), on ne s'amuse pas à refactorer si on peut s'en passer.. Même si cela finit par être du spaghetti...

Et c'est rempli, dans le monde, d'applications comme celles-là..

Les jeux ou autres sont de "petites" applis, qui elles peuvent se permettre (de temps en temps), un refactoring..

Beaucoup d'applis industrielles ne peuvent se le permettre que pour une raison majeure : comme je mentionnais, plus personne de l'équipe originale, langage disparu, machine disparue, bibliothèque externe plus supportée, client l'exigeant, etc etc..

**sleepy2002** · 20/05/2009, 16h46

A el_slapper,

Je suis d'accord que les TU ne suffisent pas. Nous avons des tests automatisés (end user) qui tournent sur un environnement d'intégration.

S'il y a un "trou de spec", le MOA mettra à jour son usecase et les développeurs mettront à jour le code + TU associé.

**souviron34** · 20/05/2009, 16h55

Envoyé par Matthieu Brucher

Personnellement, je me rends compte que si les ingénieurs qui développent les codes que je reprends par la suite avaient un début de culture informatique, avec des tests et tout et tout, on aurait beaucoup moins de crashs...

Tu n'en es pas un ?

Mais de toutes façons, comme on va le dire plus bas...

Les tests ne suffisent pas..

Et d'autre part, si il fallait un informticien patenté derrière chaque ingénieur pour chaque programme scientifique, on n'en finit pas..

Parce que, au fait, pour faire un programme qui doit faire ce qu'il faut (dans le métier), et si tu n'y connais rien, il faut que tu commences par prendre un cours (ce qui veut dire dans la majeure partie des cas faire 5 ans d'études supplémentaires et 10 ans d'expérience)... Ou alors écrire 250 pags de doces alors qu'on n'est même pas sûr du résultalt..

Envoyé par sleepy2002

nous ajoutons si besoin des tests unitaires et remanions le code. Ainsi, on ne se tape pas 3 mois d'écriture de tests et le binôme qui travaille dessus reste motivé.

oui, mais comme on le dit plus bas :

Envoyé par el_slapper

Moi, ce qui me fous les jetons, c'est cette manière de dire "on couvre tous les tests unitaires, donc on est OK".
...
Ce qui exige de la main d'oeuvre disponible de leur coté, tant technique que fonctionelle. Si cette main d'oeuvre n'est pas disponible, eh bien la nouvelle numérotation attendra. Même si elle passe tous les tests unitaires possibles et imaginables. Et ce, indépendament de la perfection qui a pu être atteinte avec la première version. Ca ne suffit pas - sauf à réaliser une appli tout seul dans son coin.

Les TU ne prouvent RIEN...

Et toutes les méthodes se BASANT là-dessus ont , elles, prouvé qu'elles ne marchaient pas (le cycle en V bête).

Ce n'est pas parce que les TU marchent que l'appli fait ce q'elle doit faire...