que les paramètres passés à cette fonction, quelles que soient les circonstances, soient toujours cohérents, sous peine de se retrouver avec un 'segfault'
(...)
Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation (...) soit détectées et signalées.
Je ne vois pas ce que ça change. Que ça segfault ou que ça remonte une exception non-catchée, d'un point de vue fonctionnel, le problème est le même : le programme est buggué. Lever une exception au lieu de segfaulter n'excuse en rien l'absence de tests.
Vu que tu as ton framework maison, tu le connais par coeur. Tu connais ses points forts et ses points faibles. Tu sais de quel façon il est sensé être utilisé et du coup tu l'utilises toujours correctement. Au final, quand je lis ton post, j'ai l'impression que la fiabilité de tes programmes ne tient qu'à ça.
Est-ce que quelqu'un d'autre a déjà utilisé avec autant de succès ton framework ? Est-ce que quelqu'un a déjà fait des modifications importantes dans ton code sans causer de régression ?
Aussi est-ce que tu as déjà développé un programme en équipe ? Je veux dire à plusieurs sur un même programme ou librairie (et je ne parle pas de pair-programming). D'après mon expérience, dans cette situation, comme chacun ne sait jamais précisément ce que l'autre a codé, les tests fonctionnels et unitaires sont le seul moyen efficace d'éviter des régressions.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 5.
Je ne vois pas ce que ça change. Que ça segfault ou que ça remonte une exception non-catchée, d'un point de vue fonctionnel, le problème est le même : le programme est buggué. Lever une exception au lieu de segfaulter n'excuse en rien l'absence de tests.
Vu que tu as ton framework maison, tu le connais par coeur. Tu connais ses points forts et ses points faibles. Tu sais de quel façon il est sensé être utilisé et du coup tu l'utilises toujours correctement. Au final, quand je lis ton post, j'ai l'impression que la fiabilité de tes programmes ne tient qu'à ça.
Est-ce que quelqu'un d'autre a déjà utilisé avec autant de succès ton framework ? Est-ce que quelqu'un a déjà fait des modifications importantes dans ton code sans causer de régression ?
Aussi est-ce que tu as déjà développé un programme en équipe ? Je veux dire à plusieurs sur un même programme ou librairie (et je ne parle pas de pair-programming). D'après mon expérience, dans cette situation, comme chacun ne sait jamais précisément ce que l'autre a codé, les tests fonctionnels et unitaires sont le seul moyen efficace d'éviter des régressions.