Si les choses étaient simples, tous les projets pourraient être définis et implémentés une bonne fois pour toute. Ce n'est malheureusement pas souvent le cas. L'environnement, les utilisateurs, les contraintes, les systèmes d'exploitation sont tous amenés à se transformer au fur à mesure que le temps passe, et il peut donc arrive qu'un projet doive être mis à jour. Ce type d'opération est généralement problématique car les implémentations initiales doivent parfois être modifiées, le code source doit parfois être convertit dans un autre langage, des limites du programme doivent être étendues tout en conservant la compatibilité ascendante avec tout l'existant, etc...

Si cette opération de maintenance logicielle est mal effectuée, cela peut poser de nombreux problèmes futures. Evidement, plus les documents initiaux ont été réalisés correctement, plus l'opération se révèlera simple à effectuer. Le problème se situe généralement ailleurs: Le document initial n'est pas mis à jour pour refléter les modifications effectuées, ce qui fait que les prochaines modifications se passeront généralement mal. C'est une erreur triviale, mais extrêmement courante, qui se révèle être coûteuse et traître, car si le document et l'implémentation initiale étaient bien réalisés les modifications apportées auraient été aisées à faire, ce qui donne généralement l'impression que les modification ultérieures le seront aussi. Malheureusement si le document n'a pas été mis à jour, ça ne sera pas le cas !

If everything was easy, any project could be defined and implemented once and forever. Unfortunately this is not often the general case. The external interactions, users, constraints, operating systems are perpetually evolving with time passing, and so sometimes a project must be updated. This kind of operation is often difficult, because that often requires a substention modification of the initial implementation, sometimes the source code must be converted to another language or compiler, some internal limits of the software must be extended while keeping the backward compatibility with all that have already been done, and so on...

If this software update is badly performed it can have very nasty consequences in the futur. Of course, the best the design documentation was, the easier performing the operation is. The real problem is generary somewhere else: The initial document is generaly not updated to reflect the modification with an obvious consequence: The next modification will be a real pain. This is a trivial mistake that most teams are not aware of. This error is costly and treacherous for one good reason: If the initial document and implementation was correctly done, the first modification should have been "very easy" to perform, and so everybody consider that futur modification will be as easy and fast. Unfortunately if the document has not been update it will not be the case !

Il faut archiver tout le projet avant de faire la moindre modification. Cela inclus les code sources, la documentation, les makefile. Si l'opération se passe mal, il serait vraiment stupide de perdre l'original !

Il faut lire le document de design avant de s'attaquer au code source. Si l'on sait de quoi ça parle, on comprendra mieux l'implémentation. De plus en lisant le document de design avant le code source, on peut avoir sa propre idée d'implémentation, ce qui aide pour la suite et est beaucoup plus dur a faire si on sait déjà comment c'est écrit.

Rechercher si la documentation ou le code source ne contient pas des indications de type "choses à faire", "extension possible", "todo", etc... Il est possible que l'auteur initial ait déjà prévu la modification que vous vous apprêtez à faire, alors au lieu de réinventer la roue utilisez cette possibilité.

Faites une évaluation de la difficulté et du temps que cela risque de représenter. Faites une liste exhaustive de ce que vous pensez devoir avoir à faire, et soumettez ça à quelqu'un d'autre pour avoir d'autres avis. Soumettez le tout à votre responsable avant de vous lancer: Si ça se trouve il préfèrera tout balancer et acheter un logiciel du commerce, alors ne perdez pas votre temps.

Si vous avez finalement à faire des modifications, notez tout au fur et à mesure, en mettant des commentaires en haut du source pour dire que vous avez fait telle modification à telle heure, et aussi un commentaire à l'endroit ou vous avez fait la modification qui permette de retrouver facilement tout ce que vous avez fait. (moi par exemple je met "// Mike" ce qui permet de faire une recherche globale dans le projet)

