Méthode de développement application web (anarchique)

Version imprimable

09/11/2015, 14h18
roukgreg

Méthode de développement application web (anarchique)

Bonjour,

Je viens vers vous pour vous demander quelques conseils.

J'ai rejoins, il y a peu, une petite cellule informatique qui travail sur une application web qui fonctionne sur tout le territoire français. Malheureusement cette application ne dispose d'aucune doc (rien de chez rien), et il n'existe pas de méthode ni de plateforme de dev. Quand une modification doit être faite, elle s'effectue directement sur le site en prod.
La base de données, qui, je pense, pourrait ne contenir qu'une trentaine de tables en contient plus de 130, sans clé étrangère sans contraintes, et également sans doc (aucun MCD, aucune description de certains champs, pourquoi la valeur 0, pourquoi la valeur 1 pourquoi la valeur 2 etc..). Beaucoup de table sont de véritable gruyère et une information peut se retrouver dans 4 ou 5 tables différentes.
Plusieurs développeurs s'étant succédé dans le développement de cette application, 50 façons de coder différentes, avec des fonctions créé 10 fois sur 10 fichiers différents (aucune consultation dans l'équipe).

Bien entendu, impossible, faute de temps, de reprendre à 0 le développement de cette application.

Enfin l'anarchie complète... :calim2:

Aujourd'hui la seule personne qui connait encore bien cette application va certainement quitter le projet. Donc pour nous, c'est la grosse m***e!! :aie:

J'ai expliqué à tout le monde qu'il fallait absolument mettre en place des choses pour nous permettre de continuer à maintenir l'application et qu'il fallait également l'améliorer (supprimer les doublons dans la BDD, dans les fichiers, supprimer les tables fantôme, etc...).

Mais étant donné l'ampleur de la tâche, je ne sais pas trop par ou commencer.

Je pensais partir dans un premier temps sur :
- La création d'un MPD pour nous permettre d'y voir plus clair
- D'une description de chaque fichier (il y en a 3000 environ :calim2: )
- Création d'une plateforme de dev. sur laquelle chacun travaillera avant de mettre un fichier sur le prod. (le problème c'est la BDD, elle contient plus de 100 millions d'entrées, donc difficile d'en faire une copie)

Mais c'est tellement mal organisé, mal structuré, qu'après les points évoqués ci-dessus je ne sais plus.

Auriez-vous des conseils pour m'aider dans mon ascension de l’Everest en short et claquette:aie: !!!
09/11/2015, 15h07
Jacques Beauregard

Bonjour,

Je t'aurais bien conseillé quelque chose mais :

Citation:

Bien entendu, impossible, faute de temps, de reprendre à 0 le développement de cette application.

A toute l'équipe dorénavant de faire un choix :

- poursuivre ainsi et développer une application plus ou moins fonctionnelle, clairement non maintenable (chaque évolution sera très complexe à mettre en place par exemple...)?
- reprendre à 0, engendrant un sérieux délai dans la livraison finale d'une application fonctionnelle et maintenable ?

Ce qui me turlupine : comment la phase de développement a pu démarrer sans phase d'analyse & conception ? ( choix technologiques ? plateforme de dev? logiciel de gestion de version (surtout quand on est plusieurs développeurs...)? etc...)
09/11/2015, 15h36
roukgreg

Tout d'abord merci de ta réponse rapide.

Pour ce qui est du début du projet, personne n'en sait rien. Les personnes présentes au tout début ne sont aujourd'hui plus là. D'autres leurs ont succédé, puis d'autres, puis d'autres, sans transfert de compétences, donc le vide total!!!
Ce que je sais, c'est que c'était à la base, un petit projet de rien du tout, puis une fonctionnalité en plus à été demandée, puis une autre, puis une autre et ainsi de suite, jusqu'à aujourd'hui, et qui fait de cette application une fonctionnalité nationale indispensable pour mon entreprise.

Ne pouvant clairement pas reprendre tout de 0, est-ce que vous pensez qu'il est possible de remettre les choses tranquillement à plat, tout en laissant tourner l'appli?
Bien sur, impossible de s'y consacrer pleinement, mais le faire au fil de l'eau.

