Présentation pour Blendwebmix 2017, sur le thème de la récupération de projet Web. Je présente les principales raisons de fails de projets, et comment réussir quand même à travailler dessus.

1. Comment récupérer un
projet Web pourri...
… et réussir à travailler dessus !

2. Présentation
Je m’appelle : Guillaume RICHARD
Profil : développeur Web depuis 2009.
Aujourd’hui : Développeur Front-end chez P3-group.
Avant (Depuis 2010) : différentes missions (toujours en développement Web)

3. Informations à savoir
Taux de réussite
39% de tous les projets aboutissent (délais, budget, caractéristiques et fonctionnalités requises)
43% sont livrés mais rencontrent des problèmes (retard, dépassement de budget, fonctionnalités manquantes)
18% échouent (soit annulés avant d'être terminés, ou livrés mais jamais utilisés).
Plus la complexité et la taille d'un projet sont importantes, plus le risque d'échec est fort.
Informations issues d’articles récents
https://www.planzone.fr/blog/statistiques-gestion-projet-surprenantes
http://www.pl-conseil.net/pilotage/projet/article/statistiques-sur-100-projets

4. Raisons/causes des fails du projet
#1 : Quand la demande du client tient en quelques lignes
#2 : Quand l’estimation a été sous-estimée en fonction des compétences disponibles
#3 : Quand on ne sait pas par quoi commencer (Objectifs de projet vagues)
#4 : Quand les demandes de modifications du client se notent dans les e-mails ou exprimées au téléphone
#5 : Quand les demandes de modifications du client se font aussi en cours de développement
#6 : Quand les membres du projet s’en vont avec les infos du projet … dans leur tête
#7 : Quand les réunions ne sont pas structurées
#8 : Deadline impossible à respecter par rapport aux réalités du projet

5. Raisons/causes des fails du projet (...suite)
#9 : Quand les équipes fatiguent
#10 : Choix de technologie en non-adéquation avec le projet, ou avec les compétences de l’équipe.
#11 : ...

6. (Re)prise en main du projet
Partie 1 : Gestion de projet
● Revoir la gestion de projet ?
● Remettre à plat la demande du client ?
● Cahier des charges, planification du projet ?

7. (Re)prise en main du projet
Partie 2 : le projet en lui-même
#1 Déterminer l’outil : CMS ? Framework ? autre …
#2 Analyse le projet (audit, ou reverse engineering)
#3 Attention au Bonne Pratique
- Documentation online (en correspondance avec la version de l’outil)
- Livres, articles de blog, etc...

8. (Re)prise en main du projet
Partie 3 : l’architecture et fichiers de configuration
● Analyse de l’architecture du projet
● Modifier l’architecture de l’outil, bonne ou mauvaise chose ?
○ Exemple de Wordpress
○ Exemple de CodeIgniter

9. (Re)prise en main du projet
Partie 4 : Langages utilisées (et versions) ?
● Pour PHP
● http://php.net/manual/fr/appendices.php

10. (Re)prise en main du projet
Partie 4 : Langages utilisées (et versions) ?
● Utilisation de bibliothèques qui vont tendre à disparaitre ?
○ Extension MySQL (vs Extension MySQLi / PDO)
○ Mcrypt (non maintenu depuis 2007)
○ Ereg, eregi, etc…
● Constructeurs PHP4 (méthodes ayant le même nom que la classe dans laquelle ils sont définis)

11. (Re)prise en main du projet
Solution pour éviter des erreurs avec du code ancien : Créer de l’abstraction.
Définition : En informatique, le concept d'abstraction identifie et regroupe des caractéristiques et
traitements communs applicables à des entités ou concepts variés ; une représentation abstraite
commune de tels objets permet d'en simplifier et d'en unifier la manipulation.

12. (Re)prise en main du projet
Partie 5 : Attention à la couche d'abstraction que l'on ajoute à l'outil
● Eviter les fichiers fourre-tout (quelques soit les langages)
● Eviter les fichiers trop long
● Eviter les fichiers mélangeant plusieurs langages différents.
● Déterminer les règles de développements et de nommage, et garder-les jusqu’au bout.

13. (Re)prise en main du projet
Partie 5 : Attention à la couche d'abstraction que l'on ajoute à l'outil
Pour la couche d’abstraction et les bibliothèques tierces ajouté sur le site : Utiliser le principe du
rasoir d'Ockham (https://fr.wikipedia.org/wiki/Rasoir_d%27Ockham).
Le rasoir d'Ockham ou rasoir d'Occam est également appelé principe de simplicité, principe
d'économie ou principe de parcimonie, il peut se formuler comme suit :
Pluralitas non est ponenda sine necessitate
« Les multiples ne doivent pas être utilisés sans nécessité. »

14. (Re)prise en main du projet
Partie 6 : outil de qualité de code
● Technologie PHP
○ PHPUnit (Test unitaire)
○ détecte/corrige les erreurs de normes de codage (PHP_CodeSniffer, PHP-CS-Fixer)
○ vérifier la qualité de votre code (Php-mess-detector)
○ Tout-en-un (grumPHP) …
● Existe aussi en JS (comme jslint)

15. Documentation et Commentaires
phpdocumentor
URL - https://www.phpdoc.org/
Packagist - https://packagist.org/packages/phpdocumentor/phpdocumentor
Tag existant - @api, @author, @copyright, @deprecated, @example, @license, @link, @package, @param,
@return, @see, @since, @source, @subpackage, @throws, @todo, @version

16. Pratiques pour commenter
Aujourd’hui
● Aucune nomenclature existante pour les commentaires.
● Listes de règles de bonnes pratiques à suivre.
● Listes de règles de mauvaises pratiques à ne pas suivre.

17. Mauvaises pratiques de commentaire
● Commentaires qui paraphrase le code
● Commentaire non maintenu
● Manque d’imagination pour le nommage (Vous auriez pu utiliser un meilleur nom)
● Commentaires servant d’excuse pour ne pas avoir à réécrire le code d’une meilleure façon
● ...

18. Bonnes pratiques pour commenter
● Quel est le pourquoi ?
● Clarifier quelque chose qui n'est pas lisible/compréhensible par les êtres humains ordinaire
Exemple :
.selector { [;property: value;]; }
var isFF = /a/[-1]=='a';

19. Bonnes pratiques pour commenter
Propositions de bon commentaire
● Quelque chose qui est clair et lisible pour vous n'est pas nécessairement clair pour les autres
● Des commentaires comme les chapitres d'un livre
● Un guide pour garder la logique tout en écrivant le code
// get the request from the server and give an error if it failed
// do x thing with that request
// format the data like so

20. Bonnes pratiques pour commenter
Propositions de bon commentaire
● Ceci est OK pour factorisation
// ce n'est pas mon meilleur travail, nous avons dû le faire avant la date limite
● Commenter comme pour un outil d'enseignement
● Copier-coller un bloc entier de code de Stack Overflow ...

21. merci