WEBVTT

1
00:00:00.353 --> 00:00:02.820
Bonjour et bienvenue à l'Ancière Académie,

2
00:00:03.141 --> 00:00:06.852
le podcast dédié à l'ingénierie logicielle et au software Craftsmanship.

3
00:00:07.753 --> 00:00:08.595
Avant de commencer,

4
00:00:08.796 --> 00:00:14.132
n'hésite pas à t'abonner et à me suivre sur LinkedIn pour recevoir régulièrement du contenu sur la programmation,

5
00:00:14.452 --> 00:00:15.558
l'architecture logicielle,

6
00:00:15.860 --> 00:00:17.892
les tests automatisés et bien plus encore.

7
00:00:18.693 --> 00:00:18.997
Sur ce,

8
00:00:19.604 --> 00:00:20.110
bonne émission !

9
00:00:22.128 --> 00:00:23.089
Salut à toutes et à tous,

10
00:00:23.410 --> 00:00:24.511
j'espère que vous allez bien,

11
00:00:25.031 --> 00:00:28.835
et aujourd'hui un petit podcast en réaction et non pas en réponse,

12
00:00:28.915 --> 00:00:33.380
en réaction au podcast de Mathieu Calahoui qui s'appelle Hands-On Podcast,

13
00:00:33.840 --> 00:00:39.166
dans lequel il a invité plusieurs développeurs à discuter de sujets très intéressants,

14
00:00:39.406 --> 00:00:41.328
notamment celui de la qualité logicielle.

15
00:00:41.549 --> 00:00:43.718
Et pratiquement dès le début du podcast,

16
00:00:44.320 --> 00:00:46.328
il pose une question extrêmement intéressante qui est...

17
00:00:47.421 --> 00:00:53.798
Doit-on nécessairement avoir des tests et mettre en place une clean architecture et du clean code pour avoir un logiciel de bonne qualité ?

18
00:00:54.600 --> 00:00:55.465
Et en une seule question,

19
00:00:55.566 --> 00:00:55.888
pour moi,

20
00:00:56.754 --> 00:00:57.740
il en a posé plusieurs.

21
00:00:58.120 --> 00:00:59.165
Et je pense que déjà,

22
00:00:59.566 --> 00:01:02.680
se mettre d'accord sur ce qu'est la qualité logicielle est extrêmement important.

23
00:01:03.220 --> 00:01:03.683
Et ensuite,

24
00:01:03.743 --> 00:01:06.900
faire le rapprochement entre les pratiques qu'il a énoncées et celles qui suivent,

25
00:01:07.080 --> 00:01:09.280
d'une manière générale ce qu'on appelle les pratiques craft,

26
00:01:10.281 --> 00:01:13.918
voir s'il y a un rapprochement à faire entre la qualité logicielle et ces pratiques-là.

27
00:01:14.320 --> 00:01:16.720
Et la réponse n'est pas forcément évidente.

28
00:01:17.542 --> 00:01:20.276
Et il y a pour moi une réponse extrêmement pertinente,

29
00:01:20.956 --> 00:01:22.956
qui est la base de tout ce que je vais dire dans ce podcast-là,

30
00:01:23.116 --> 00:01:25.136
je ne sais plus lequel des participants l'a donné,

31
00:01:26.177 --> 00:01:26.763
mais il a dit...

32
00:01:27.693 --> 00:01:31.707
Tu as un logiciel de bonne qualité si tu arrives tous les jours à déployer,

33
00:01:31.707 --> 00:01:33.312
si tu arrives régulièrement à déployer.

34
00:01:33.352 --> 00:01:34.838
Moi j'aime bien le principe de tous les jours,

35
00:01:34.858 --> 00:01:38.572
pour moi on devrait être capable de déployer même plusieurs fois par jour.

36
00:01:38.892 --> 00:01:42.272
Et ça pour moi c'est vraiment l'heuristique la plus importante.

37
00:01:42.852 --> 00:01:47.452
C'est à dire que moi en tant que développeur qui se revendique comme étant hardcore agile,

38
00:01:48.333 --> 00:01:49.296
Le plus important,

39
00:01:49.357 --> 00:01:52.248
c'est de pouvoir avoir le feedback le plus rapide possible,

40
00:01:52.388 --> 00:01:55.608
que ce soit avec mes clients ou que ce soit pour les clients de mes clients.

41
00:01:56.128 --> 00:01:56.451
Le but,

42
00:01:56.471 --> 00:01:58.768
c'est d'avoir un retour sur le logiciel que j'ai produit,

43
00:01:59.248 --> 00:02:00.979
sur la valeur ajoutée de ce logiciel,

44
00:02:01.422 --> 00:02:02.408
le plus rapidement possible.

45
00:02:03.008 --> 00:02:07.468
Toutes les pratiques que j'applique derrière ont pour but de servir ce but-là.

46
00:02:07.910 --> 00:02:12.148
Je n'appliquerai jamais une pratique qui irait à l'encontre de cet objectif.

47
00:02:12.668 --> 00:02:13.011
Donc du coup,

48
00:02:13.051 --> 00:02:13.373
pour moi,

49
00:02:13.555 --> 00:02:15.328
c'est de maintenir cette vélocité.

50
00:02:15.873 --> 00:02:21.544
et de maintenir ma capacité à rapidement rajouter de la valeur sur un logiciel existant dans le temps,

51
00:02:21.824 --> 00:02:25.892
sans avoir le problème que l'on a aujourd'hui avec pratiquement tous les logiciels,

52
00:02:26.412 --> 00:02:34.952
sans avoir ce problème de dette technique qui s'accumule avec le temps et qui fait que d'abord on arrive à déployer une fois par jour et puis une fois par semaine et puis une fois toutes les deux semaines,

53
00:02:35.253 --> 00:02:44.632
puis une fois par mois et qu'après on doit faire des synchronisations entre les différentes équipes parce qu'on doit sortir la version de l'API en même temps que le front ou la version de l'application mobile en même temps que l'API.

54
00:02:45.123 --> 00:02:45.267
Donc...

55
00:02:45.831 --> 00:02:52.668
Tous ces effets-là sont des conséquences pour moi d'une application qui a été mal conçue et dont la qualité est mauvaise.

