Présentation donnée à l’afup day Lille 2019.

1. Une application sans framework en 2019
Afup day Lille 2019 - Rodrigue Villetard

2. Mon contexte
- Application dite “de gestion”
- Durée de vie de l’application estimée à 5+ années
- Rythme d’évolution en dents de scie
- Peu de contraintes de performance
- Développement en solo
- Engagé sur la maintenance

3. Mon objectif en tant que développeur
- Développer et livrer le premier lot : être payé
- Avoir un coût de maintenance réduit sur la durée de vie du projet
- Réduire la frustration de devoir retourner sur un “vieux” projet

4. La tentation des « getting started in less than 5 »
- Démarrage et livraison ultra rapide des premières itérations
- Pas de question existentielle : on suit les bonnes pratiques
- On dégoupille du CRUD à la seconde avec les générateurs cli
- Le projet avance bien dès le début, tout le monde est content et on se
concentre sur le swag pour les démos clients.

5. Sauf que…
On réalise souvent tardivement que l’application ne se
résout pas à quatre lettres.
Productivité
Vie du projet
Première fonctionnalité
autre que CRUD,
Et premier bidouillage
Coincé dans le CRUD !

6. Sauf que…
Ces 5 dernières années :
- 3 versions majeures de symfony
- 10 versions majeures de laravel
- Incertitudes Zend framework <> laminas
- Silex abandonné
- …
Retourner 2 ans plus tard sur un projet avec 3 versions majeures de retard, c’est pénible.
Faire les montées de versions, c’est pénible
Reprendre les anciennes bonnes pratiques, c’est pénible

7. Encore en plus que…
Les frameworks ne viennent pas seuls : chacun y va de son système d’extension
(Bundles, Plugins, etc.)
Le cycle de vie des extensions est généralement plus imprévisible que celui des
frameworks.
FosUserBundle anyone?

8. Mais quand même…
- Documentation
- Qualité générale
- Communauté
- Rapidité de développement
- Intégration de nouveaux développeurs sur le projet
- Curiosité d’essayer les nouveautés
- …

9. Conclusion sur les tentations
Dans mon cas, j’ai favorisé la stabilité dans le temps de mon projet plutôt que de profiter des
atouts d’un framework.
(et faut bien avouer que ça avait l’air d’être un exercice de style rafraîchissant)

10. Choix de la philosophie et de l’architecture du projet
- Domain Driven Design
- Hexagonal architecture
- CQRS simplifié
- Post inheritance age of OOP

11. Domain Driven Design (Kent Beck)
Couplage intense entre l’organisation du métier et l’implémentation logicielle

12. Architecture hexagonale (Alistair Cockburn)
Aucune classe ou interface tierce
À l’intérieur de l’hexagone !
Les drivers et adapters font le pont
entre notre système et leur fonction.

13. CQRS Simplifié
Point d’entrée **unique** dans l’hexagone

14. Post inheritance age of OOP

15. Sauf que…
Productivité ressentie (et réelle) au début du projet

16. Premier retour d’expérience
L’implémentation des infrastructures (base de données, router et inversion de contrôle
notamment) est consommatrice de temps, complexe et sans réel intérêt pour l’application.
Chaque petit pas en avant nécessite une réflexion sur l’architecture (et ralenti
l’implémentation)
Le réflexe primaire de recréer un framework est un combat de chaque instant

17. Intégration sous contrôle de librairies tierces
- Se prémunir des breaking change
- Restreindre la surface exposée à ce qui est utilisé par
l’application
- Homogénéité du “style” de l’application
On bénéficie alors d’implémentations éprouvées, sûres et de qualités sans
affaiblir ou tordre notre architecture.
Ma règle sur ce projet : Les librairies tiers n’ont pas le droit d’
être visibles depuis l’intérieur de l’hexagone :

18. Productivité
Intégration de librairies tierces
Effet positif des librairies tierces

19. Composer.json

20. - Éviter au maximum les implémentations astucieuses
- Typage le plus fort possible (ValueObjects, Interface, Type hints)
- Utilisation d’outils d’analyses statiques (phpstan)
- Tests unitaires (phpunit)
- Tests fonctionnels (behat)
- Clean code et lint (php-cs-fixer)
- Intégration continue sévère
- Choix de dépendances à faible risque
Stratégie de maintenance facile en place

21. - Vivre le stress
- Vivre le doute du client face aux premières livraisons
- Vivre l’aventure et les grandes (re)découvertes
- Un voyage qui se prépare
Conclusion, se passer d’un framework, c’est :

22. Rendez-vous dans 5 pour vous dire si ça valait le
coût !

23. Kudos techniques et communautaires

24. Merci, mangez des pommes et bon week end !
Rodrigue Villetard – @gorghoa
=