SlideShare une entreprise Scribd logo
Comment récupérer un
projet Web pourri...
… et réussir à travailler dessus !
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)
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
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
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 : ...
(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 ?
(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...
(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
(Re)prise en main du projet
Partie 4 : Langages utilisées (et versions) ?
● Pour PHP
● http://php.net/manual/fr/appendices.php
(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)
(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.
(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.
(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é. »
(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)
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
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.
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
● ...
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';
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
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 ...
merci

Contenu connexe

Similaire à Comment récupérer un projet Web pourri ... et réussir à travailler dessus.

Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
Normandy JUG
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019
Rodrigue Villetard
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven
Arnaud Héritier
 
La relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesLa relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiques
Eric SIBER
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
Nouhaila ALAMI
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Agile
AgileAgile
Agile Methodologies
Agile MethodologiesAgile Methodologies
Agile Methodologies
Jean-Philippe Jacoupy
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
testuser715939
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
Mohamed IBN ELAZZOUZI
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
Stéphane Traumat
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
ssuserec8501
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
agnes_crepet
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
JEAN-GUILLAUME DUJARDIN
 
Projet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiProjet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type Wiki
MylneRoffi
 
Presentation forum php 2010
Presentation forum php 2010Presentation forum php 2010
Presentation forum php 2010
Laurent Destailleur
 
Ch1-Généralités.pdf
Ch1-Généralités.pdfCh1-Généralités.pdf
Ch1-Généralités.pdf
FadouaBouafifSamoud
 
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Médiathèque de Roubaix - La Grand-Plage
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slides
Oxalide
 

Similaire à Comment récupérer un projet Web pourri ... et réussir à travailler dessus. (20)

Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
Une application sans framework en 2019
Une application sans framework en 2019Une application sans framework en 2019
Une application sans framework en 2019
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven
 
La relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesLa relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiques
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Agile
AgileAgile
Agile
 
Agile Methodologies
Agile MethodologiesAgile Methodologies
Agile Methodologies
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
 
Projet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiProjet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type Wiki
 
Presentation forum php 2010
Presentation forum php 2010Presentation forum php 2010
Presentation forum php 2010
 
Chapter1
Chapter1Chapter1
Chapter1
 
Ch1-Généralités.pdf
Ch1-Généralités.pdfCh1-Généralités.pdf
Ch1-Généralités.pdf
 
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
Créer un site web ? Méthode illustrée par la médiathèque de Roubaix - PARTIE 1
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slides
 

Comment récupérer un projet Web pourri ... et réussir à 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