56
00:02:53.168 --> 00:02:55.288
Donc ça rejoint exactement ma vision des choses.

57
00:02:55.368 --> 00:03:00.768
On a un logiciel de bonne qualité si on arrive à produire de la valeur au quotidien.

58
00:03:00.908 --> 00:03:01.334
Là-dessus,

59
00:03:01.354 --> 00:03:02.508
on est parfaitement d'accord.

60
00:03:03.567 --> 00:03:08.664
Et donc maintenant qu'on a une heuristique qui nous permet de savoir si oui ou non on a du code de bonne qualité,

61
00:03:09.184 --> 00:03:14.584
il nous reste à savoir qu'est-ce que du code de bonne qualité et comment produire un code de bonne qualité.

62
00:03:15.084 --> 00:03:17.864
Et c'est sur ces points-là que l'on va avoir énormément de désaccords.

63
00:03:17.864 --> 00:03:20.495
Et la première chose qui va me choquer de la part de,

64
00:03:20.696 --> 00:03:21.178
une fois de plus,

65
00:03:21.298 --> 00:03:22.724
je ne sais plus lequel des intervenants,

66
00:03:22.784 --> 00:03:26.784
de toute façon le but ce n'est pas de faire des attaques à nominés ou de nommer des responsables,

67
00:03:28.287 --> 00:03:32.144
ce qui va beaucoup me gêner c'est cette réponse dans laquelle l'un des intervenants dit

68
00:03:32.885 --> 00:03:36.220
que les tests ne sont pas nécessaires à une bonne qualité logicielle,

69
00:03:36.320 --> 00:03:39.420
que la clean architecture n'est pas nécessaire à une bonne qualité logicielle.

70
00:03:40.201 --> 00:03:40.442
Déjà,

71
00:03:40.523 --> 00:03:41.469
pour la clean architecture,

72
00:03:42.153 --> 00:03:43.280
je suis moyennement d'accord,

73
00:03:43.800 --> 00:03:45.552
car une architecture qui est testable,

74
00:03:45.875 --> 00:03:46.560
par définition,

75
00:03:46.960 --> 00:03:48.340
suit les principes de la clean architecture.

76
00:03:48.860 --> 00:03:49.082
En fait,

77
00:03:49.082 --> 00:03:50.109
c'est un mot,

78
00:03:50.109 --> 00:03:53.780
on en parlait aussi avec Michael Hazerath sur LinkedIn dernièrement en privé,

79
00:03:54.263 --> 00:03:55.228
c'est que finalement,

80
00:03:55.852 --> 00:03:56.515
dans son cœur,

81
00:03:56.616 --> 00:03:57.340
la clean architecture,

82
00:03:57.988 --> 00:03:59.614
c'est l'inversion de dépendance,

83
00:03:59.915 --> 00:04:01.259
c'est l'architecture hexagonale,

84
00:04:01.279 --> 00:04:02.624
c'est exactement ce même principe-là.

85
00:04:03.185 --> 00:04:06.544
D'inverser les dépendances pour pouvoir remplacer ces dépendances,

86
00:04:06.604 --> 00:04:08.036
que l'on soit dans un environnement de test,

87
00:04:08.076 --> 00:04:09.024
un environnement de production,

88
00:04:09.464 --> 00:04:13.524
ou tout simplement si on a envie de tester différents types de dépendances de production.

89
00:04:14.024 --> 00:04:14.787
Donc déjà,

90
00:04:15.390 --> 00:04:16.193
sans Clean Architecture,

91
00:04:16.193 --> 00:04:18.624
en tout cas sans le principe fondateur de la Clean Architecture,

92
00:04:18.786 --> 00:04:20.304
c'est-à-dire l'inversion de dépendance,

93
00:04:21.041 --> 00:04:22.452
C'est compliqué de tester son code.

94
00:04:22.612 --> 00:04:24.652
Il faut écrire des tests d'intégration à tout bout de champ.

95
00:04:25.152 --> 00:04:26.792
Donc ça reste faisable.

96
00:04:27.474 --> 00:04:33.332
Il me semble qu'il y a pas mal d'applications industrielles qui ont très peu de tests unitaires et beaucoup de tests d'intégration.

97
00:04:33.793 --> 00:04:35.432
Ça permet de maintenir une bonne qualité.

98
00:04:36.553 --> 00:04:39.012
Mais on se retrouve avec une qualité questionnable.

99
00:04:40.228 --> 00:04:40.570
Pourquoi ?

100
00:04:41.072 --> 00:04:44.687
Naturellement parce que ces tests d'intégration là sont beaucoup plus lents à tester,

101
00:04:45.068 --> 00:04:48.383
donc ça devient beaucoup plus difficile de tester tous les cas possibles,

102
00:04:48.504 --> 00:04:50.861
tous les différents chemins que peut emprunter le code.

103
00:04:51.365 --> 00:04:54.791
Ces tests là nécessitent d'avoir en place une base de données ou un système de fichiers ou autre.

104
00:04:55.464 --> 00:04:59.362
Donc du coup ça devient moins intéressant de les lancer vu qu'ils prennent beaucoup de temps à être lancés.

105
00:04:59.745 --> 00:05:04.383
Donc du coup ils sont moins utilisés et donc du coup on a moins de possibilités,

106
00:05:04.403 --> 00:05:07.924
c'est moins agréable de travailler sur la qualité du logiciel en lui-même.

107
00:05:07.924 --> 00:05:08.224
Donc c'est ça.

108
00:05:08.349 --> 00:05:09.274
C'est beaucoup plus pénible,

109
00:05:09.334 --> 00:05:11.504
tandis que si on avait des tests véritablement unitaires,

110
00:05:12.004 --> 00:05:17.004
par exemple j'ai cité dernièrement le cas de GCC qui a une batterie de 300 000 tests,

111
00:05:17.404 --> 00:05:22.504
donc GCC c'est la suite de compilation de GNU Linux pour compiler du C.

112
00:05:23.507 --> 00:05:25.272
Ils ont à peu près 300 000 tests,

113
00:05:25.914 --> 00:05:27.759
je n'en doute pas qu'il y a une grande partie de ces tests,

