Paris Web 2015 - Atelier désendettement Javascript legacy

1

Tél : +33 (0)1 58 56 10 00Fax : +33 (0)1 58 56 10 01www.octo.com© OCTO 2015

50, avenue des Champs-Elysées75008 Paris - FRANCE

Atelier Paris Web 2015

Michael AKBARALY @Chehcheucheh

[email protected]

François PETITIT@francoispetitit

[email protected]

2

Présentation

Michael AKBARALYFrançois PETITIT

OCTO TechnologyConsultants chez Canal+, FranceConnect…Ref card « Tests sur tous les fronts »http://blog.octo.com

3

Quand on commence un projet de zéro…

Usine de Build

Build

Compiler

Déposer

Référentielbinaires

Référentiel de tâches

et anomalies

Documentation& Indicateurs

Serveurd’intégration

continue

BuildGestionnaire de sources

BuildLocal

Notifications

Exécuter les tests

Vérifier la qualité du code

Documenter

Récupérer les dépendances

Packager

4

Travailler sur du legacy : les livres de référence

5

Du code ‘legacy’, c’est quoi?

6

Eco-système Javascript: vous n’avez pas d’excuse!

7

Types de tests

8

https://github.com/octo-web-front-end-tribe/ka-ching

9

10

Les grandes étapes

Faire tourner l’application

Faire une analyse statiqueNombre de ligne de codes par fichiersCouverture de code par les testsCalcul de la complexité cyclomatique…

Regarder le code à la main pour voir la tête du codeCode non formaté !On n’a pas de test !On n’a pas de gestion des ressources front-end !…

Démarche pour un audit express

11

ObjectifVisualiser certaines métriques sur le code : couverture par les tests, complexité cyclomatique, nombre de lignes de code…

CommentAvec Plato.js :

https://github.com/es-analysis/plato

Npm install –g platoCôté back-end :

plato -d report -x node_modules/ index.jsCôté front-end :

plato -r -d report -x node_modules/ app/scripts

Analyse statique de code

12

Améliorations – axe qualité du code

Modification Avantages Criticité Complexité

Améliorer la couverture de tests côté API puis front-end

• Améliorer la maintenabilité

+++ +++

Mettre en place des normes de formatage

• Améliorer la lisibilité du code• Permettre d’avoir des diffs Git utiles +++ +

Mettre en place un outil de linting

• Eviter des erreurs de code détectables par des outils +++ +

Supprimer les duplications de code

• Eviter des régressions en oubliant de faire évoluer chaque version ++ ++

Supprimer le code mort

• Améliorer la lisibilité du code + +

13

Modification Avantages Criticité Complexité

Mettre en place un build automatisé Gulp pour le front

• Mettre en place des tests unitaires côté front-end

• Outillage JS dédié pour optimisation des ressources

+++ ++

Automatiser les tests • maintenabilité +++ +

Améliorations – axe build

14

Modification Avantages Criticité Complexité

Optimiser les ressources statiques front-end

• Améliorer les performances+ ++

Déployer les ressources statiques en-dehors du serveur NodeJS (serveur HTTP, CDN…)

• Améliorer les performances• Décharger le serveur d’application

+ ++

Améliorations – axe run

15

Formater le codeMettre en place un outil de « linting » de codeMettre en place une couverture de tests minimale

D’abord côté APIPuis côté front-end

Supprimer le code mortSupprimer les duplications de code

En vérifiant la non-régression via des tests unitaires

Feuille de route

16

ObjectifRendre le code plus facile à lire

Comment faireLa fonction de formatage de notre IDE (WebStorm + ESLint) ?Un outil en ligne de commande : JS-Beautify : https://www.npmjs.com/package/js-beautify

Npm install –g js-beautifyjs-beautify -f ./app/modules/**/* -r

Formatage de code JavaScript

17

Comment le rendre pérenne Intégration de ESLint au build

Linting

18

ObjectifAvoir un harnais de tests de non-régressions sur l’API pour pouvoir la faire évoluer sereinement

CommentMettre en place des tests de non-regression HTTP avec SuperTest (https://github.com/visionmedia/supertest )Bouchonner les données de baseAjouter ces tests au build (attention : nécessite de déployer l’application)

Le codeBranche « api-integration-tests »https://github.com/octo-web-front-end-tribe/ka-ching/tree/api-integration-tests

Tester l’API en boîte noire

19

GET /api/friends/Prends en entrée l’id de l’utilisateur courantRenvoie la liste de ses amis

Les étapes :Mettre en place un jeu de données significatif pour l’API à testerImplémenter le testAutomatiser l’exécution du test à chaque build

Exemple : l’API à tester

Supertest Should

20

ObjectifsMieux visualiser comment fonctionne l’application au runtimeSupprimer le code non utiliséVisualiser le code non testé

Comment ?Istanbul pour visualiser la couverture par les tests :

https://github.com/gotwarlost/istanbul Istanbul-middleware pour instrumenter à l’exécution

https://github.com/gotwarlost/istanbul-middleware

Analyse dynamique : détecter le code mort côté back

21

ObjectifsPoser un harnais de test pour pouvoir ensuite modifier le code front-end

Comment Avec PhantomCSS

https://github.com/Huddle/PhantomCSS

Exemplehttps://github.com/octo-web-front-end-tribe/ka-ching-phantomcss

Ajouter de la non régression sur l’IHM en mode boîte noire

22

ObjectifDétecter le code dupliquéSupprimer sans risque les duplications

Comment ?JSInspect pour analyser le code et détecter les duplicationsMise en place de tests unitaires pour sécuriser les appels aux fonctions dupliquésRefactoring pour supprimer les doublonsS’assurer que les tests fonctionnent toujours

Supprimer le code dupliqué