Discussion :

[fafabzh6]

Bonjour,

Voici un nouvel article relatant quelques règles importantes pour réussir et mener à bien ses projets de programmation.
Celui-ci présente les bonnes pratiques à prendre afin de rendre son projet viable, modulable, portable et robuste.
De plus, quelques perspectives sur le travail collaboratif et les logiciels à utiliser pour mettre en place un environnement fiable sont également présentés.
Cet article ne vise aucun projet en particulier, ni de langage précis et se veut le plus généraliste possible.

Les règles d'or de la programmation.

Bonne lecture et n'hésitez pas à réagir et à donner votre opinion.

[souviron34]

2 petites remarques vite fait :

• La notation hongroise est fortement déconseillée (elle vient d'ailleurs à l'origine d'une erreur de traduction), car lourde, redondante, non maintenable et surtout non évolutive.
  
  
• La refactorisation est aussi à déconseiller dans la majorité des cas (voir Rewites considered harmful ? )

[el_slapper]

La notation hongroise est fortement déconseillée (elle vient d'ailleurs à l'origine d'une erreur de traduction), car lourde, redondante, non maintenable et surtout non évolutive.

la notation hongroise de type, oui, à éviter absolument, c'est lourdingue et inutile. Par contre, une normalisation des noms de données en fonction des éléments fonctionnels peut être futée. Par exemple, dans une macro EXCEL, préfixer de la même manière toutes les lignes, et d'une autre toutes les colonnes, peut être très utile.

La refactorisation est aussi à déconseiller dans la majorité des cas (voir Rewites considered harmful ? )

Euh, ton article parle de réécriture complète. le refactoring, c'est beaucoup plus léger, et c'est souvent indispensable. Article classique de Joel Spolsky sur le sujet. Avec les règles suivantes :

1. 1.No New Features, not even small ones, would be added.
2. 2.At any time, with any check in, the code would still work perfectly.
3. 3.All I would do is logical transformations -- the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.

Il s'agit de nettoyer proprement, mais sans essayer de réinventer la poudre. Je suis d'accord avec ton article : mettre à la poubelle et tout réécrire, c'est un exercice dantesque. Je l'ai fait une fois, sur un périmètre limité, C'est un boulot énorme(et qui n'a pu marcher que parceque j'avais les moyens de comparer totalement les 2 chaines, anciennes et nouvelles, de manière totalement automatique). A limiter à des cas particulier. Joel Spolsky est d'accord avec ton article, en plus. (il est même plus extrême encore).

Mais refactoriser un code pourri, ou alors un code à maintenir pour le faire évoluer, c'est une pratique saine si on se donne les moyens de tester la non-regression.

[souviron34]

Par contre, une normalisation des noms de données en fonction des éléments fonctionnels peut être futée. Par exemple, dans une macro EXCEL, préfixer de la même manière toutes les lignes, et d'une autre toutes les colonnes, peut être très utile.

Je ne connais pas les maco excel ou autres, mais de manière générale, il est alors préférable de normaliser par fonctioanlité en précisant par VerbeSujet/Complément qu'autre chose..

DisplaysDataset

ChecksValidity

IsThresholdReached

Euh, ton article parle de réécriture complète. le refactoring, c'est beaucoup plus léger, et c'est souvent indispensable. Article classique de Joel Spolsky sur le sujet. Avec les règles suivantes :

1. 1.No New Features, not even small ones, would be added.
2. 2.At any time, with any check in, the code would still work perfectly.
3. 3.All I would do is logical transformations -- the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.

Il s'agit de nettoyer proprement, mais sans essayer de réinventer la poudre. Je suis d'accord avec ton article : mettre à la poubelle et tout réécrire, c'est un exercice dantesque. Je l'ai fait une fois, sur un périmètre limité, C'est un boulot énorme(et qui n'a pu marcher que parceque j'avais les moyens de comparer totalement les 2 chaines, anciennes et nouvelles, de manière totalement automatique). A limiter à des cas particulier. Joel Spolsky est d'accord avec ton article, en plus. (il est même plus extrême encore).

Mais refactoriser un code pourri, ou alors un code à maintenir pour le faire évoluer, c'est une pratique saine si on se donne les moyens de tester la non-regression.

D'une part l'article parlait de "refactorisation" sans préciser.

D'autre part, au vu du niveau de l'article, qui s'adresse à des débutants, il est à mon avis peu souhaitable de prler de "re"-factorisation... surtout si le sens n'est pas le sens généralement admis de "refactorisation complète"... Dans le cas de l'article, il s'agit plutôt de modularité, fabrication et utilisation de biblothèques...

[DevNico]

Un point qui n'apparait pas dans cet article, et qui fait partie d'une des principales choses qu'on demande à un développeur dans le cadre d'un projet informatique, c'est le reporting sur son avancement.

Suivre le temps qu'il y a passé, et estimer le temps qu'il lui reste à faire pour clore son développement sont 2 choses primordiales pour le bon fonctionnement du projet.
C'est notamment sur la qualité de l'estimation du reste à faire qu'on identifie les bons développeurs.

Nicolas

[Graffito]

C'est notamment sur la qualité de l'estimation du reste à faire qu'on identifie les bons développeurs.

C'est surtout comme cela qu'on identifie les bons chef de projet qui doivent tenir compte de la qualité des dévellopeurs affectés au projet pour établir un planning réaliste.