Meowcate (./22911) :
dans les derniers à y avoir écrit, ils ont bien dû comprendre le code pour y ajouter leur pierre ?
Tu n'as généralement pas besoin de comprendre l'ensemble du fonctionnement d'un appli / bibliothèque pour y ajouter un comportement ou corriger un bug, d'une part.
Et même quand tu souhaites comprendre le fonctionnement général d'une appli / lib complète, tu n'as généralement pas besoin de relire le moindre détail pour ça.
D'expérience, les revues de code sont souvent assez efficaces sur quelques dizaines de lignes de code ; au-delà de quelque chose comme 200 à 300 lignes, ça devient plus difficile.
Alors, sur une appli complète, à part à avoir des semaines devant soit (ce qui, sauf très rares exceptions, demande une certaine forme de financement), c'est pas tout à fait exactement faisable...
Meowcate (./22911) :
on n'avait pas encore inventé le versionning ou quoi ?
Même en faisant des revues de code systématiques sur l'ensemble des changements à chaque fois qu'ils arrivent (idéalement, avant qu'ils ne soient intégrés, bien sûr), il se peut que des bugs passent entre les mailles du filet.
J'ai souvenir sur un soft d'un changement portant sur une ligne de code, ajoutée (même pas modifiée).
Quelque chose du genre, en PHP :
sort($tableau);Changement simple, qui répondait visiblement au besoin fonctionnel, et n'a cassé aucun test.
Bon ben une fois en prod, sur des jeux de données plus réalistes que ceux qui avaient été utilisés en tests, il a été réalisé qu'il manquait un caractère à cette ligne, et qu'il aurait fallu genre :
asort($tableau);C'est con comme bug ; et ça avait échappé à ceux qui avaient fait la revue de code... mais ça arrive... même avec toute la bonne volonté du monde.
)
et bien comme c'est plus long à écrire, peut-être que le codeur aime s'entendre taper.
)
)