Essential skills for the agile developer
•Télécharger en tant que PPTX, PDF•
0 j'aime•1,335 vues
Présentation BDX.IO Octobre 2015
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
En vedette (7)
Similaire à Essential skills for the agile developer
Similaire à Essential skills for the agile developer (20)
Plus de Alice Barralon
Plus de Alice Barralon (10)
Essential skills for the agile developer
- 1. 1 Qualités essentielles pour un développeur agile A. Barralon a.barralon@oriions.com @a_barralon
- 2. 2 Essential skills for the agile developer : a guide to better programming and design Ionic Angular JS Spark Git Hadoop …
- 3. 3 Essential skills for the agile developer L’informatique est non prédictive. La technologie est un outil au service du développeur.
- 4. 4 Essential skills for the agile developer Le design et la complexité d’un système sont difficiles à cadrer en totalité en amont d’un projet. Complexité simplifiée + Design minimaliste
- 5. 5 Essential skills for the agile developer Trim-tabs essentiels : 1. Programmation par intention 2. Séparer l’usage et la construction 3. Considérer les tests avant d’écrire le code
- 6. 6 Programmation par intention Découpe le problème en étape fonctionnelle (bullet points) : 1 classe == 1 responsabilité • on prend une ‘commande’ à commiter • on tokenize la commande • on normalise les tokens • on traite selon les cas de la taille des tokens • on retourne le résultat
- 7. 7 Programmation par intention Avantages : + cohésion + lisibilité + simple à débugguer + simple à réfactorer + simple à unit-tester
- 8. 8 Séparer l’utilisation de la construction On sépare l’utilisation de l’instantiation. • création d’une instance d’un Service • on le délègue pour effectuer d’autres tâches
- 9. 9 Séparer l’utilisation de la construction Créateurs (:type) : WHAT something IS Utilisateurs (:interface) : HOW something operates “what you hide you can change”
- 10. 10 Séparer l’utilisation de la construction
- 11. 11 Définir les tests en amont Les tests et la qualité du code “je ne peux pas tester ce code…” • car il fait trop de chose entremêlées -> (problème de cohésion) • car j’ai besoin d’une douzaine d’autre chose → couplage excessif • car c’est du code copié dans pleins d’endroits et modifiés à certains points → redondance
- 12. 12 Définir les tests en amont Les programmeurs grenouille • Planification (l’action de faire un plan d’ensemble) → écrire les specs de test • Plan (description des différentes étapes) → écrire les tests • Suivre le plan (effectuer les étapes) → jouer les tests
- 13. 13 Conclusion Lire, c’est prendre des risques, parfois se mettre en danger. Non, ce n’est pas un acte neutre et divertissant. C’est un exercice de liberté, et nous en restons rarement indemnes. Mais une chose est certaine, palpable, et cette expérience peut être faite par chaque lecteur, nous agrandissons notre Moi, nous sortons de nos prisons mentales, nous déverrouillons notre regard sur le monde, dans l’acte de lire.
- 14. 14 Merci !
Notes de l'éditeur
- Bonjour, j’ai choisi ici de vous parler d’un livre et non pas d’une technologie. Ce livre s’intitule ‘Essential Skills for the agile developer : a guide to better programming and design’. C’est un livre au look carrément ringard, édité la 1ere fois en 2011. C’est sûr quand on compare avec les autres pitch de l’événement sur AngularJS, Ionic, l’API Rest, Spark, etc. ; vous pouvez vous demander ce que vous faires ici. Une blonde qui parle d’un bouquin, au secours… c’est le moment de partir à votre cours d’aqua-poney.
- Pourquoi j’ai choisi de présenter un livre? Car l’informatique est en constante évolution. On ne peut pas prédire le futur. On ne peut pas assumer à ce jour si TypeScript va supplanter Angular, si Ionic va faire un flop ou pas. Depuis 10 ans on spécule sur la mort du Javascript qui est présent plus que jamais. Lorsque je suis arrivée dans le monde du travail, il y a quelques années déjà, j’étais jeune , je parlais techno et versionning. Pour moi connaître le numéro de la dernière version de JAVA, Tomcat, Postgres était une manifestation de ma ‘culture ‘informatique. Je l’affichais fièrement dans mon CV. 10 ans plus tard, j’ai eu la chance de participer à un groupe de travail leadé par Julien Dollon (dev chez Microsoft puis chez Amazon US qui a fait table rase de mes grands principes pour m’ouvrir les yeux sur le fait que la technologie est un outil au service du développeur. C’est un peu comme un mécanicien. Il peut être équipé d’un tournevis manuel ou d’une visseuse électrique, s’il ne sait pas ou trouve la panne ses outils ne lui servent à rien. Le principe s’applique aussi en informatique ou un algo peu performant le restera quelle que soit la techno utilisée. C’est important de garder à l’esprit qu’on ne fait pas de choix technologique parce que c’est cool, ça le fait bien sur un CV, on a envie de se faire plaisir et de joue un peu. Mais qu’on analyse les besoins techniques pour en déduire la technologie à utiliser.
- Dans son livre Alan Shalloway part de ce constat : Le design et la complexité d’un système sont difficiles à cadre en totalité en amont d’un projet. Quand un besoin est recueilli, un cahier des charges est posé mais on a pas la visibilité complète sur l’ensemble du projet. On y va mais on ne maitrise pas toujours ou on va. La plupart du temps la complexité est très simplifiée et le design est minimaliste (la V1 inclut le minimum syndical pour faire fonctionner le système). Par ailleurs, en admettant que les fonctionnalités soient TOUTES analysées en amont du projet, la demande des utilisateurs et le marché font que des ajustements sont nécessaires: On se confronte à des besoins de réfactorisation (le nettoyage du code, le changement de structure en préservant le comportement) L’amélioration du système (ajout ou modification de comportement pour matcher un besoin) L’objectif étant d’avoir des coûts réduits (en terme de temps de développements) , sans effets de bord, sans bugs, sans retour arrière dans les fonctionnalités. C’est important que chaque développeur ait en tête que son code n’est pas immuable et qu’il est amené à être refactorisé, et à évoluer.
- En introduction du livre, Alan Shalloway pose donc 3 trim-tabs (principes fondamentaux): Trim-tabs essentiels : Programmation par intention Séparer l’usage et la construction Considérer les tests avant d’écrire le code Je vais vous les présenter rapidement.
- La programmation par intention consiste à découper le problème à résoudre en étape fonctionnelle (en bullet points). Un exemple de code qui parle de lui-même Par exemple : 1 classe à 1 responsabilité. L’interprétation et la compréhension rapide du code se fait comme suit : on prend une ‘commande’ à commiter on tokenize la commande on normalise les tokens on traite selon les cas de la taille des tokens on retourne le résultat Les commentaires de code sont en réalité les noms des méthodes. C’est simple, rapide et efficace. Le contraire de la politique ou à la fin de la réflexion, on ne se rappelle plus le sujet de la question posée.
- Les avantages sont nombreux : + cohésion + lisibilité + simple à débugguer + simple à réfactorer + simple à unit-tester
- Lorsqu'on a besoin d’une nouvelle fonctionnalité, on passe plus de temps à l’intégrer plutôt qu’à l’implémenter. L’ajout ou modification de fonctionnalité nécessite de changer le code client qui peut rapidement devenir un problème (source de bug, réfactoring complexe, etc.). Quand on change du code client, on doit faire attention au type des objets (sauf cas des classes abstraites). D'où l’intérêt de cacher (=d’encapsuler) l’implémentation de ces objets. Le fait de cacher l’implémentation est très important, car il permet de pouvoir la changer sans modifier les clients qui l’utilisent. Un exemple très simple. - création d’une instance d’un Service on le délègue pour effectuer d’autres tâches Même si cette façon de faire parait naturelle, c’est une erreur qu’il faut éviter. En effet la classe BusinessObject est créateur et utilisateur du service. Il faut séparer cette relation. Dans des langages fortement typés tels que Java ou C#, le mot clé new créé une instance typée d’un objet concret, en d’autre terme, ce n’est pas une classe abstraite ou une interface. Si on remplace Service myServiceObject = new Service Par : Service myServiceObject = new Service_Impl on aura une erreur de compilation.
- On peut donc changer ce que l’on cache les créateurs sont couplés au type (‘new’ créé un objet concret typé ; on ne peut pas faire new ClasseAbstraite() ) -> lié à l’instantiation mémoire de l’objet WHAT something IS les utilisateurs sont couplés à l’interface (ex : web services : fournissent un API pour utiliser le service) HOW something operates Ils doivent être utilisés séparément car les 2 partis peuvent changer pour différentes raisons. Mantra à se rappeler “what you hide you can change” → encapsulation Garder à l’esprit qu’un changement peut entraîner des effets de bords. Donc on change une interface si et seulement si le client (qui consomme le service) a un nouveau besoin et non pas pour une implémentation spécifique du code (ou un caprice du développeur).
- Penser à faire du design minimal. On ne peut pas prédire si une classe va changer dans le futur. Ne pas faire de l’over-design… La pratique minimum à engager quand il n’y a pas de complexité justifiée est la recommandation suivante :
- Avec l’avènement des méthodes agiles, le TDD (Test Driven Developpement) a gagné de l’importance. L’un des mantra de l’agilité est que chaque ‘story’ est complète à la fin de l’itération (tests compris!). La testabilité est fortement corrélée avec la qualité du code (perte de couplage, cohésion, pas de redondance).Lorsqu’on commence les tests, on se trouve face à des problématiques de type : “je ne peux pas tester ce code…” car il fait trop de chose entremêlées” -> (problème de cohésion) car j’ai besoin d’une douzaine d’autre chose → couplage excessif car c’est du code copié dans pleins d’endroits et modifiés à certains points → redondance Il faut considérer comment le code va être testé avant de l’écrire.
- Comme la théorie de la grenouille de Platon, les programmeurs ne remarquent pas la dégradation de leur code. Au début les développeurs sont très vigilants et petit à petit le laxisme s’installe jusqu’au point de non retour. Il faut faire preuve de discipline. Ne pas ajouter de fonctionnalité dont on a pas besoin au moment présent. La planification des tests se fait en 3 étapes: Planification (l’action de faire un plan d’ensemble) → écrire les specs de test Plan (description des différentes étapes) → écrire les tests Suivre le plan (effectuer les étapes) → jouer les tests
- EN conclusion je n’insisterai jamais assez sur l’importance de lire et le capital intellectuel que l’on se créé. Une personne qui lit en moyenne un livre par mois, elle capitalisera 10 livres sur une année. Rendez-vous compte de l’importance et du savoir qu’elle aura accumulé sur une carrière et une vie.