Ce que je pense faire :
- Mise en place serveur de dev.
- Mise en place SVN
- Création MPD
- Lister et commenter les différents dossiers et fichiers (à faire régulièrement)
- Noter les fonctions disponibles et leur emplacement, et virer les doublons
- Une fois MPD établi, récréer des tables qui évitent les doublons (en gardant dans un premier temps les anciennes, car il faut garder l'historique !!! :aie: )

Après je ne sais pas vraiment si tout ça peut m'aider, et peut être faut-il faire plus de choses, mais vraiment ... [pas de mots] !!! :calim2:
09/11/2015, 15h52
tdutrion

J'utiliserais Git et particulièrement git-flow dès le démarrage mais ça dépends aussi des capacités de l'équipe.

Existe-t-il des tests unitaires ? Je pense que non, dans ce cas, fais tourner un script de test unitaire avec code coverage en intégration continue dès que tu as mis en place le code sur un repository. Ca va commencer avec 0% de couverture (ça fait peur...), passera par un peu de couverture et du test invalide à des moments, mais à chaque pourcent gagné c'est la fête (dans vos têtes, mais aussi l'occasion de faire une petite fête ou boire un pinte - selon la taille du projet faut le faire tous les pourcents ou 10%... c'est du team building pas de l'incitation à l'alcoolisme...).
Utilises aussi sur cette plateforme d'intégration des outils de reporting : coding standard, complexité cyclomatique, etc. Vois ce qui peut être résolu à court ou moyen terme.

Selon le RDBMS utilisé, il existe des outils de rétro-conception. Utilises ça comme base, vois les liens manquants et mesure la difficulté à les ajouter : comptes les FK dont les données ne match pas, etc, et pondère (donnée modifiable, problème critique, etc...).

Pense aussi à ajouter différents niveaux de logs (dev, staging, prod). En l'absence de tests, les logs sont un bon fallback pour entamer un debug je trouves.

Serait-il possible d'avoir une idée des technos utilisées ?
10/11/2015, 13h25
roukgreg

Oula!! :aie:

Je suis pas sur d'avoir bien tout compris (enfin j'ai compris, mais y a certaines choses que je ne connais pas).

Mais oui, il y a beaucoup de choses à faire, à voir, à revoir!!

En faite hormis un framework propriétaire propre à mon entreprise, le reste de l'application n'est rien d'autre qu'un simple site web (intranet), php, html css etc...
Donc pas vraiment complexe si tout était correctement fait.
Je pense que je vais mettre en place des tests unitaires dans un premier temps, couplé avec l'utilisation de git (je l'ai utilisé une fois, mais pas bien compliqué). On a vu ce matin pour la mise en place d'un SVN qui devrait ce faire rapidement avec la plateforme de dev, qui est plus que nécessaire.
Je vais voir pour la mise en place également d'un process de dév, avec réunion, échanges, et la mise en place d'un coding standard qui nous aideras.

Aprés tout ça mis en place, je penserais à aller plus loin!! Il va falloir du courage et beaucoup de boulot pour tout ça!!! :calim2:

Encore merci pour vos réponses
11/11/2015, 11h30
bretus

Citation:

Envoyé par roukgreg

Aprés tout ça mis en place, je penserais à aller plus loin!! Il va falloir du courage et beaucoup de boulot pour tout ça!!! :calim2:

Bon courage à toi. Mon conseil : Essaye de faire ça par ordre de priorité en faisant bien adhérer tes collègues.

1) Mettre en place un GIT, arrêter de travailler directement sur la production. Dans un premier temps, tu ne déploies que des tags sur la production. Dans un second temps, tu regarderas du côté de git-flow pour avoir une méthode de gestion des branches et des tags.

2) Documenter le modèle de données existant (mettre au propre le script d'initialisation de la base (les CREATE TABLE) peut être un point de départ si tu n'as pas d'ORM qui gère cet aspect.

3) Mettre en place des tests fonctionnels et tests de non régression (vu la méthode de développement, ça m'étonnerait que tu fasses facilement des tests unitaires : Il faut des codes propres pour pouvoir faire des mocks).

Approche brutale : Prendre la base de production à l'instant, supprimer les données sensibles (utilisateur). Hop, tu as un jeu test où tu peux faire des assertions sur les résultats. J'aime encore bien cette approche, car elle te permet d'avoir un jeu test le jour où tu fais une migration de structure de données (quand tu passes de 130 tables à 50).

4) Mettre en place une plateforme d'intégration continue (type jenkins).

Le but : Que les tests ne soient pas exécuté au bon vouloir des développeurs, mais à chaque modification du code.

5) Reprendre une convention de codage (type PSR-2) et vérifier qu'elle est appliquée avec PHP-CheckStyle.

Point qui m'étonne : Ton framework propriétaire n'a pas de convention de codage? La racine du mal est peut-être là. Le framework de ma boite c'était Zend1, là c'est Symfony2, mais plus généralement, c'est surtout PHP Composer+PSR-2 (autoloader)+SATIS. NB : Utiliser une convention de nommage existante évite d'en documenter une et permet de bénéficier des outils qui vérifient qu'elle est appliquées.

6) Rechercher les codes moches avec des outils du type PHP-MD, CopyPasteDetector, etc.

7) Prendre du recul et définir une stratégie pour refactorer tout ça dans le temps.

En bref, définir une architecture cible et voir comment vous pouvez converger progressivement vers cette architecture cible.

Citation:

En faite hormis un framework propriétaire propre à mon entreprise, le reste de l'application n'est rien d'autre qu'un simple site web (intranet), php, html css etc...

Les 3000 fichiers, c'est en comptant le framework? Tu as combien de fichiers/fonctions propres à l'application? Est-ce que tu peux y définir des "modules" qui te permettront de refactorer module par module à l'occasion de corrections de bugs ou ajouts de fonctionnalités?

130 tables, ça ne me fait pas penser à une petite application.