Discussion :

[Matthieu Vergne]

Là où je te rejoins, c'est sur l'idée que "bon" est subjectif : ça ne veut rien dire si ce n'est ce que tu décides arbitrairement de mettre derrière.

En revanche, cela ne veut pas dire qu'il n'est pas possible de tirer des grandes lignes en fonction d'une expérience commune : c'est parce qu'un nombre significatif de personnes dans le domaine estime qu'une pratique est bonne qu'on la considère comme telle. C'est cela qui permet de pouvoir généraliser. Tu peux toujours avoir tes propres critères, mais cela ne regarde que toi. Si on veut parler de quelque chose de généralisable, il faut voir ce qui se fait/pense de manière globale. On peut toujours ne pas être d'accord d'un point de vue personnel, mais quand on n'a pas l'expérience pour décider par soi-même, il est préférable de se fier à des principes globalement acceptés plutôt que venant d'un avis personnel naturellement biaisé. C'est en ce sens qu'il est important de se mettre d'accord sur ce qu'est un "bon" code (ou quoi que ce soit d'autre) : ce n'est pas pour ceux qui ont déjà décidé de leur propre façons de faire, mais pour ceux qui se demandent comment ils peuvent améliorer la leur.

Par contre, faire un bon programme ne se limite pas à respecter le cahier des charges : le client a ses connaissances, le dév a les siennes. C'est par la combinaison des deux qu'on eut faire quelque chose de bien pour les deux. Le dév n'est pas qu'un exécutant. Si tu prends cette perspective, alors faire un "bon" code, tu n'en a a priori rien à faire.

[CodeurPlusPlus]

Et tu fais comment quand ton cahier des charges ne te dis pas quoi faire ?

Ou, pire, quand le cahier des charges n'existe pas.

[Hatsrog]

Quand je pense à un bon code, je pense à un code susceptible d'évoluer sans difficulté sans trop toucher à l'ossature du projet.
Je pense aussi à un code où les risques de failles et d'autres intrusions sont minimisés, il m'est déjà arrivé de travailler sur l'évolution de sites très beaux graphiquement mais avec des failles de sécurité béantes
Souvent ce point là est (hélas) parfois un peu bâclé, souvent pour des raisons de temps

[el_slapper]

(.../...)Par contre, faire un bon programme ne se limite pas à respecter le cahier des charges : le client a ses connaissances, le dév a les siennes. C'est par la combinaison des deux qu'on eut faire quelque chose de bien pour les deux. Le dév n'est pas qu'un exécutant. Si tu prends cette perspective, alors faire un "bon" code, tu n'en a a priori rien à faire.

Voilà. Être un professionnel, ce n'est pas lire le petit manuel. C'est savoir l'interpréter en fonction des circonstances.

Exemple. LE CdC fait une liste de cas dans lesquels le batch doit rejeter un enregistrement en entrée invalide. Il ne dit pas que faire en cas de rejet. Le développeur peut choisir entre un plantage crade et une gestion propre des rejets avec recyclage et retour d'information vers l'appli en amont. Choisir entre rejeter la faute sur le C.d.C. et faire son boulot. (j'ai pris une engueulade de 20 minutes pour avoir fait mon boulot à cette occasion, et j'ai adoré ça : elle savait qu'elle avait tort, et moi aussi).

[landry161]

Ou, pire, quand le cahier des charges n'existe pas.

Alors là misère de misère

[Matthieu Vergne]

Alors là misère de misère

Mais non, voyons. Ça veut dire que tu peux faire ce que tu veux. {^_^}

Positivons !

[landry161]

Mais non, voyons. Ça veut dire que tu peux faire ce que tu veux. {^_^}

Positivons !

Ouais je sais mais sans cahier de charge ...
Ce qui est probable c'est que quand tu finiras sans le CdC, c'est en ce moment que le client va te faire ch...

[deltree]

Vaste sujet, ça me fait penser au débat sur le bon et le mauvais chasseur.

J'ai ajouté autres, parce qu'il y a un nombre de point énorme, et pour moi "l'homogénéité" du code c'est le fait que toutes les personnes de l'équipe respectent l'architecture principale de l'application. ça se rapproche aussi du principe de moindre surprise: si on s'attend à un traitement fait d'une certaine sorte, il ne faut pas qu'il soit fait autrement en fonction du bon vouloir d'un développeur. Exemple: si tous les flux sont traités en TCP, il ne faut pas qu'un flux équivalent soit traité en UDP. (c'est gros, mais c'est pour illustrer mes propos)

[Nebulix]

Et tu fais comment quand ton cahier des charges ne te dis pas quoi faire ? Il y a 1001 façon interpréter un cahier des charges si celui-ci n'est pas "bon", et il n'a pas vocation à te donner les détails de codage suffisant pour n'avoir qu'à appliquer. Sinon ça fait déjà longtemps qu'on aurait automatisé le codage depuis le cahier des charges.

Ceux qui disent qu'un bon code n'est que le respect du cahier des charges, pour moi, ne cherchent pas à faire un bon code, mais à déléguer leur responsabilité au rédacteur du cahier : "j'ai respecté le CdC, donc si c'est pas bon c'est pas ma faute, c'est le CdC qui a été mal fait.".

A rapprocher du fait divers récent :
"Le chauffeur d’un autocar belge s’est trompé en entrant sa destination sur son GPS et s'est retrouvé à La Plagne en Ariège, dans les Pyrénées, alors que son point de chute était la station de ski du même nom mais dans les Alpes, en Savoie !
Un détour de quelque 1200 kilomètres."

[marsupial]

Lorsque la sécurité pour 2015 est la priorité de 85% des DSI à travers le monde devant la mobilité, ce qui n'est pas rien, personne n'a songé à sécuriser ?