Help

Comment est conçu Paheko ?

Le design de Paheko est basé sur plusieurs concepts :

  • Simplicité : les fonctionnalités doivent être le plus simple possible à utiliser par les utilisateurs finaux
  • Intuitivité : il ne doit pas y avoir besoin de lire 200 pages de manuel pour comprendre comment ça marche, tout doit être clair et expliqué dans l'interface elle-même
  • Flexibilité : Paheko doit pouvoir convenir à l'utilisation de 95% des petites et moyennes associations
  • Puissance : Paheko doit permettre une utilisation avancée, qui peut être apprise progressivement, mais pas au détriment de la simplicité

Développement

Au niveau du développement nous suivons les principes suivants :

  • Durabilité : le logiciel doit encore fonctionner dans 10 ans et rester maintenable.
  • Eco-conception : le code doit être léger en ressources serveur et client, réduisant la consommation énergétique du matériel utilisé (voir notamment Eco-conception web car la plupart des sites web sont inutilement lents)
  • Artisanat : Paheko est construit comme un projet artisanal, avec l'amour du travail bien fait, mais aussi le plaisir de coder et de créer de nouvelles choses (et donc de réinventer la roue).
  • Amélioration progressive : le Javascript ne doit pas être nécessaire
  • Sécurité : faire en sorte que la conception et l'utilisation soit la plus sécurisée possible.

C'est pour cela nous utilisons peu d'outils existants : pas de framework PHP ou CSS. Nous utilisons en général les outils KD2 qui suivent les même principes. Ces briques logicielles sont réutilisables et éprouvées.

Comme Paheko est un projet artisanal et non pas industriel, il ne fait pas sens pour nous d'utiliser un framework lourd (comme Laravel ou Symfony), d'autant plus que leur durée de support ne convient pas au cycle de développement de Paheko. L'idée n'est pas d'utiliser des outils génériques qui ne sont pas adaptés à nos besoins, mais de trouver ou développer les solutions les plus adaptées, les plus légères, et les plus durables.

Ces choix se retrouvent au niveau de l'interface visuelle :

  • Nous n'utilisons pas de bibliothèque lourde populaire comme React, Bootstrap, etc. ces projets sont très bien mais lents et lourds et n'apportent rien dont nous n'ayons besoin ;
  • Les champs de formulaire ne sont pas stylisés, ils utilisent le style natif du navigateur, afin de rendre évident ce qu'ils sont et ce qu'ils font ;
  • Nous n'utilisons pas de design à la mode tel que "Material Design" ou autre car ces designs passent très vite de mode et ne sont pas étudiés pour une utilisabilité maximale et sont peu accessibles aux handicaps.

Durabilité

Comme souligné dans l'article de Bert Hubert sur le développement logiciel sur le temps long, Paheko vise un horizon de 10+ années lors de son développement.

Cela veut notamment dire :

  • Pas de framework :
    • les frameworks introduisent des changements importants tous les 2-3 ans, qui nécessitent de lourdes et complexes réécritures du logiciel. Cela force à passer beaucoup de temps à s'adapter au framework, temps qui n'est pas utilisé à la maintenance du code du logiciel lui-même.
    • entre le début du développement de Paheko et aujourd'hui (2024), Symfony a vécu 6 changements de versions majeures, nécessitant à chaque fois une réécriture partielle du code basé sur Symfony.
    • il est quasi-impossible de changer de framework
    • sans framework, il est plus simple de lire et maîtriser le code complet de l'application et ses dépendances
  • Pas de dépendance externe (ou très peu) :
    • le développement des dépendances va probablement être abandonné dans les 10 prochaines années, forçant à changer de dépendance, ou à reprendre la maintenance de cette dépendance
    • rien ne dit que ces dépendances sont bien écrites et ne contiennent pas de faille de sécurité. Il est généralement plus rapide et moins coûteux d'écrire une nouvelle librairie que de faire un audit de sécurité d'une librairie externe.
    • une dépendance qui contient plus de code que le logiciel lui-même est une aberration (en général)
    • on ne maîtrise pas le code ni le fonctionnement d'une librairie externe, à moins d'avoir fait une lecture et analyse poussée de son fonctionnement, ouvrant la voie à des bugs et détails non maîtrisés
  • Réduction du code :
    • moins il y a de code à maintenir, plus c'est facile à maintenir
  • Plus de documentation :
    • le code est commenté, car il faut penser aux autres personnes lisant le code, et au développeur original, qui plusieurs années plus tard aura oublié pourquoi iel a écrit ce bout de code comme ça…

Dépendances utilisées

  • Librairies KD2
  • SQLite3
  • PHP et ses extensions standard

Réinventer la roue n'est pas un problème !

Il est probable que de nombreuses parties de Paheko réinventent la roue, au sens que ces fonctionnalités existent déjà dans des librairies existantes. Mais réinventer la roue n'est pas un problème en réalité, c'est même un grand plaisir de développement. En plus cela permet souvent de mieux comprendre et maîtriser la problématique. Cela présente également un intérêt créatif et artistique certain (oui, le code c'est aussi de l'art).

C'est uniquement dans une entreprise capitaliste, dont le but est la rentabilité et donc la réduction des coûts, que le principe de ne pas réinventer la roue est pertinent. Dans ce cas il est dans l'intérêt de l'entreprise de réduire le temps de travail et produire vite, sans se soucier de la qualité et la longévité.

Pour Paheko la roue a été réinventée de nombreuses fois :

  • écriture d'un parser CSS en PHP
  • création d'un langage de templates (Brindille)
  • etc.

À chaque fois le résultat a été une solution plus légère, plus rapide, plus robuste et plus durable.

Voir aussi