Discussion :

[randriano]

Bonjour,

Il s'agit de reprendre une application informatique développée par une autre agence et que le client a rompu le contrat de maintenance. Il faut bien alors prendre main le code et la structure des fichiers et de la base de données. Pour information, il s'agit d'un gros site-application PHP.

Comment bien procéder?
Comment documenter le code et la structure de la base de données? En fait, on fonctionne comme ça, il faut tout documenter pour que tous les développeurs de l'agence pourront prendre le projet au cas où l'un de nous est en congé ou ne travaille plus là-bas.
Quels outils utilisez-vous? Pour moi juste Word et Excel où je liste les fonctions de chaque modèle et les rôles de chaque table de la BD.

Merci d'avance!

[el_slapper]

Chaque projet est différent, c'est le problème. J'ai été confronté à une problématique similaire(appli interne obsolète et illisible, à remplacer par quelque chose qui soit maintenable), et au final, il y a trop de cas particulier pour qu'un autre langage que le langage humain soit pertinent, je crois.

[Logan Mauzaize]

Durant une phase de migration, il est bon de savoir quel est l'état du produit. Je commencerai par des relectures de la documentation (spécifications, conceptions, plans de test). Et ainsi voir déjà si le socle est cohérent.
Parallèlement, il faut être capable de remonter l'environnement de développement et les environnements de tests. De même que la reconstruction des packages de livraison et le déploiement en mode "from scratch" et "update".
Ensuite, on peut éventuellement regarder les dernières demandes de modifications et comment elles ont été traitées (échanges, analyses, négociations, codage, test, retours).
Faire également un état des lieux des points de l'outil de suivi (bugzilla, mantis, trac, etc.). Ca permet de voir les évolutions à venir et les bugs connus.
S'il y a du temps (mais peu probable), je commencerai à faire des campagnes de tests (si l'état du plan de test est suffisant).

En conclusion de tout ça, je rédigerai un document (et/ou une matrice) qui trace les éventuelles difficultés, les actions préventives et correctives, ainsi que les risques. Cela pouvant conclure à un no-go, et les actions devront être menées (et éventuellement commandées par le client suivant négociation) avant d'entamer toute activité sur le produit.

[randriano]

Ok mais là je parle d'un projet où il ne reste plus qu'un petit cahier des charges et un simple manuel de l'utilisateur. Le client nous le livre comme ça avec les spécifications de sa nouvelle demande.

A nous de comprendre le code qui est peu commenté et sans autres documentations!

[el_slapper]

Ok mais là je parle d'un projet où il ne reste plus qu'un petit cahier des charges et un simple manuel de l'utilisateur. Le client nous le livre comme ça avec les spécifications de sa nouvelle demande.

A nous de comprendre le code qui est peu commenté et sans autres documentations!

Nemek a pointé quelquechose qui, je le crois, peut vous être utile : un outillage de comparaison. Il vous faut créér, d'une manière ou d'une autre, un outil automatique qui liste les différences entre l'ancienne et la nouvelle version. Sinon, vous allez faire des milliards de regressions sans même les vois.

[Luckyluke34]

Créer une suite de tests automatisés s'il n'y en a pas déjà une peut être un bon moyen de 1/ comprendre le code 2/ le documenter et 3/ s'assurer qu'il y aura le moins de régressions possibles quand on développera des corrections / évolutions.

Un livre intéressant sur le sujet : http://www.amazon.com/Working-Effect...ds=legacy+code

[Logan Mauzaize]

Ok mais là je parle d'un projet où il ne reste plus qu'un petit cahier des charges et un simple manuel de l'utilisateur. Le client nous le livre comme ça avec les spécifications de sa nouvelle demande.

A nous de comprendre le code qui est peu commenté et sans autres documentations!

Si vous appliquez les principes que j'ai énoncé, cela résulte d'un no-go car trop de risques. Et l'action sera de mettre les choses à plat et rédiger en parallèle un plan de test de non-régression ET une spécification associée.

Bien sûr il faudra négocier en tenant compte des risques que prennent chacune des parties. Par exemple, s'ils acceptent pas du tout ou en partie, vous devrez "sur-chiffrer" toutes futures activités en appliquant un coefficient de risque et en chiffrant ces activités de remise à plat au fur et à mesure des corrections et des évolutions.

Je pense qu'il serait également bon de prévoir au moins pendant une période des feedbacks rapides en effectuant une grande quantité de livraisons intermédiaires.

[souviron34]

Quels outils utilisez-vous? Pour moi juste Word et Excel où je liste les fonctions de chaque modèle et les rôles de chaque table de la BD.

Tu peux agrémenter ça d'un organigramme. Rien de bien compliqué, mais avec Word par exemple et la fonction de dessin.

Pour une grosse appli SNCF il y a 4 ans j'ai fais ça pour le coeur.. Tu peux faire un organigramme détaillé, puis en sortir un de plus haut niveau. En utilisan quelques couleurs.

Ensuite d'une part tu l'imprimes (par une imprimerie ou un CopyCenter, enfin un truc où tu peux avoir le format maximum de papier (double A3 par exemple)) , et tu peux l'inclure dans le Wiki interne..