Hype driven developement

Mbechezi Nawo

Dev @Meero

@Shine_neko

Bridge lover

Dompteur de legacy

Techno

Docker

MySQL

GraphQL

React JS

Hadoop

Cloud (AWS, GCP, Azure)

MongoDB

Kubernetes

Microservice

ETC ...

J'aime le LEGACY

Legacy

Shame marketing strategy

Qu'est ce du legacy ?

Du vieux code plus maintenu ?
Du code code qui n'est pas écrit par moi ?
Un projet que personne ne comprend
Symfony 4 ?

Dette technique

Elle permet d'acheter une augmentation rapide du ROI pour le projet.
Mais avec un taux d'intéret élevé
Elle doit être explicite et générée consciemment avec le métier.
Le remboursement doit être obligatoire et les developpeurs doivent avoir carte blanche pour le remboursement.
Ne doit pas être une excuse pour faire n'importe quoi.

Role d'un développeur ?

Software is not a piece of art

~~Code is poetry.~~

Faire du refactoring

Supprimer du code

L'ECRITURE DE TESTS

RTFC

Lisez le code source

Open source ou pas

REVIEW DE CODE A FOND

Dev&OPS

N'est pas un métier

Ne doit pas dépendre d'une équipe

Le devops est un mouvement en ingénierie informatique et une pratique technique visant à l'unification du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment l'administration système.

Dev&OPS

Un déploiement régulier des applications, la seule répétition contribuant à fiabiliser le processus
Une pratique des tests dans un environnement similaire à celui de production
Une intégration continue incluant des tests continus
Une boucle d'amélioration courte (i.e. un feed-back rapide des utilisateurs)
Une surveillance étroite de l'exploitation et de la qualité de production factualisée par des métriques et indicateurs clés.

Dev&OPS

Si vous recrutez une personne avec un intitulé de poste Devops vous ne faites pas du devops

Architecture

Micro services Clean architecture
Command Query Responsibility Segregation(CQRS)
etc ...

Overengineering

L'optimisation prématurée est la racine de tous les maux (ou, du moins, la plupart d'entre eux) en programmation.

Overengineering

Dis moi de quoi tu as besoin, on va t'expliquer comment t'en passer !

Data driven development (DDD²)

Tracing, Monitoring & Logging

Dev&Archi

Architecture decision record (ADR)
https://github.com/joelparkerhenderson/architecture_decision_record

Architecture decision record

L'importance du contexte

Pourquoi on a mis ça en place déjà ? : "C’est historique"

Permet d'avoir les tenants et les aboutissants sur les décisions d'architecture et de design
Permet d'écrire peu de documentation mais, une documentation utile<

Architecture decision record

Title
Décideurs ( Qui était impliqué dans la prise de décision)
Contexte : Qu’est-ce qui, dans l’architure actuelle, a fait que l’on a dû arriver à cette décision.
Décision : Ce qui a été décidé, c’est-à-dire le changement qui est proposé (ou qui va être mis en place quand on écrit l’ADR un peu tard)..
Statut : L’état : Proposé, Accepté, Rejeté, Déprécié, Remplacé
Conséquences : Quelles sont les nouvelles choses que l’on va devoir gérer suite à cette décision.

Faites simple