Pour le 3), je veux bien des explications. Que les tests ne se déroulent pas de la même manière, je le conçois. Que cela soit "moins testable"...
Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,... Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.
Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.
Pour le 2), il est lié au 1). C'est un problème uniquement si le choix initial est mauvais.
Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.
Pour le C, rien à voir. Au contraire, j'aurais plutôt tendance à dire que cela ralenti les livraisons !
Avoir plus de tests et un feedback rapide, ça ralenti ?
un coût financier tout d'abord, par le temps supplémentaire nécessaire pour les développements ;
je suis pas certains que ça prenne plus de temps
tu maîtrise mieux ton langage de base que le langage de ton bd (tu écris plus de code avec le premier)
tu as une boucle de feedback plus rapide (test unitaire vs test d'intégration) donc ça te fais aller plus vite
un coût technique, dû au surcoût (processeur, ram, etc...) lié à l'utilisation massive d'adapteurs
C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.
Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3. Dernière modification le 16 mars 2016 à 14:44.
Tu pars d'une hypothèse « j'ai fais un bon choix dès le départ » et je ne vois pas comment tu peux l'affirmer.
Je peux ajouter d'autres ressources de gens qui affirment la même chose : https://www.thoughtworks.com/talks/agile-architecture-rethink-2014 et qui ne font pas parti d'une SS2I (Martin Fowler c'est déjà un peu plus respectable ?)
Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,... Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.
Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.
Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.
Avoir plus de tests et un feedback rapide, ça ralenti ?
C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.
Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)