114
00:05:27.759 --> 00:05:29.684
voire la majeure partie de ces tests qui sont des tests unitaires,

115
00:05:30.224 --> 00:05:32.144
ce qui fait que le développement est extrêmement simple.

116
00:05:32.204 --> 00:05:34.552
Dès que je vais modifier un morceau de code quelque part,

117
00:05:34.773 --> 00:05:35.997
je vais peut-être avoir une centaine,

118
00:05:36.117 --> 00:05:38.244
plusieurs milliers de tests qui vont se lancer instantanément,

119
00:05:38.344 --> 00:05:39.973
qui vont s'exécuter en une seule seconde,

120
00:05:40.315 --> 00:05:41.904
et je vais avoir un retour immédiat.

121
00:05:42.004 --> 00:05:48.524
Et ce retour immédiat-là va me permettre de travailler dans une boucle de feedback dans laquelle je vais pouvoir continuellement mettre à jour mon code.

122
00:05:48.872 --> 00:05:50.584
le refactoriser et améliorer sa qualité.

123
00:05:51.064 --> 00:05:52.644
Ce que l'on n'a pas avec des tests d'intégration,

124
00:05:52.804 --> 00:05:54.009
parce que ces tests-là peuvent mettre

125
00:05:54.572 --> 00:05:55.335
30 secondes,

126
00:05:55.396 --> 00:05:55.817
1 minute,

127
00:05:55.878 --> 00:05:56.300
5 minutes,

128
00:05:56.380 --> 00:05:57.284
10 minutes à se lancer,

129
00:05:57.824 --> 00:06:00.444
vous imaginez qu'on ne peut pas avoir des petites itérations,

130
00:06:00.904 --> 00:06:02.336
de quelques modifications,

131
00:06:02.478 --> 00:06:03.204
de quelques lignes,

132
00:06:03.284 --> 00:06:04.844
parce qu'on a du véritable refactoring,

133
00:06:05.244 --> 00:06:08.319
lorsqu'on a une boucle de feedback qui dépasse les 30 secondes,

134
00:06:08.319 --> 00:06:08.801
la minute,

135
00:06:08.801 --> 00:06:09.223
les 10 minutes,

136
00:06:09.223 --> 00:06:09.343
etc.

137
00:06:10.105 --> 00:06:11.053
Donc déjà,

138
00:06:11.517 --> 00:06:12.304
sans clean architecture,

139
00:06:12.724 --> 00:06:14.944
c'est difficile de maintenir une bonne qualité logicielle,

140
00:06:15.025 --> 00:06:16.604
car cela implique que si l'on a des tests,

141
00:06:17.017 --> 00:06:19.992
Ce sont nécessairement en grande partie des tests d'intégration.

142
00:06:20.514 --> 00:06:25.031
Par contre à la question peut-on avoir une bonne qualité logicielle sans test tout court,

143
00:06:26.208 --> 00:06:26.372
non.

144
00:06:26.412 --> 00:06:28.083
Clairement pour moi la question ne se pose même pas,

145
00:06:28.123 --> 00:06:29.532
c'est tout simplement impossible.

146
00:06:30.094 --> 00:06:37.429
Les tests apportent une valeur tellement incroyable et tellement nécessaire à la maintenance d'une qualité logicielle.

147
00:06:38.696 --> 00:06:41.612
que l'on ne peut pas avoir un logiciel de bonne qualité sans test.

148
00:06:42.073 --> 00:06:44.111
D'autant plus que la plupart des logiciels que l'on développe,

149
00:06:44.392 --> 00:06:45.582
ça va être des applications web,

150
00:06:45.582 --> 00:06:46.449
des applications mobiles,

151
00:06:46.469 --> 00:06:46.590
etc.,

152
00:06:46.953 --> 00:06:49.452
sont des applications qui vont avoir une longue durée de vie.

153
00:06:49.752 --> 00:06:50.839
On va les développer aujourd'hui,

154
00:06:51.222 --> 00:06:52.752
il y a de grandes chances que dans 3 ans,

155
00:06:52.872 --> 00:06:53.377
dans 5 ans,

156
00:06:53.377 --> 00:06:53.841
dans 10 ans,

157
00:06:53.841 --> 00:06:57.186
ces logiciels existent toujours et soient encore développés et maintenus,

158
00:06:57.206 --> 00:06:58.052
soient encore actifs.

159
00:06:58.512 --> 00:07:01.352
Et pour comprendre la nécessité des tests à une bonne qualité logicielle,

160
00:07:01.892 --> 00:07:05.712
il faut comprendre déjà comment est-ce qu'on arrive à avoir un logiciel de mauvaise qualité.

161
00:07:05.893 --> 00:07:06.196
D'abord,

162
00:07:06.479 --> 00:07:07.831
qu'est-ce qu'un logiciel de bonne qualité ?

163
00:07:08.359 --> 00:07:08.785
Donc déjà...

164
00:07:09.472 --> 00:07:13.308
Il faut différencier le logiciel de bonne qualité et le code source de bonne qualité.

165
00:07:13.448 --> 00:07:15.508
Je pense que c'est extrêmement important de différencier les deux.

166
00:07:15.988 --> 00:07:17.215
Un logiciel de bonne qualité,

167
00:07:17.275 --> 00:07:19.728
c'est un logiciel qui fonctionne d'un point de vue de l'utilisateur,

168
00:07:19.848 --> 00:07:21.113
qui va utiliser l'application,

169
00:07:21.475 --> 00:07:33.148
tandis qu'un code source de bonne qualité va concerner les développeurs qui travaillent régulièrement dessus et va concerner leur facilité et la flexibilité de ce code-là à être modifié pour s'adapter à de nouveaux besoins.

170
00:07:33.268 --> 00:07:33.552
Pour moi,

171
00:07:33.552 --> 00:07:34.648
c'est ça la qualité logicielle.

172
00:07:34.809 --> 00:07:36.217
Ou plutôt la qualité du code source,

173
00:07:36.237 --> 00:07:38.268
mais c'est ce que l'on va appeler qualité logicielle.

174
00:07:39.033 --> 00:07:39.780
dans ce podcast-là.

175
00:07:40.265 --> 00:07:41.180
C'est de ça dont on va parler.

