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 ch...
Informations à savoir
Taux de réussite
39% de tous les projets aboutissent (délais, budget, caractéristiques et fonctionna...
Raisons/causes des fails du projet
#1 : Quand la demande du client tient en quelques lignes
#2 : Quand l’estimation a été ...
Raisons/causes des fails du projet (...suite)
#9 : Quand les équipes fatiguent
#10 : Choix de technologie en non-adéquatio...
(Re)prise en main du projet
Partie 1 : Gestion de projet
● Revoir la gestion de projet ?
● Remettre à plat la demande du c...
(Re)prise en main du projet
Partie 2 : le projet en lui-même
#1 Déterminer l’outil : CMS ? Framework ? autre …
#2 Analyse ...
(Re)prise en main du projet
Partie 3 : l’architecture et fichiers de configuration
● Analyse de l’architecture du projet
●...
(Re)prise en main du projet
Partie 4 : Langages utilisées (et versions) ?
● Pour PHP
● http://php.net/manual/fr/appendices...
(Re)prise en main du projet
Partie 4 : Langages utilisées (et versions) ?
● Utilisation de bibliothèques qui vont tendre à...
(Re)prise en main du projet
Solution pour éviter des erreurs avec du code ancien : Créer de l’abstraction.
Définition : En...
(Re)prise en main du projet
Partie 5 : Attention à la couche d'abstraction que l'on ajoute à l'outil
● Eviter les fichiers...
(Re)prise en main du projet
Partie 5 : Attention à la couche d'abstraction que l'on ajoute à l'outil
Pour la couche d’abst...
(Re)prise en main du projet
Partie 6 : outil de qualité de code
● Technologie PHP
○ PHPUnit (Test unitaire)
○ détecte/corr...
Documentation et Commentaires
phpdocumentor
URL - https://www.phpdoc.org/
Packagist - https://packagist.org/packages/phpdo...
Pratiques pour commenter
Aujourd’hui
● Aucune nomenclature existante pour les commentaires.
● Listes de règles de bonnes p...
Mauvaises pratiques de commentaire
● Commentaires qui paraphrase le code
● Commentaire non maintenu
● Manque d’imagination...
Bonnes pratiques pour commenter
● Quel est le pourquoi ?
● Clarifier quelque chose qui n'est pas lisible/compréhensible pa...
Bonnes pratiques pour commenter
Propositions de bon commentaire
● Quelque chose qui est clair et lisible pour vous n'est p...
Bonnes pratiques pour commenter
Propositions de bon commentaire
● Ceci est OK pour factorisation
// ce n'est pas mon meill...
merci
Prochain SlideShare
Chargement dans…5
×

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

281 vues

Publié le

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.

Publié dans : Internet
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

  1. 1. Comment récupérer un projet Web pourri... … et réussir à travailler dessus !
  2. 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. 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. 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. 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. 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. 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. 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. 9. (Re)prise en main du projet Partie 4 : Langages utilisées (et versions) ? ● Pour PHP ● http://php.net/manual/fr/appendices.php
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. merci

×