genie logiciel

Génie Logiciel

principes

Découper un problème en plusieurs problèmes plus simples

Low coupling, high cohesion, maintainability, extensibility, reusability.

  • Loi de Hofstadter

Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter.

  • Donald Knuth à propos de l'optimisation prématurée

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.

  • Loi de Parkinson

Plus on a de temps pour réaliser une tâche, plus cette tâche prend du temps.

  • Loi de Murphy

Toute chose prend plus de temps qu'on ne l'avait prévu

  • Loi d'Illich

Au delà d'un certain seuil de travail, l'efficacité décroit

  • Loi de Carson

Faire un travail de façon continue prend moins de temps que de le faire en plusieurs fois

  • Loi de Fraisse

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

  • YAGNI (You aren't gonna need it)

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

Inversion of Control

normes

pratiques

monorepo

Plusieurs solutions de gestion des repos/projets :

  • 1 repo = 1 projet
  • 1 repo = 1 micro-service
  • monorepo (tout le SI est contenu dans un seul repo)

défaut des 2 premiers : Dependency Hell.

avantages du monorepo :

  • version unifiée du code
  • unique source de vérité
  • réutilisation intensive
  • gestion des dépendances simplifiées (tous les projets ont les mêmes versions)
  • collaboration inter-équipes améliorées (mais nécessite meilleure communication)
  • frontières des équipes et code ownership flexibles (résoud le problème levé par la loi de Conway)

inconvénients du monorep :

  • difficulté à faire des montées de version des dépendances (puisque tout le monde est impacté)
  • investissement très lourd du tooling pour gérer les projets
  • sécurité du code (tout le monde a tout le code)

impact git :

  • généralement on fait du feature branching (rend difficile la collaboration)
  • monorepo impose le trunk based development (commit quotidiens sur le trunk + feature toggle)

Le monorepo est la pratique actuelle des géants comme Google et Facebook.

Exemple Google (janvier 2015) :

  • 1 repo (exclus : Chrome, Android, ...)
  • 25K ingés
  • 1 milliard de fichiers
  • 35 millions de commits
  • 9 millions de fichiers sources
  • 2 milliards de lignes de code

Pourquoi votre entreprise devrait stocker l'ensemble de son code dans un seul repo (Thierry Abaléa) Devoxx2017

Why Google Stores Billions of Lines of Code in a Single Repository : Rachel [email protected] 20150914

continuous integration

wikipedia

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

wikipedia

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

wikipedia

Continuous deployment means that every change is automatically deployed to production.

continuous delivery / deployment and semver

Semantic Versioning with Continuous Deployment by Mark Seemann : blog.ploeh.dk

feature flipping

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.

méthodes

waterfall

cycle en V

agiles

auteurs

histoire

  • Software crisis Fin des années 70, les ordinateurs sont montés en puissance, donc permettent le développement de programmes plus puissants et plus complexe. Dégradation massive de la qualité du à la complexité. C'est le début des recherches en génie logiciel pour définir les bonnes pratiques du développement logiciel (gestion qualité, méthodes, invention programmation procédurale puis objet).
  • bulle internet Fin 90 début 2000 le crash boursier entraine de nombreux licenciements de développeurs suite aux réductions du couts et aux sociétés déposants le bilan. Les développeurs ont alors tendance à se transformer en oui:oui pour éviter de perdre leur emploi, entrainant une dégradation massive de la qualité des productions. Ce phénomène associé à l'arrivée de nombreux jeunes développeurs sur le marché du travail quelques années après sont les deux phénomènes responsables de l'immaturité de l'industrie du développement logiciel dénoncée par Robert C. Martin (cf Martin pour une explication plus détaillée dans The Future of Programming)
  • Jeff Bezos API Mandate explained by Google employee

    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.

courants

Software Craftmanship

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

exemples concrets

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

architecture

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

clean architecture

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

Podcast Les vices de l'agilité - Choisir les technos avant de commencer à coder - Mickael Azerhad - 20180725

Software Architecture & Design Tutorial - www.tutorialspoint.com

divers

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.

results for ""

    No results matching ""