Si vous tombez sur des commentaires pas clairs, analysez le code, soyez sur de votre coup, et mettez votre commentaire à la place s'il permet de gagner du temps à d'autres personnes plus tard ça n'est pas du temps perdu. De même si vous tombez sur des commentaires manquant ou carrément faux, corrigez les.

Si vous avez à votre disposition des outils d'analyse de code de type "afficheur de la hiérarchie des classes", "pc-lint" ou autre, n'hésitez pas à vous en servir. Ca permettra peut-être de trouver de grosses boulettes que vous auriez mis beaucoup de temps à trouver.

Si vous devez modifier une implémentation, commentez pourquoi vous le faites.

Si vous devez changer / enlever / rajouter une fonctionnalité, rajoutez le dans le document de design, de manière à ce que l'on voit que c'est une modification ultérieure. Si vous changez un format de fichier, n'oubliez pas de faire la corrélation partout au niveau de la gestion des numéro de version, surtout si vous avez une compatibilité à assurer.

Ne bâclez pas votre travail. Je sais que ça n'est jamais très agréable de remanier un programme, que cela soit le votre ou celui d'un autre. Mais bon relativisez: Vous apprenez la maintenance, a comprendre le code des autres (ou bien votre propre code d'il y a 4 ans !), à bosser proprement. Vous venez de rentrer dans le club très fermé des codeurs méthodiques. Ceux sur qui on peut compter, qui ne sont pas systématiquement hors délais et hors budget, et qui ont de l'expérience. Contrairement à ce que vous pouvez croire, les programmeurs capable de ce genre de chose sont au moins aussi recherchés que ceux qui savent programmer des moteurs 3D ou des algorithmes de physique et de dynamique...

The whole project must be archived before any modificaiton. This includes source codes, documentation, makefiles,... If the update operation is badly done, you would be sorry to have no copy of the original job...

You should read the original design document before thinking to read the source code. It is always easier to understand a code source implementation when you know what it's supposed to do. And when you read a design document it generaly give you an idea of how it could be implemented and this can helps you later. If you already know the actual implementation it is harder to imagine something else.

Look into the documentation and in the source code for indications put by the authors concerning futur updates. Perhaps they anticipate the modification you are suppose to do. So look for things like "TODO" "UPDATE" and other comments like that. You have nothing to lose, and potentialy can win a lot of time.

Try to honestly evaluate the difficulty and time required to perform the modificaiton. Try to list all the things that need to be done, and submit all that stuff to the opinion of someone else. After you can submit a report to you hierarchical or financial responsable: Perhaps he will finally decides to throw everything away and buy some off the shelf software !

If you finally have to do some modification, then write somewhere all that you are doing. Update the comments at the top of the source code indicating what modification you perform, and when. Do not forget to put some additional comment where you've done the modification so it will be easy to locate all the modifications you've done in the project. (Personaly, I write "// Mike" so I can performa a global search on the project)

If you find some obscures comments, do not hesitate to analyse the code and correct/update the comment. If this can avoid someone else to loose time trying to understand the same comment this is not lost time. And if you find missing or totaly wrong comments, correct them.

If you have code analysis software as "hierarchy class viewer", "pc-lint" or anything else like that, do not hesitate to use them. Perhaps they will help you to locate enormous problems, implementation bugs, structuration flaws that could have been very hard to notice.

If you need to modify an implementation, never forget to comment why.

If you have to change / remove / add a feature, write it in the design document. Do it in a way everybody knows it is an update and not a thing present in the original design. If you change a file format, do not forget to check the handling of file format versioning, be specially carefull if you have to keep a compatibility.

Do not do a bad job. I know this is never cool to have to work on a old program beeing yours or someone else one. But try to think about it: When you do that, you're learning how to maintain living software, understand someone else code (or perhaps your own 4 year old code), to work cleanly and efficiently. By doing that you just enter in the very closed club of the "clean coders". You are now someone reliable, able to keep resonble delays and budgets, and have good real world experience. You could think that only guys that do 3D engines or physic engines are searched by software companies, but the real thing is that good general purpose coders are as priceless...