176
00:07:41.540 --> 00:07:43.800
La qualité de l'exécutable en lui-même,

177
00:07:43.940 --> 00:07:45.080
c'est encore un autre sujet.

178
00:07:45.520 --> 00:07:50.220
Il y a généralement une très bonne corrélation entre qualité du code source et qualité logicielle,

179
00:07:50.722 --> 00:07:51.780
mais c'est pas ça dont on va parler.

180
00:07:51.940 --> 00:07:52.142
Et donc,

181
00:07:52.203 --> 00:07:55.677
comment est-ce qu'on en vient à avoir une dégradation de cette qualité logicielle ?

182
00:07:56.080 --> 00:07:56.242
Eh bien,

183
00:07:56.262 --> 00:07:56.810
tout simplement,

184
00:07:56.830 --> 00:07:58.839
au fur et à mesure qu'on travaille sur ce logiciel,

185
00:07:59.401 --> 00:08:03.400
on va avoir des retours et on va se rendre compte que ce que l'on pensait être la vérité,

186
00:08:03.520 --> 00:08:05.520
ce que l'on pensait que le logiciel devait faire,

187
00:08:06.202 --> 00:08:08.676
est différent de ce que le logiciel doit faire en réalité.

188
00:08:08.876 --> 00:08:09.277
Premièrement,

189
00:08:09.779 --> 00:08:14.656
soit parce qu'on n'a pas très bien compris ce qu'il fallait faire dans la définition de ce logiciel,

190
00:08:15.116 --> 00:08:17.389
soit parce que tout simplement le logiciel a évolué,

191
00:08:17.469 --> 00:08:18.676
on a de nouveaux besoins,

192
00:08:18.796 --> 00:08:21.376
il faut adapter le code existant à ces nouveaux besoins-là,

193
00:08:21.496 --> 00:08:23.976
et donc nécessairement il faut modifier le code qui est en place.

194
00:08:24.498 --> 00:08:25.444
Et c'est à ce moment-là,

195
00:08:25.504 --> 00:08:27.296
lorsque l'on va modifier le code existant,

196
00:08:27.376 --> 00:08:29.076
que l'on va introduire de la complexité,

197
00:08:29.476 --> 00:08:32.170
que l'on va rajouter de plus en plus de cas de spécification,

198
00:08:32.210 --> 00:08:33.436
de plus en plus de cas à gérer.

199
00:08:33.784 --> 00:08:38.060
et que l'on risque de complexifier le logiciel sans modifier son design,

200
00:08:38.160 --> 00:08:41.060
sans adapter en fait le design de ce code-là aux nouveaux besoins.

201
00:08:41.260 --> 00:08:44.720
Et c'est à ce moment-là que l'on arrive à avoir des classes qui font beaucoup trop de choses,

202
00:08:44.800 --> 00:08:45.565
ou avoir des fonctions,

203
00:08:45.847 --> 00:08:47.820
ou avoir des fichiers qui font beaucoup trop de choses,

204
00:08:48.281 --> 00:08:51.960
parce qu'on a gardé l'ancien design et qu'on a ajouté de nouvelles fonctionnalités dessus,

205
00:08:52.261 --> 00:08:53.598
sans l'adapter aux nouveaux besoins.

206
00:08:53.901 --> 00:08:55.266
Et donc c'est là en général,

207
00:08:55.386 --> 00:08:59.140
lorsque le nouveau besoin arrive et que l'on a besoin de modifier du code existant,

208
00:08:59.638 --> 00:09:01.912
que l'on va se poser la question du refactoring.

209
00:09:02.112 --> 00:09:05.012
Est-ce que le code qui existe actuellement est suffisant,

210
00:09:05.112 --> 00:09:06.507
est adapté à ce nouveau besoin-là ?

211
00:09:07.012 --> 00:09:09.909
Est-ce que je peux juste rajouter quelques lignes et ça fonctionnera très très bien ?

212
00:09:10.372 --> 00:09:19.511
Ou est-ce qu'il y a besoin de redesigner ce morceau de code-là pour l'adapter à ce nouveau besoin et potentiellement aux besoins similaires qui pourraient arriver dans l'avenir ?

213
00:09:19.612 --> 00:09:22.092
Parce que lorsque l'on parle de design et de refactoring,

214
00:09:22.232 --> 00:09:22.796
nécessairement,

215
00:09:23.199 --> 00:09:24.912
on anticipe un certain futur.

216
00:09:25.433 --> 00:09:26.237
Mais pas trop loin,

217
00:09:26.358 --> 00:09:28.267
parce que sinon on peut tomber dans ce qu'on appelle le Yagni,

218
00:09:28.287 --> 00:09:29.367
le You're not gonna need it.

219
00:09:29.851 --> 00:09:32.648
Donc c'est assez délicat de trouver le bon équilibre entre les deux.

220
00:09:33.385 --> 00:09:35.791
Et lorsque l'on va avoir besoin de faire du refactoring,

221
00:09:35.911 --> 00:09:37.715
on va avoir besoin d'une méthode,

222
00:09:37.815 --> 00:09:41.404
d'une solution qui nous permet de nous assurer que pendant ce refactoring-là,

223
00:09:41.524 --> 00:09:43.528
pendant que l'on modifie la structure,

224
00:09:43.528 --> 00:09:46.414
le design de notre code sans modifier son comportement,

225
00:09:46.795 --> 00:09:51.144
on a besoin d'une sécurité de s'assurer que notre code fonctionne toujours de la même façon.

226
00:09:51.624 --> 00:09:56.424
Et c'est là que les tests unitaires vont intervenir et même les tests d'intégration dans une certaine mesure.

227
00:09:56.825 --> 00:10:02.924
On aura une suite de tests qui va nous permettre de faire ce refactoring tout en gardant l'assurance que notre code fonctionne toujours.

228
00:10:03.192 --> 00:10:12.488
Et c'est ce refactoring là qui va nous permettre de maintenir un code adapté à notre besoin et ce sont ces tests là qui vont nous permettre de faire ce refactoring en toute quiétude.

