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 #793226.
Run by 
Cette page a été générée par Templeet en 0.0775s (dont 0.0159 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
vocabulaire
Juste pour être sûr de bien comprendre ce que tu veux dire, ne faut-il pas plutôt lire "gestionnaire de versions" plutôt que "gestion de configuration" ?
J'ajouterais dans les bonnes pratiques:
- faire des tests (unitaires, fonctionnels)
- écrire de la doc
[^]Re: vocabulaire
et pour être sympa avec les copains qui repasse dérrière :
- ne pas coder comme un porc
- non, une fonction de 1000 lignes, ce n'est pas de l'optimisation.
(ceux qui code des fonctions de mille lignes, on devrait les pendre par les couilles ou non pire : les obliger de maintenir leur code à vie)
[^]Re: vocabulaire
Ben si, c'est de l'inlining!! ;)
Oui je suis bien d'accord!
Ca va souvent de paire avec la programmation par copier/coller qui est une hérésie quand on utilise un langage objet (avec un autre langage aussi d'ailleurs)
[^]Re: vocabulaire
si on pend par les couilles ceux qui font des fonctions de 1000 lignes, que doit-on faire de ceux qui écrivent des fonctions de 4-5000 lignes plusieurs fois dans un fichier > 30 000 lignes le tout en utilisant un langage objet et les fonctions ayant plus de 10 paramètres ?
(vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)
Sinon, pour moi le mini vital c'est :
- svn (ou autre, faut pas être sectaire ;-) )
- bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
- des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
- point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...
Sinon, j'irai plus loin sur le traitement des erreurs.
Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.
(*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.
[^]Re: vocabulaire
Moi je suis sectaire, et je dis mort a SourceSafe. Les autres je gere, mais celui-la, non, vraiment, je peux pas.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: vocabulaire
c'est pas être sectaire ça ;)
Toute personne ayant déjà utilisé sourcesafe sait que ce n'est pas un vrai gestionnaire de source mais simplement une blague que les personnes de crosoft on voulu faire mais que des idiots on décidé de prendre au sérieux...
(oui, 1 an de sourcesafe ça marque, j'avais fini par écrire un soft en ruby permettant de migrer sourcesafe vers svn mais j'ai quitté la boite avant de le finir totalement ;-) )
[^]Re: vocabulaire
Mais mais mais .. on a bossé dans la même boite ??
[^]Re: vocabulaire
On est tant que ca a etre passés par Sharp ?
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: vocabulaire
non, et c'est ça le pire... c'est qu'il y en a plusieurs des boites comme ça...
Moi qui coryait être passé dans une exception ;-)
Le mieux ça a été leur tête quand j'ai demandé, lors de mon 2° jour dans cette boite, s'il y avait des conventions de codage et si oui lesquelles. J'ai compris un peu plus tard, quand j'ai vu leur code...
Ils ont du me prendre pour un fou ! ;-)
[^]Re: vocabulaire
Ouais pareil et ce n'est pas Sharp :
- pas de convention de codage
- des fonctions qui font facilement plusieurs milliers de lignes
- des prototypes de fonctions avec plusieurs dizaines de variables
- pas de typage fort
- pas d'indentation défini
- le nommage des variables dans le genre x, y, z ou toto, tata
- réutilisation des variables pour faire passer d'autres infos .. d'autres types
- ..
En fait c'est super formateur parceque c'est tout à fait à l'opposé de l'ensemble des bonnes pratiques :) Comme ça tu vois en vrai pourquoi il ne faut pas faire ça.
[^]Re: vocabulaire
Oui "gestionnaire de version", ça me va aussi.
Pour les tests, ça me parait évident, bien que les test unitaires n'ont pas l'air d'être évidents pour tout le monde.
De la même manière utiliser un outils de suivi de bug me semble tellement indispensable que je m'aperçoit que je ne l'ai même pas mentionné.
Pour la doc, c'est important, mais il faut éviter de faire de la doc pour faire de la doc.
Moins il y en a et mieux c'est (il faut la maintenir à jour), mais il y a un minimum à fournir
.
Pour la forme, le wiki c'est pas mal (mieux qu'un tas de fichiers bien enfouis sur un lecteur partagé en tout cas)
Mais c'est pas optimal non plus, au bout d'un moment, les gens oublient de mettre à jour le wiki, et de plus les non-informaticiens ne sont pas toujours à l'aise avec.
[^]Re: vocabulaire
/me se rappelle avec nostalgie d'une de ses précédentes boites (penser télécom et Suede) ou il a passé 3 mois a écrire de la doc pour un wrapper entre 2 API qui a été codé et testé en une demi-journée.
J'ai démissioné au bout de 5 mois. Bon, j'avoue que c'est aussi parce que j'avais dans les mains une offre que je ne pouais pas refuser, mais j'étais soulagé de partir...
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: vocabulaire
Par contre personnellement je dirais qu'il faut SPECIFIER le code que l'on écrit (schéma ou texte, peu importe), de telle façon que n'importe qui puisse intégrer le projet sans passetr trop de temps à lire des sources pour savoir comment ca marche.
[^]Re: vocabulaire
Un outil de gestion de version est un outil qui permet de faire de la gestion de configuration :)