Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Tutoriel : Les règles d'or de la programmation
Par mogwai162 et Alexandre Laurent

Le , par fafabzh6

18PARTAGES

3  0 
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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 10/01/2013 à 11:51
Citation Envoyé par souviron34 Voir le message
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.

Citation Envoyé par souviron34 Voir le message
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.
4  0 
Avatar de DevNico
Membre éprouvé https://www.developpez.com
Le 16/01/2013 à 13:57
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
2  0 
Avatar de Graffito
Expert éminent https://www.developpez.com
Le 16/01/2013 à 22:51
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.
2  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 10/01/2013 à 13:22
Citation Envoyé par el_slapper Voir le message
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

Citation Envoyé par el_slapper Voir le message
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...
1  0 
Avatar de mogwai162
Membre chevronné https://www.developpez.com
Le 01/03/2013 à 20:47
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
1  0 
Avatar de HamzaR9
Nouveau Candidat au Club https://www.developpez.com
Le 21/03/2013 à 12:13
Merci bcp pour ces règles
0  0 
Avatar de dragonno
Membre confirmé https://www.developpez.com
Le 25/03/2013 à 2:57
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)
0  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 10/01/2013 à 11:22
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 ? )
0  2