229
00:10:13.008 --> 00:10:20.328
Donc le premier intérêt des tests est de nous faciliter cette phase de refactoring qui va nous permettre de continuellement améliorer la qualité logicielle.

230
00:10:21.180 --> 00:10:21.761
Deuxièmement,

231
00:10:22.102 --> 00:10:26.834
on peut parfois se rendre compte qu'une solution que l'on a développée à un problème n'est pas forcément très claire,

232
00:10:26.854 --> 00:10:28.097
n'est pas forcément très optimale.

233
00:10:28.852 --> 00:10:30.959
Et à ce moment là on va vouloir modifier ce code là,

234
00:10:30.959 --> 00:10:33.949
une fois de plus ça va être du refactoring voire carrément du redesign,

235
00:10:34.449 --> 00:10:41.029
et une fois de plus avoir ces tests là vont nous permettre de faire ces modifications tout en s'assurant que le code fonctionne toujours.

236
00:10:41.229 --> 00:10:45.549
Donc ça c'est la deuxième raison pour laquelle les tests sont nécessaires à une bonne qualité logicielle.

237
00:10:45.750 --> 00:10:48.384
Et enfin cette fois-ci on va parler de Test Driven Development,

238
00:10:48.464 --> 00:10:49.389
donc de TDD,

239
00:10:49.909 --> 00:10:54.323
qui est une pratique extrêmement intéressante cette fois-ci pour développer une feature,

240
00:10:54.343 --> 00:10:56.269
pour développer une solution dont on a besoin.

241
00:10:56.714 --> 00:10:57.948
Pourquoi est-ce que c'est intéressant ?

242
00:10:58.322 --> 00:10:59.044
Car le TDD,

243
00:10:59.344 --> 00:11:00.326
de par sa nature,

244
00:11:00.366 --> 00:11:05.177
va nous pousser à créer un bon design et à penser à un design qui soit testable,

245
00:11:05.297 --> 00:11:05.718
de base,

246
00:11:05.818 --> 00:11:07.181
avant même que l'on commence à développer.

247
00:11:07.601 --> 00:11:08.806
On va devoir penser à...

248
00:11:08.987 --> 00:11:09.710
Donc nécessairement,

249
00:11:09.710 --> 00:11:12.501
on va se poser la question de quels résultats est-ce que je vais obtenir,

250
00:11:12.681 --> 00:11:15.373
quelles doivent être les conséquences des différents appels,

251
00:11:15.373 --> 00:11:17.061
des différentes invocations que je vais faire.

252
00:11:17.381 --> 00:11:23.841
Donc on va vraiment penser en termes de contrat et on va devoir créer du code qui soit testable parce que le TDD se fait en test unitaire.

253
00:11:24.183 --> 00:11:27.641
Ce qui signifie que l'on va naturellement aboutir à une clean architecture.

254
00:11:28.249 --> 00:11:31.003
Et donc que vient faire le TDD dans la qualité logicielle ?

255
00:11:31.445 --> 00:11:34.068
Et bien tout simplement lorsque l'on a un problème complexe,

256
00:11:34.608 --> 00:11:50.025
avec le TDD on va pouvoir commencer à travailler sur une solution petit bout par petit bout en commençant par des cas très très génériques et petit à petit en allant dans des cas de plus en plus spécifiques jusqu'à aboutir à une implémentation complète.

257
00:11:50.326 --> 00:11:56.503
Et c'est ça l'avantage du TDD c'est que l'on peut attaquer le problème selon le dicton divide and conquer.

258
00:11:56.524 --> 00:11:57.045
On commence par...

259
00:11:57.730 --> 00:12:00.423
un petit problème et petit à petit un autre petit problème,

260
00:12:00.524 --> 00:12:00.644
etc.

261
00:12:01.426 --> 00:12:01.950
Et ensuite,

262
00:12:01.950 --> 00:12:02.353
à la fin,

263
00:12:02.393 --> 00:12:03.945
on a une solution qui est complète.

264
00:12:04.305 --> 00:12:06.505
Et en travaillant sur des petits morceaux de problèmes,

265
00:12:06.965 --> 00:12:10.393
on peut travailler sur des petits morceaux de code qui soient,

266
00:12:10.474 --> 00:12:10.595
eux,

267
00:12:10.595 --> 00:12:11.485
de très très bonne qualité.

268
00:12:11.625 --> 00:12:13.365
On va pouvoir faire du découpage de fonctions,

269
00:12:13.885 --> 00:12:15.201
appliquer des design patterns,

270
00:12:15.262 --> 00:12:15.383
etc.

271
00:12:16.507 --> 00:12:19.425
De telle sorte à avoir un programme de bonne qualité à la fin.

272
00:12:19.546 --> 00:12:19.788
Et donc,

273
00:12:19.869 --> 00:12:21.705
si vous appliquez rigoureusement le TDD,

274
00:12:22.025 --> 00:12:24.157
c'est-à-dire que vous écrivez un test,

275
00:12:24.700 --> 00:12:25.665
vous développez une solution,

276
00:12:26.197 --> 00:12:30.353
vous refactorisez le test et la solution petit à petit à mesure que vous évoluez,

277
00:12:30.953 --> 00:12:35.673
naturellement vous arrivez à un design de bonne qualité et à un code de bonne qualité.

278
00:12:35.833 --> 00:12:37.533
Et quand bien même ce ne serait pas le cas,

279
00:12:37.853 --> 00:12:40.433
parce que vous n'êtes peut-être pas forcément un développeur habitué au TDD,

280
00:12:40.673 --> 00:12:42.373
ou vous n'êtes pas forcément habitué au refactoring,

281
00:12:42.737 --> 00:12:43.991
ou la solution est complexe,

282
00:12:44.433 --> 00:12:48.093
ou vous ne maîtrisez pas nécessairement les bons design patterns pour cette solution-là,

283
00:12:48.613 --> 00:12:52.273
combien même vous avez une solution qui n'est pas forcément de très bonne qualité,

284
00:12:52.920 --> 00:12:53.567
vous avez...

285
00:12:53.833 --> 00:12:54.757
En conclusion,

286
00:12:54.918 --> 00:12:57.709
en side effect de cette façon de développer qu'est le TDD,

