Journal : Bonnes pratique pour le développement
Posté par Papa Furax (page perso, ) le 11 janvier 2007
Bonjour,
je suis intéressé par ce que vous considérez comme de bonnes pratiques, que vous avez vous-même expérimenté.
Pour préciser je suis plus intéressé par des exemples pratiques que par la théorie. Et plus par la méthode que par les technique de programmation.
Voici pour ma contribution:
- Toujours utiliser une gestion de configuration, même à un ou deux.
Les avantages sont évidents. Ne pas utiliser une gestion de configuration qui plombe le processus de développement, je pense à un certain logiciel propriétaire assez buggé, lent, contre-intruitif, et qui veut en faire trop. En bref Subversion est très bien.
- utiliser une méthodes automatisée pour générer et déployer l'application.
- plus généralement les procédures manuelles sont à proscrire.
- Ne pas laisser d'erreurs considérés comme "normales":
Tout ce qui est en gestion de configuration doit compiler (!!),
de préférence sans warning. Et quand on passe les procédures automatises (ant, make, script), cela doit se passer sans erreurs.
- Eviter les générateur de code.
- Ne pas mettre en gestion de configuration des fichiers qui sont générés.
- Commiter du code propre et indenté (penser au merge)
- Ne pas utiliser les tabulation mais des espaces à la place
- Ne pas commiter de fichier avec du code en commentaire
- Utiliser des outils réactif: rien de plus agaçant et distrayant que d'attendre devant son écran.
- définir un vocabulaire: ne pas utiliser le même mot pour des choses différentes, même si les contextes sont différents.
Voilà, et vous quelle est votre expérience du front?
je suis intéressé par ce que vous considérez comme de bonnes pratiques, que vous avez vous-même expérimenté.
Pour préciser je suis plus intéressé par des exemples pratiques que par la théorie. Et plus par la méthode que par les technique de programmation.
Voici pour ma contribution:
- Toujours utiliser une gestion de configuration, même à un ou deux.
Les avantages sont évidents. Ne pas utiliser une gestion de configuration qui plombe le processus de développement, je pense à un certain logiciel propriétaire assez buggé, lent, contre-intruitif, et qui veut en faire trop. En bref Subversion est très bien.
- utiliser une méthodes automatisée pour générer et déployer l'application.
- plus généralement les procédures manuelles sont à proscrire.
- Ne pas laisser d'erreurs considérés comme "normales":
Tout ce qui est en gestion de configuration doit compiler (!!),
de préférence sans warning. Et quand on passe les procédures automatises (ant, make, script), cela doit se passer sans erreurs.
- Eviter les générateur de code.
- Ne pas mettre en gestion de configuration des fichiers qui sont générés.
- Commiter du code propre et indenté (penser au merge)
- Ne pas utiliser les tabulation mais des espaces à la place
- Ne pas commiter de fichier avec du code en commentaire
- Utiliser des outils réactif: rien de plus agaçant et distrayant que d'attendre devant son écran.
- définir un vocabulaire: ne pas utiliser le même mot pour des choses différentes, même si les contextes sont différents.
Voilà, et vous quelle est votre expérience du front?
> Lire le journal (89 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #793247.
Run by 
Cette page a été générée par Templeet en 0.0475s (dont 0.0049 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Alors, il faut générer ou pas ?
En ce qui me concerne, je remplacerais celle là par :
- Générer le code chaque fois que c'est possible.
pour moi, utiliser un générateur de code, c'est du même ordre d'idée que d'utiliser une bibliothèque externe.
Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!
Alors, on les génère ou pas ?
[^]Re: Alors, il faut générer ou pas ?
Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!
+1
Alors, on les génère ou pas ?
J'ai dis "éviter", pas interdire ;)
En fait je me pose pas mal de question la dessus.
A mon avis, si le langage permet de réutiliser le code, ou d'écrire du code générique pour le problème rencontré, il faut privilégier cette voix
En tout cas la génération de code pose problème pour les fichier qu'on doit retoucher ensuite:
- écrasement des modifs par la génération suivante
- les dév on peur de toucher le code généré
- générateur pas à jour -> procédure manuelle pour palier le problème.
Car bien souvent un générateur est complexe, et personne ne veux/peux le maintenir si la personne qui l'a mis en place n'est plus là.
Plus généralement je me pose aussi la question de l'utilisation des outils de "programmation visuelle".
J'ai plutôt tendance à avoir confiance dans une approche entièrement textuelle: le code fais foi,
mais j'arrive pas trop à me justifier la dessus.
[^]Re: Alors, il faut générer ou pas ?
s/voix/voie
[^]Re: Alors, il faut générer ou pas ?
il ne faut *JAMAIS* modifier à la main du code généré
ils ont bien raison.
Deux cas :
1) le générateur viens de l'extérieur :
Avant de se décider à l'utiliser, s'assurer qu'il existera toujours (vive le logiciel libre !!!) et s'assurer qu'il est suffisemment bien construit pour avoir une gestion fine du code généré.
2) le générateur est écris en interne :
Il faut le gérer comme le reste du code qui peut être complexe aussi !!!