par Michael Akbaraly et François Petitit - OCTO Technology Vous avez récupéré un projet JavaScript de plusieurs milliers de lignes, on vous demande des évolutions et des corrections de bugs, et rien ne va. Code illisible, régressions en pagaille, structure des répertoires incompréhensibles : vous ne savez pas par où commencer ! Au long des 90 minutes de cet atelier, nous vous proposons de découvrir les techniques et les outils qui vont vous sauver la vie via des travaux pratiques de code JavaScript côté back-end avec NodeJS, et côté front-end avec AngularJS. Débutants ou ayant déjà une connaissance de ces technologies sont les bienvenus. Les travaux pratiques seront disponibles si vous souhaitez coder vous-mêmes pendant l'atelier.

1. 1
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2015
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Atelier Paris Web 2015
Michael AKBARALY
@Chehcheucheh
makbaraly@octo.com
François PETITIT
@francoispetitit
fpetitit@octo.com

2. 2
Présentation
Michael AKBARALY
François PETITIT
OCTO Technology
Consultants chez Canal+,
FranceConnect…
Ref card « Tests sur tous les
fronts »
http://blog.octo.com

3. 3
Quand on commence un projet de zéro…
Usine de Build
Build
Compiler
Déposer
Référentiel
binaires
Référentiel
de tâches
et anomalies
Documentation
& Indicateurs
Serveur
d’intégration
continue
BuildGestionnaire
de sources
Build
Local
Notifications
Exécuter les tests
Vérifier la qualité
du code
Documenter
Récupérer
les dépendances
Packager

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

5. 5
Du code ‘legacy’, c’est quoi?

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

7. 7
Types de tests

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

9. 9

10. 10
Les grandes étapes
Faire tourner l’application
Faire une analyse statique
Nombre de ligne de codes par fichiers
Couverture de code par les tests
Calcul de la complexité cyclomatique
…
Regarder le code à la main pour voir la tête du code
Code 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. 11
Objectif
Visualiser certaines métriques sur le code : couverture par les tests,
complexité cyclomatique, nombre de lignes de code…
Comment
Avec Plato.js :
https://github.com/es-analysis/plato
Npm install –g plato
Côté back-end :
plato -d report -x node_modules/ index.js
Côté front-end :
plato -r -d report -x node_modules/ app/scripts
Analyse statique de code

12. 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. 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. 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. 15
Formater le code
Mettre en place un outil de « linting » de code
Mettre en place une couverture de tests minimale
D’abord côté API
Puis côté front-end
Supprimer le code mort
Supprimer les duplications de code
En vérifiant la non-régression via des tests unitaires
Feuille de route

16. 16
Objectif
Rendre le code plus facile à lire
Comment faire
La 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-beautify
js-beautify -f ./app/modules/**/* -r
Formatage de code JavaScript

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

18. 18
Objectif
Avoir un harnais de tests de non-régressions sur l’API pour pouvoir la
faire évoluer sereinement
Comment
Mettre en place des tests de non-regression HTTP avec SuperTest
(https://github.com/visionmedia/supertest )
Bouchonner les données de base
Ajouter ces tests au build (attention : nécessite de déployer
l’application)
Le code
Branche « 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. 19
GET /api/friends/
Prends en entrée l’id de l’utilisateur courant
Renvoie la liste de ses amis
Les étapes :
Mettre en place un jeu de données significatif pour l’API à tester
Implémenter le test
Automatiser l’exécution du test à chaque build
Exemple : l’API à tester
Supertest Should

20. 20
Objectifs
Mieux visualiser comment fonctionne l’application au runtime
Supprimer 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. 21
Objectifs
Poser un harnais de test pour pouvoir ensuite modifier le code front-end
Comment
Avec PhantomCSS
https://github.com/Huddle/PhantomCSS
Exemple
https://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. 22
Objectif
Détecter le code dupliqué
Supprimer sans risque les duplications
Comment ?
JSInspect pour analyser le code et détecter les duplications
Mise en place de tests unitaires pour sécuriser les appels aux fonctions
dupliqués
Refactoring pour supprimer les doublons
S’assurer que les tests fonctionnent toujours
Supprimer le code dupliqué