287
00:12:58.329 --> 00:13:01.749
des tests qui vont vous permettre de remodifier à nouveau ce code.

288
00:13:02.029 --> 00:13:05.829
Donc si par exemple vous avez un éclair de génie dans la nuit ou quelques jours après,

289
00:13:06.209 --> 00:13:09.549
ou si vous vous retrouvez avec un développeur qui a un meilleur niveau que vous,

290
00:13:10.172 --> 00:13:12.029
vous pouvez reprendre là où vous êtes arrêté,

291
00:13:12.109 --> 00:13:14.529
parce que vous avez en reliquat les tests que vous avez écrits,

292
00:13:15.129 --> 00:13:19.248
modifier ce code source là pour l'adapter à votre nouvelle compréhension de ce problème là.

293
00:13:19.722 --> 00:13:23.577
et graduellement améliorer la qualité logicielle en tout cas de cette partie là du code.

294
00:13:23.917 --> 00:13:29.997
C'est pour ça que pour moi d'ailleurs le TDD se pratique sur l'ensemble de l'application et pas juste sur une petite partie.

295
00:13:30.117 --> 00:13:33.757
On ne peut pas avoir un développeur qui bosse en TDD et d'autres développeurs qui ne bossent pas en TDD dessus.

296
00:13:34.278 --> 00:13:37.917
Tout simplement parce que lorsque derrière on va avoir besoin de reprendre ce code là,

297
00:13:38.397 --> 00:13:39.301
si on n'a pas les tests,

298
00:13:39.321 --> 00:13:43.117
comment est-ce qu'on va s'assurer que les modifications que l'on va faire sur ce code là fonctionnent toujours ?

299
00:13:43.137 --> 00:13:45.057
Eh bien soit on va devoir écrire des tests.

300
00:13:45.531 --> 00:13:48.325
qui vont essayer de comprendre le code qui a été écrit,

301
00:13:48.405 --> 00:13:50.105
de tester tous les cas possibles et imaginables,

302
00:13:50.185 --> 00:13:51.685
donc ce n'est pas forcément simple à faire.

303
00:13:52.285 --> 00:13:56.125
Soit on va devoir tester manuellement au fur et à mesure que l'on écrit notre code,

304
00:13:56.485 --> 00:13:59.805
donc du coup rajouter beaucoup de temps dans notre cycle de développement,

305
00:14:00.305 --> 00:14:03.225
et donc prendre moins de temps à améliorer la qualité du logiciel.

306
00:14:03.487 --> 00:14:04.090
Donc là aussi,

307
00:14:04.231 --> 00:14:06.345
une des raisons pour lesquelles les tests et le TDD,

308
00:14:06.925 --> 00:14:08.353
appliqués à une équipe entière,

309
00:14:08.614 --> 00:14:10.525
contribuent à la qualité du logiciel,

310
00:14:10.585 --> 00:14:11.028
et je dirais même,

311
00:14:11.089 --> 00:14:13.265
est nécessaire à une bonne qualité du logiciel.

312
00:14:13.585 --> 00:14:15.257
Et maintenant la question à 100 000 euros.

313
00:14:15.897 --> 00:14:17.304
Est-ce que toutes ces pratiques-là,

314
00:14:17.344 --> 00:14:18.389
la clean architecture,

315
00:14:18.389 --> 00:14:18.851
le TDD,

316
00:14:19.032 --> 00:14:19.796
l'écriture de tests,

317
00:14:19.796 --> 00:14:19.916
etc.

318
00:14:21.075 --> 00:14:28.149
va nécessairement rallonger le temps de développement et donc du coup impacter notre capacité à délivrer de la valeur jour après jour.

319
00:14:28.469 --> 00:14:32.589
Et c'est ça l'un des problèmes que j'ai eu avec une des réponses qui était donnée dans ce podcast.

320
00:14:33.229 --> 00:14:35.189
Je ne sais plus lequel des participants une fois de plus.

321
00:14:36.090 --> 00:14:41.909
Prends l'exemple d'un jeune développeur qui va coder une feature en une semaine sans appliquer de clean architecture ni quoi que ce soit,

322
00:14:42.389 --> 00:14:46.629
et un autre développeur qui va appliquer toutes les bonnes pratiques et lui va passer six mois à le faire.

323
00:14:47.202 --> 00:14:50.917
Donc c'est complètement irréaliste et je me prends moi-même comme exemple.

324
00:14:51.257 --> 00:14:55.637
J'ai souvent bossé avec des clients qui m'ont dit mais lève le piège à nous,

325
00:14:56.217 --> 00:14:57.786
comment fais-tu pour aller aussi vite ?

326
00:14:57.967 --> 00:14:59.536
Comment fais-tu pour développer aussi vite ?

327
00:14:59.797 --> 00:15:03.637
Les autres développeurs auraient mis trois mois de plus à développer ce que toi tu as fait.

328
00:15:03.917 --> 00:15:07.157
Donc déjà mon expérience personnelle me sert moi-même de preuve.

329
00:15:07.418 --> 00:15:15.117
Mais alors comment est-ce que je fais pour aller plus vite que d'autres développeurs qui eux n'appliquent pas toutes ces pratiques-là qui mettent pourtant factuellement plus de temps ?

330
00:15:15.953 --> 00:15:20.106
Et bien tout simplement parce que le développement logiciel c'est pas juste pondre du code,

331
00:15:20.286 --> 00:15:20.828
le livrer,

332
00:15:20.928 --> 00:15:21.450
fin de l'histoire.

333
00:15:21.890 --> 00:15:23.837
Le développement logiciel c'est pondre du code,

334
00:15:23.998 --> 00:15:24.560
le livrer,

335
00:15:24.841 --> 00:15:25.684
accueillir des feedbacks,

336
00:15:25.764 --> 00:15:26.467
modifier le code,

337
00:15:26.627 --> 00:15:27.069
relivrer,

338
00:15:27.129 --> 00:15:27.249
etc.

339
00:15:28.631 --> 00:15:37.010
Et là où moi j'aurais mis en place tout ce dont j'ai besoin pour faire mes modifications extrêmement rapidement et pour déployer dans le quart d'heure qui vient,

340
00:15:37.590 --> 00:15:40.861
un autre développeur qui n'a pas mis ça en place va devoir reprendre son code,

