A mon humble avis, le point le plus important n'est pas le résultat final, mais tout ce qui s'est passé depuis l'écriture de la première ligne.
Il y a par exemple :
- Le type qui a passé 2 ans à faire un cahier des charges, a modélisé des machins en merise, fait des dessins dans tous les sens, et possède sur papier le détail de chaque classe et de chaque fonction à implémenter. Le premier truc concret qu'il va probablement faire est d'écrire tous les prototypes. Le remplissage avec du code viendra bien après, et la structure (théoriquement) ne changera jamais sans repasser par la case départ.
- Le type qui écrit un truc infect qui fonctionne 10 minutes après, mais avec toutes les valeurs en dur, aucune gestion d'erreur, aucune précaution liée à la sécurité, aucun effort de portabilité, etc. Ces détails seront éventuellement ajoutés bien plus tard, lorsque l'application fonctionnera.
- Le type qui va au contraire toujours prévoir tous les cas de figure possible. Par exemple pour effectuer une simple requete SQL, il va prendre soin de quoter absolument tout, y compris les nombres (on sait jamais, des fois que plus tard, on change le nombre par autre chose), il va systématiquement utiliser des transactions, réessayer plusieurs fois en cas d'erreur, ajouter un cache et des délais exponentiels pour éviter un effet zeno, considérer que n'importe quelle fonction de la libc peut etre bogguée ou ne pas fonctionner exactement comme documentée, etc. Résultat : il va falloir beaucoup plus de temps que le type précédent pour avoir un code "ou y a quelque chose à voir". Mais une fois le truc en prod, il n'aura jamais à s'excuser ("ah euh, ouais, c'est normal, c'est parce qu'il n'y avait plus de place sur le disque") .
- Le type qui suit à la ligne un modèle qu'on lui a enseigné ou qu'il a lu dans un bouquin.
- Le type qui fait un patchwork avec des bouts de code repiqués de-ci, de-là, en y ajoutant des rustines pour qu'ils cohabitent.
# Re: Critères de personnalité d'un code
Posté par j . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 2.
Il y a par exemple :
- Le type qui a passé 2 ans à faire un cahier des charges, a modélisé des machins en merise, fait des dessins dans tous les sens, et possède sur papier le détail de chaque classe et de chaque fonction à implémenter. Le premier truc concret qu'il va probablement faire est d'écrire tous les prototypes. Le remplissage avec du code viendra bien après, et la structure (théoriquement) ne changera jamais sans repasser par la case départ.
- Le type qui écrit un truc infect qui fonctionne 10 minutes après, mais avec toutes les valeurs en dur, aucune gestion d'erreur, aucune précaution liée à la sécurité, aucun effort de portabilité, etc. Ces détails seront éventuellement ajoutés bien plus tard, lorsque l'application fonctionnera.
- Le type qui va au contraire toujours prévoir tous les cas de figure possible. Par exemple pour effectuer une simple requete SQL, il va prendre soin de quoter absolument tout, y compris les nombres (on sait jamais, des fois que plus tard, on change le nombre par autre chose), il va systématiquement utiliser des transactions, réessayer plusieurs fois en cas d'erreur, ajouter un cache et des délais exponentiels pour éviter un effet zeno, considérer que n'importe quelle fonction de la libc peut etre bogguée ou ne pas fonctionner exactement comme documentée, etc. Résultat : il va falloir beaucoup plus de temps que le type précédent pour avoir un code "ou y a quelque chose à voir". Mais une fois le truc en prod, il n'aura jamais à s'excuser ("ah euh, ouais, c'est normal, c'est parce qu'il n'y avait plus de place sur le disque") .
- Le type qui suit à la ligne un modèle qu'on lui a enseigné ou qu'il a lu dans un bouquin.
- Le type qui fait un patchwork avec des bouts de code repiqués de-ci, de-là, en y ajoutant des rustines pour qu'ils cohabitent.
etc.