Pour en revenir au C/C++, si l'on code un logiciel en utilisant directement des fonctions des bibliothèques systèmes ou standards, il est indispensable d'écrire des tests unitaires. Si on appelle, par exemple, la fonction 'memcpy()', il est nécessaire de s'assurer, par ces tests, 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' en production ou, pire, un comportement erratique de l'application, dont il sera très difficile de diagnostiquer l'origine, et donc d'y apporter les corrections nécessaires.
Dans mon cas, je ne fais jamais appel directement à des fonctions des bibliothèques standards ou systèmes. J'utilise un framework maison qui, lui, utilise bien entendu ces fonctions. Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation, dont celles qui pourraient mener à un appel à des fonctions comme 'memcpy()' avec des paramètres incohérents, soit détectées et signalées. Ainsi, même des cas de figure qui mènerait à un appel à une fonction comme 'memcpy()' avec des paramètres corrects, mais algorithmiquement faux, sont détectés et signalés.
Ce framework est utilisé dans toutes mes programmes. Personnellement, j'utilise quotidiennement plusieurs outils, basés sur ce framework, que j'ai développés, ce qui fait que je détecte les éventuels problèmes du framework bien avant qu'ils n’apparaissent chez les utilisateurs de mes logiciels. De ce fait, à l'usage, ce framework se révèle extrêmement fiable.
Je ne sais pas si c'est cela qui fait la différence, mais, à ton expérience sur un projet mené sans écrire de tests, avec, pour conséquence, d’après tes dires, une augmentation des coûts, je ne peux que t'opposer mon expérience concernant l'ensemble des mes programmes, que j'ai développé sans écrire de tests unitaires, et qui ne présentent qu’extrêmement rarement des bugs une fois en production. Et si bugs il y a, leur correction est presque toujours triviale.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1. Dernière modification le 20 juillet 2013 à 11:26.
Pour en revenir au C/C++, si l'on code un logiciel en utilisant directement des fonctions des bibliothèques systèmes ou standards, il est indispensable d'écrire des tests unitaires. Si on appelle, par exemple, la fonction 'memcpy()', il est nécessaire de s'assurer, par ces tests, 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' en production ou, pire, un comportement erratique de l'application, dont il sera très difficile de diagnostiquer l'origine, et donc d'y apporter les corrections nécessaires.
Dans mon cas, je ne fais jamais appel directement à des fonctions des bibliothèques standards ou systèmes. J'utilise un framework maison qui, lui, utilise bien entendu ces fonctions. Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation, dont celles qui pourraient mener à un appel à des fonctions comme 'memcpy()' avec des paramètres incohérents, soit détectées et signalées. Ainsi, même des cas de figure qui mènerait à un appel à une fonction comme 'memcpy()' avec des paramètres corrects, mais algorithmiquement faux, sont détectés et signalés.
Ce framework est utilisé dans toutes mes programmes. Personnellement, j'utilise quotidiennement plusieurs outils, basés sur ce framework, que j'ai développés, ce qui fait que je détecte les éventuels problèmes du framework bien avant qu'ils n’apparaissent chez les utilisateurs de mes logiciels. De ce fait, à l'usage, ce framework se révèle extrêmement fiable.
Je ne sais pas si c'est cela qui fait la différence, mais, à ton expérience sur un projet mené sans écrire de tests, avec, pour conséquence, d’après tes dires, une augmentation des coûts, je ne peux que t'opposer mon expérience concernant l'ensemble des mes programmes, que j'ai développé sans écrire de tests unitaires, et qui ne présentent qu’extrêmement rarement des bugs une fois en production. Et si bugs il y a, leur correction est presque toujours triviale.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...