341
00:15:40.982 --> 00:15:41.644
le modifier,

342
00:15:41.764 --> 00:15:43.390
retester manuellement et redéployer.

343
00:15:43.968 --> 00:15:45.354
Imaginez ça sur 10,

344
00:15:45.495 --> 00:15:45.877
15,

345
00:15:45.977 --> 00:15:46.238
20,

346
00:15:46.359 --> 00:15:47.002
30 retours.

347
00:15:47.602 --> 00:15:48.742
Ça s'accumule très rapidement.

348
00:15:49.262 --> 00:15:51.576
Donc le temps que je peux perdre au début,

349
00:15:51.717 --> 00:15:52.562
entre guillemets perdre,

350
00:15:52.742 --> 00:15:59.142
plutôt le temps que je vais investir au début à me mettre en place tout ce dont j'ai besoin pour aller vite par la suite,

351
00:16:00.172 --> 00:16:03.086
je vais le rattraper largement après coup.

352
00:16:03.973 --> 00:16:04.966
Dès les deux premières semaines.

353
00:16:05.126 --> 00:16:05.550
Parce que moi,

354
00:16:05.813 --> 00:16:07.146
quand je travaille en agile,

355
00:16:07.506 --> 00:16:09.286
je déploie dès les deux premières semaines.

356
00:16:09.426 --> 00:16:10.434
Ça va dépendre du projet,

357
00:16:10.495 --> 00:16:11.846
ça peut être assez compliqué à estimer.

358
00:16:12.249 --> 00:16:13.206
Mais d'une manière générale,

359
00:16:13.566 --> 00:16:16.046
toujours le premier déploiement dans les deux premières semaines.

360
00:16:16.286 --> 00:16:16.771
Idéalement,

361
00:16:16.893 --> 00:16:18.186
même dans la première semaine.

362
00:16:18.746 --> 00:16:19.169
Et pour ça,

363
00:16:19.249 --> 00:16:21.926
ce qui est extrêmement important en tant que développeur,

364
00:16:22.490 --> 00:16:24.566
c'est de prendre notre place à nous.

365
00:16:25.279 --> 00:16:27.006
qui n'est pas seulement de créer,

366
00:16:27.006 --> 00:16:28.111
de produire du code,

367
00:16:28.111 --> 00:16:28.754
de programmer,

368
00:16:29.215 --> 00:16:30.854
mais de développer une feature.

369
00:16:31.295 --> 00:16:31.557
Vraiment,

370
00:16:31.818 --> 00:16:34.274
c'est très différent programmer et développer une feature.

371
00:16:34.794 --> 00:16:36.454
En tant que développeur d'une feature,

372
00:16:36.994 --> 00:16:37.902
lorsque un client,

373
00:16:37.902 --> 00:16:40.302
ou même si je fais partie d'une équipe et qu'il y a déjà un logiciel,

374
00:16:40.302 --> 00:16:41.410
il y a déjà un product owner,

375
00:16:41.430 --> 00:16:41.551
etc.,

376
00:16:42.117 --> 00:16:43.214
qui a déjà défini le besoin,

377
00:16:43.834 --> 00:16:46.434
peu importe qui va me demander de développer quelque chose,

378
00:16:46.834 --> 00:16:49.114
je vais nécessairement challenger ce besoin.

379
00:16:49.634 --> 00:16:49.736
Donc,

380
00:16:49.736 --> 00:16:50.813
dès qu'on a besoin de mettre...

381
00:16:50.996 --> 00:16:52.021
tout ça dès le début,

382
00:16:52.102 --> 00:16:53.589
est-ce que ça c'est vraiment nécessaire ?

383
00:16:53.690 --> 00:16:54.534
Est-ce que ce petit bout-là,

384
00:16:54.796 --> 00:16:55.559
cette petite sécurité,

385
00:16:55.781 --> 00:16:56.846
cette petite vérification,

386
00:16:56.886 --> 00:16:57.590
ce petit bonus-là,

387
00:16:57.990 --> 00:17:02.509
on a besoin de le sortir là directement en V1 ou est-ce que ça peut attendre un petit peu ?

388
00:17:02.810 --> 00:17:06.423
Et là on arrive à la jonction entre le craftsmanship,

389
00:17:06.884 --> 00:17:08.470
l'agilité et le lean.

390
00:17:08.750 --> 00:17:10.710
Parce que ça c'est exactement le lean dont je suis en train de parler.

391
00:17:11.292 --> 00:17:16.910
C'est le fait de vraiment chercher le minimum nécessaire pour recueillir le maximum de feedback le plus vite possible.

392
00:17:17.347 --> 00:17:20.702
Ce sont trois choses pour moi qui sont absolument inséparables.

393
00:17:20.962 --> 00:17:22.762
Peu importe le contexte dans lequel vous travaillez,

394
00:17:22.822 --> 00:17:25.782
même si vous travaillez dans un contexte où la feature est posée,

395
00:17:25.902 --> 00:17:26.842
c'est à carrière rien d'autre,

396
00:17:27.002 --> 00:17:30.842
il est extrêmement important de travailler en tout petit incrément.

397
00:17:31.042 --> 00:17:31.771
Car une fois de plus,

398
00:17:31.771 --> 00:17:36.002
c'est de cette façon-là que l'on va pouvoir mettre quelque chose le plus rapidement entre les mains de l'utilisateur.

399
00:17:36.770 --> 00:17:37.352
Et surtout,

400
00:17:37.773 --> 00:17:41.526
travailler sur un petit morceau est beaucoup plus simple d'un point de vue de qualité logicielle.

401
00:17:41.886 --> 00:17:44.186
Je peux développer ce petit morceau avec une très bonne qualité.

402
00:17:44.666 --> 00:17:45.108
Et derrière,

403
00:17:45.128 --> 00:17:49.286
si j'ai besoin de rajouter en proactif une amélioration à cette feature-là,

404
00:17:49.726 --> 00:17:54.616
ce sera beaucoup plus simple pour moi de modifier ce code-là qui est déjà de bonne qualité parce qu'il ne sera pas trop gros,

405
00:17:54.636 --> 00:17:55.906
ce sera un petit morceau de code.

