Découper un problème en plusieurs problèmes plus simples
Low coupling, high cohesion, maintainability, extensibility, reusability.
Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter.
Premature optimization is the root of all evil
Ajouter des personnes à un projet en retard accroît son retard
Adding manpower to a late software project makes it later
Neuf femmes ne font pas un enfant en un mois
80 % des effets sont le produit de 20 % des causes
Les organisations à l’origine des architectures doivent refléter le système en lui-même.
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
“The structure of a problem reflects the structure of the organization that created it.” Bill Corcoran’s version of Conway’s Law
Pour un projet innovant, il faut multiplier l’estimation initiale des coûts par 3,14.
Plus on a de temps pour réaliser une tâche, plus cette tâche prend du temps.
Toute chose prend plus de temps qu'on ne l'avait prévu
Au delà d'un certain seuil de travail, l'efficacité décroit
Faire un travail de façon continue prend moins de temps que de le faire en plusieurs fois
1 heure n'est pas toujours égale à 1 heure
Ne parlez qu'à vos amis immédiats
La notion fondamentale est qu'un objet devrait faire aussi peu d'hypothèses que possible à propos de la structure de quoi que ce soit d'autre, y compris ses propres sous-composants.
Exemple concret par Misko Hevery
Always implement things when you actually need them, never when you just foresee that you need them. (Ron Jeffries)
You aren't gonna need it : en.wikipedia.org
Plusieurs solutions de gestion des repos/projets :
défaut des 2 premiers : Dependency Hell.
avantages du monorepo :
inconvénients du monorep :
impact git :
Le monorepo est la pratique actuelle des géants comme Google et Facebook.
Exemple Google (janvier 2015) :
Why Google Stores Billions of Lines of Code in a Single Repository : Rachel Potvin@Google 20150914
Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day.
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
Continuous deployment means that every change is automatically deployed to production.
Semantic Versioning with Continuous Deployment by Mark Seemann : blog.ploeh.dk
feature-flipping : blog.octo.com
feature flags explained : featureflags.io (very good link, with lots of use case, eg : early access)
drawback
Settings are evil - MPJ's Musings - FunFunFunction #62
TLDR : Feature toggle generate combinatorial explosion of test cases -> lower quality
Martin Fowler deal with this question in his feature toggle article :
A common question we hear about feature toggles concerns testing - does using feature toggles mean a combinatorial explosion of tests? In general there's no need to test all combinations of features. For release toggles it's usually sufficient to run two combinations :
- all the toggles on that are expected to be on in the next release
- all toggles on
This is pretty much the same as what you need to do with feature branches if you want to find any integration bugs.
It's very important to retire release toggles once the pending features have bedded down in production. This involves removing the definitions on the configuration file and all the code that uses them. Otherwise you will get a pile of toggles that nobody can remember how to use. In one memorable example I heard of, it required making a special recompilation of the linux kernel to handle enough command line switches.
Feature branches vs. feature toggles : fournines.wordpress.com : 20111120
The biggest mistake you can make when deciding on how to use branches is trying to define "one branching strategy to rule them all".
Feature toggle should not be systematicly used. It should be only if the team experience pain merges.
Features branches cons :
- the feature branch is not merged in the mainline, so there is no CI on it
- concurrent feature branch works can lead to big conflicts when merging. The last team to merge will have to handle all the issues.
Conflicts could symptomatic of underlying problems :
- poor design
- no cohesive view of the domain (no or bad modelization)
- or multiple logical views of the domain
- refactor-rage (a dev doing lot's of cow boy refactoring)
Feature toggle can be impl at build time or at runtime. Build time means you need several CI pipeline, run time increase increase code complexity.
Feature toggles are certainly an interesting concept, and seem to mesh well with the principle of building composable applications. However, they are not without their pitfalls, so if you are thinking about trying them out, make sure that they are the most appropriate solution to the actual problem that you’re trying to solve.
Robert Cecil Martin (Uncle Bob)
Eric Elliott : "Programming JavaScript Applications" (O’Reilly)
David Heinemeier Hansson (Creator of Ruby on Rails)
a été titulaire de la chaire de génie logiciel du Cnam. A dirigé les développements logiciels des ordinateurs Bull DPS7. Consultant en systèmes d’information auprès de grandes entreprises et administrations. Auteur de nombreux ouvrages sur le génie logiciel.
inventeur du datagramme et concepteur du premier réseau à commutation de paquets, à la base de ce qui deviendra Internet. Lauréat du Queen Elizabeth Prize for Engineering en 2013. Militant du multilinguisme dans l’espace numérique et d’une nouvelle gouvernance d’Internet
a été titulaire de la chaire des techniques fondamentales de l'informatique du Cnam, responsable de recherche à l'Imag, Bull et l'Ecole Polytechnique. Pionnier en France des architectures de circuits intégrés, en particulier sur leur preuve formelle et leur synchronisation interne.
Précurseur à l’INRIA de la notion de routeur de réseau, puis du poste de travail intelligent, en dirigeant le projet Kayak. Il a ensuite exercé des responsabilités de direction dans l’Industrie (Bull, EDS, Sabre, Prologue), et maintenant de conseil en management.
Daniel Glazman Former co-chairman of the W3C CSS Working Group
Rich Hickey Clojure author, The problems of programming
Top 10 Programming Books Every Software Developer Should Read
1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn't do this will be fired.
Agile : Are we building the right thing ?
Craftsmanship : Are we building the thing right ?
from Software Craftsmanship by Sandro Mancuso @ Devoxx France 20??
Conférences
odyssée du Continuous Delivery Diego Lemos David Caramelo (Nicolas Bourgeois) Présentation Devoxx2016 sur le passage du code legacy au continuous delivery à la Société Générale. Juste génial.
SOAT Agile Day - Keynote de Romain Niccoli - Etre agile dans un contexte de forte croissance
Architectural patterns - www.dossier-andreas.net
- Model-View-Controller
- Presentation-Abstraction-Control
- Pipe-And-Filter
- Layered Systems
- Microkernel
- Client-Server and N-Tier Systems
- Repository
- Blackboard
- Finite State Machine
- Process Control
- Multi Agent System
- Broker a.k.a. Service Oriented Architecture
- Master-Slave
- Interpreter a.k.a. Virtual Machine
- Hub-And-Spoke
- Message Bus a.k.a. Event Bus
- Structural Model
- Ports-And-Adapters a.k.a. Hexagonal Architecture
- Peer-to-peer
- Event sourcing
- CQRS
La Clean Architecture : catalyseur de productivité - medium.com/@mickalwegerich - 20180507
Pérennisez votre métier avec l’architecture hexagonale ! - blog.xebia.fr - 20160316
Robert C Martin - Clean Architecture and Design - www.youtube.com - 2013
Robert C Martin - A Little Architecture - blog.cleancoder.com - 20160104
Ports-And-Adapters / Hexagonal Architecture - www.dossier-andreas.net
Architecture hexagonale pour les nuls (Y. Chéné) - DevoxxFrance 2018
a substituer à l'architecture en couche connue de tous
tackling complexity in the heart of software (Eric Evans 2003)
"ports and adapters architecture" ou "Object Structural" ou "Hexagonal Architecture" (cf Alistair Cockburn)
Archi similaires : Clean Architecture, Onion Architecture
Règle 1 : Pas de framework ou de dépendances sur le domaine, on écrit tout en vanilla (on peut avoir éventuellement des dépendances sur des libs générales, par ex en js ça serait lodash)
Règle 2 : Le domaine est le central, c'est l'extérieur qui appelle le domaine. Le domaine n'appelle jamais l'extérieur. Il ne doit donc jamais y avoir de code d'infra dans le domaine, en d'autres termes toutes les I/O sont à l'extérieur.
le reste de la prez il commente un exemple avec Spring Boot
Software Architecture & Design Tutorial - www.tutorialspoint.com
The worst mistake of computer science - www.lucidchart.com/techblog - 20150831
In commemoration of the 50th anniversary of Sir Hoare’s null, this article explains what null is, why it is so terrible, and how to avoid it.