Dans un monde idéal, tous les codes écrits par un développeur donné seront bien documentés, structurés et testés de manière compréhensible, avec des outils automatiques tels que des tests unitaires et des scripts de cas d'utilisation exécutés par l'utilisateur pour vérifier que vous obtenez le résultat attendu.
Cependant, la première chose que vous apprendrez, c'est que nous ne vivons pas dans un monde idéal!
Un grand nombre de développeurs ne documentent pas correctement leur code, voire pas du tout, ils associent logique métier et code non lié. Le seul test qu'ils effectuent est une analyse rapide de ce qu'ils s'attendent à être le cas d'utilisation normal.
Lorsque vous travaillez avec un code comme celui-ci, la première chose à faire est d'établir ce qu'il est censé faire. S'il y a des commentaires, ils peuvent vous donner des indices, mais ne comptez pas dessus. D'après mon expérience, de nombreux développeurs ne sont pas doués pour s'expliquer et même s'ils laissent des commentaires, ils pourraient ne pas avoir de sens. Cependant, à moins d'être le seul codeur de la société, quelqu'un doit sûrement avoir au moins une idée de base du code et de ce qu'il est censé faire. Demande autour de toi!
Si vous avez des tests unitaires, ils vous faciliteront grandement la vie. Sinon, l'apprentissage de la base de code peut impliquer l'écriture de tests unitaires pour le code existant. Normalement, cela n’est pas considéré comme une bonne pratique car si vous écrivez des tests unitaires pour s’ajuster au code existant, vous vous retrouverez avec des tests unitaires qui pensent que le code fonctionne tel quel (ils seront écrits pour supposer que le comportement qui est en fait un bogue est correct), mais au moins cela vous donne une base. Si vous découvrez par la suite que certains comportements que vous pensiez corrects sont en fait incorrects, vous pouvez modifier le test unitaire pour rechercher le résultat attendu plutôt que le résultat obtenu à présent par le code. Une fois que vous avez passé un test unitaire, vous pouvez apporter des modifications et évaluer les effets secondaires de vos modifications.
Enfin, la meilleure ressource dont vous disposez pour traiter un élément de code non documenté est de demander aux utilisateurs finaux. Ils peuvent ne rien savoir du code, mais ils savent ce qu'ils veulent que l'application fasse. La collecte des exigences est la première étape de tout projet, et les discussions avec les utilisateurs potentiels du système à développer constituent toujours un élément important. Pensez-y simplement que vous réalisez l’étape de capture des exigences pour un nouveau projet qui vient d’être déjà construit.
N'oubliez pas que même un code bien écrit et bien documenté peut être difficile à comprendre pour un étranger. Le code est essentiellement une expression de la façon dont l'auteur a pensé à l'époque, et chacun a son propre processus de pensée. Vous devrez apprendre à être un peu patient et à être détective. Il est difficile d'entrer dans le processus de réflexion d'une autre personne, mais il s'agit d'une compétence essentielle pour un programmeur qui effectue la maintenance du code existant. Comme la plupart des opérations de codage (environ 70%) sont liées au maintien du code existant, il s'agit d'une compétence importante à apprendre.
Oh, et maintenant que vous avez vu la douleur que peut causer un code mal documenté, non testé et brouillé, vous ne le ferez pas au prochain pauvre développeur, non? :) Tirez les leçons des erreurs de votre prédécesseur, commentez bien votre code, assurez-vous que chaque module a une responsabilité clairement définie, et assurez-vous de disposer d'un ensemble complet de tests unitaires que vous écrivez en premier (pour les méthodologies TDD) ou au moins à côté du code en cours de développement.