406
00:17:56.207 --> 00:17:57.533
Et donc si vous travaillez comme ça,

407
00:17:58.015 --> 00:17:59.080
avec du TDD,

408
00:17:59.382 --> 00:18:00.386
avec de la clean architecture,

409
00:18:00.806 --> 00:18:03.926
que vous travaillez en agile avec de petits incréments de valeur,

410
00:18:04.313 --> 00:18:11.070
dans lequel vous questionnez régulièrement le besoin qui vous est demandé par le PO ou le client ou autre,

411
00:18:11.831 --> 00:18:21.810
vous irez nécessairement plus vite que n'importe quel autre développeur qui tape un rush de la feature avec le framework de son choix qui est extrêmement productif,

412
00:18:22.370 --> 00:18:24.190
que ce soit Rails ou soit Symfony ou autre,

413
00:18:24.550 --> 00:18:27.450
donc du coup qui ira très très vite dans le développement de la feature,

414
00:18:27.930 --> 00:18:32.550
mais qui va ramer et qui va ramer de plus en plus à mesure qu'il va avoir ces feedbacks-là.

415
00:18:32.955 --> 00:18:38.481
Et si vous travaillez avec un développeur qui fait de la clean architecture du TDD et qui ne sort rien au bout de

416
00:18:38.823 --> 00:18:39.326
1 mois,

417
00:18:39.486 --> 00:18:39.848
2 mois,

418
00:18:39.909 --> 00:18:40.170
3 mois,

419
00:18:40.190 --> 00:18:42.104
mais qui ne sort rien au bout de 2 semaines,

420
00:18:42.366 --> 00:18:42.970
inquiétez-vous.

421
00:18:43.110 --> 00:18:43.391
Pour moi,

422
00:18:43.432 --> 00:18:46.870
il ne pratique pas proprement le craftsmanship et l'agilité.

423
00:18:47.692 --> 00:18:47.913
Voilà,

424
00:18:48.053 --> 00:18:49.217
donc pour répondre à la question,

425
00:18:49.418 --> 00:18:52.648
qu'est-ce que la qualité logicielle et qu'est-ce qu'un logiciel de bonne qualité ?

426
00:18:53.290 --> 00:18:55.034
La réponse a déjà été donnée dans le podcast,

427
00:18:55.115 --> 00:18:55.937
pour moi elle est parfaite,

428
00:18:56.017 --> 00:19:01.390
c'est un logiciel dans lequel on peut rajouter de la valeur et que l'on peut déployer régulièrement.

429
00:19:01.650 --> 00:19:02.131
Et pour ça,

430
00:19:02.572 --> 00:19:03.534
il n'y a pas de secret,

431
00:19:03.654 --> 00:19:10.550
on a besoin d'avoir un environnement qui nous permette d'avoir l'assurance de pouvoir faire ce déploiement sans avoir à passer des heures sur les tests.

432
00:19:11.170 --> 00:19:15.224
Et on a besoin aussi d'avoir les moyens de modifier ce code-là sans avoir peur,

433
00:19:15.264 --> 00:19:16.970
sans avoir besoin de retester tout le périmètre.

434
00:19:17.426 --> 00:19:19.413
Au début c'est facile lorsqu'il y a 10 000,

435
00:19:19.433 --> 00:19:19.734
20 000,

436
00:19:19.734 --> 00:19:21.842
30 000 lignes de code de faire un test de périmètre,

437
00:19:22.102 --> 00:19:23.234
lorsque le code est assez simple,

438
00:19:23.254 --> 00:19:23.962
il n'y a aucun problème.

439
00:19:24.402 --> 00:19:25.627
Lorsqu'on arrive à 100 000,

440
00:19:25.627 --> 00:19:26.431
150 000,

441
00:19:26.431 --> 00:19:28.962
200 000 et qu'on commence à toucher les 500 000 lignes de code,

442
00:19:29.382 --> 00:19:31.762
que le périmètre devient très large et qu'on est une équipe de 20 personnes,

443
00:19:32.062 --> 00:19:35.402
ça devient beaucoup plus compliqué de le faire si on n'a pas les tests qui vont avec.

444
00:19:35.844 --> 00:19:39.942
Et donc naturellement ça devient plus compliqué de maintenir cette qualité logicielle.

445
00:19:40.462 --> 00:19:40.784
Donc voilà,

446
00:19:40.844 --> 00:19:44.622
j'espère que ce petit podcast vous a plu en réaction au Enzone Podcast.

447
00:19:45.024 --> 00:19:46.191
que je vous invite à regarder,

448
00:19:46.331 --> 00:19:47.498
qui est extrêmement intéressant.

449
00:19:47.678 --> 00:19:47.779
Moi,

450
00:19:47.799 --> 00:19:49.938
j'aime beaucoup le travail de Mathieu Calaoui.

451
00:19:50.118 --> 00:19:51.298
J'espère que je n'ai pas écorché son nom.

452
00:19:52.362 --> 00:19:53.118
J'aime beaucoup son travail.

453
00:19:53.218 --> 00:19:54.678
J'aime beaucoup le travail de Hill Studio.

454
00:19:54.818 --> 00:19:56.198
Je prends toujours beaucoup de plaisir à l'écouter,

455
00:19:56.399 --> 00:19:56.841
même si,

456
00:19:57.284 --> 00:19:58.149
sur ce podcast-là,

457
00:19:58.591 --> 00:19:59.878
j'ai eu beaucoup de désaccords.

458
00:20:00.118 --> 00:20:00.464
Maintenant,

459
00:20:00.504 --> 00:20:01.358
ça fait partie du jeu.

460
00:20:01.538 --> 00:20:02.358
Il y a différents avis.

461
00:20:02.898 --> 00:20:03.826
Le plus important,

462
00:20:04.209 --> 00:20:08.758
c'est de ne pas aller insulter et d'aller embêter les gens qui pensent différemment de vous.

463
00:20:08.838 --> 00:20:09.797
Ça fait partie du jeu aussi.

464
00:20:10.779 --> 00:20:11.101
Sur ce,

465
00:20:11.464 --> 00:20:13.078
je vous laisse et je vous dis à bientôt.