Les règles d'or de la programmation

[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]

Envoyé par souviron34

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.

Envoyé par souviron34

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]

Envoyé par el_slapper

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

Envoyé par el_slapper

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.

[mogwai162]

Bonjour

Tout à fait d'accord avec les remarques concernant la notation hongroise (pas de typage) et la refactorisation (le mieux est l'ennemi du bien trop refactorisation et c'est le clash assuré surtout sans tests de non régression qui sont nécessaires lors de chaque modification du programme).

En ce qui concerne l'évaluation et le respect des délais, en ce qui me concerne c'est déjà du hors sujet. En dehors de la portée de l'article. Il n'a pas été question de la rédaction du cahier des charges ni du suivi des utilisateurs. Arrêtons nous là.

Merci

[HamzaR9]

Merci bcp pour ces règles

[dragonno]

Bon article mais qui ne s'adresse pas aux débutants car le trait est rapide, sec, utilisant souvent des termes de professionnels et de techniques qui le sont aussi.

Le titre de ce topic ne correspond pas du tout au sujet de l'article, qui est selon l'auteur :

comment faire pour devenir un meilleur développeur ?

Je verrais cet article comme plutôt réservé à des programmeurs d'expérience, et même en milieu professionnel je dirais.

Quel que soit votre environnement de développement, langage, société dans laquelle vous travaillez,

Nullement question de niveau dans la description, même si le sigle "pour tous" est affiché.

Ce serait utile de modifier le titre en conséquence donc.

Pour les débutants je prévois bientôt un article sur mon site qui leur est réservé. (ma signature)