Chaque projet logiciel a sa propre aura. Cette aura existait avant même le début du projet. Il a donné naissance au projet et sera vivant lorsque le projet sera déclassé et/ou remplacé par un autre projet. Cette aura est Le contexte complet.
Le contexte complet se compose de toutes les informations directement ou indirectement liées au projet. C’est la seule source de vérité pour chaque décision liée au projet, de la décision de le démarrer au nom de chaque variable dans le code.
Le contexte complet est extrêmement volumineux et contient de nombreuses informations commerciales, économiques et politiques, telles que les finances de l’entreprise, l’influence de personnes ou de groupes sur des décisions particulières, ou même l’état d’esprit du développeur qui a affecté une décision particulière.
Traiter de telles quantités d’informations n’est possible qu’en les superposant dans une hiérarchie d’abstractions. Chaque couche de la hiérarchie est constituée d’éléments — chaque élément peut être considéré comme un mot, et l’ensemble des éléments au même niveau d’abstraction : le langage. Ce langage est ensuite utilisé par la couche d’abstraction suivante pour exprimer des mots utilisés par la couche supérieure, et ainsi de suite.
Dans la plupart des cas, il n’y a pas d’abstraction « racine » unique ni de hiérarchie unique d’abstractions. Au lieu de cela, les informations de contexte sont structurées comme un ensemble de hiérarchies indépendantes.
Il convient de noter qu’une superposition stricte d’abstractions est essentielle pour garder le contexte compréhensible. Les abstractions qui fuient vers les niveaux supérieurs peuvent entraîner une croissance incontrôlée de la complexité et faire du contexte un désordre incompréhensible.
Le contexte
La structure hiérarchique du contexte nous permet d’extraire uniquement la partie technique de Le contexte complet, c’est-à-dire la partie directement liée au projet. Appelons cette partie Le contexte limitéou simplement Le contexte. Cette partie du contexte complet est la seule habituellement nécessaire au développement. Pour faire abstraction des aspects non techniques, il convient de considérer Le contexte comme la seule source de vérité de toutes les décisions techniques liées au projet. Cette abstraction supprime le « pourquoi » ces décisions ont été prises en supprimant tous les facteurs non techniques. C’est une décision délibérée, nécessaire pour limiter la complexité en ne gardant que les parties indispensables au développement logiciel.
Le contexte est constamment mis à jour et étendu par de nouvelles décisions techniques que nous prenons chaque jour. Si une décision ne fait pas encore partie de Le contexte, la décision est en quelque sorte prise (généralement à l’aide de procédures spécifiques à une équipe/entreprise/produit/etc.) et mise en contexte. Ces décisions ressemblent donc à une «carte de décision», qui associe chaque «problème» à une «décision» particulière et invoque une procédure prédéfinie si un élément manque.
D’un point de vue général, il est logique de garder cette « carte de décision » aussi petite que possible car elle contribue directement à la complexité de Le contexte. En d’autres termes, il est préférable d’avoir un plus petit ensemble de décisions plus générales/génériques qui couvrent un plus large éventail de situations similaires.
À l’intérieur du contexte
Regardons de plus près Le contexte et vérifiez ce qu’il y a d’autre. En plus de la carte de décision, il y a :
- le véritable domaine d’activité
- le modèle de domaine métier
- véritables processus métier
- le modèle des processus métier
Le mot business voici un espace réservé car ce qui est business dépend de chaque projet particulier et Le contexte complet qui lui a donné naissance. Dans l’industrie de la blockchain, au sommet de la hiérarchie d’abstraction, il y aura des processus de domaine et de blockchain. Dans le commerce électronique, ce sera une activité de commerce électronique, et ainsi de suite.
Notez que, lorsque nous commencerons à creuser dans les abstractions, nous constaterons que le business à chaque niveau d’abstraction est différent. Cela devrait être évident : nous divisons l’un des éléments de niveau supérieur en sous-parties (« mots »), où chaque « mot » n’est responsable que d’une partie de l’implémentation. Cette partie de la mise en œuvre est la business de ce mot. Ce processus descend et descend à travers les couches d’abstractions. En bas, il y a des détails purement techniques comme des appels à une bibliothèque standard ou même des trucs de bas niveau. En fait, les détails peuvent être poursuivis en profondeur aussi profondément que nécessaire (peut-être à l’infini) à partir des changements de contexte de tâche, en passant par des instructions CPU et des voies de cache spécifiques, via des signaux et des bus, jusqu’aux éléments logiques et à la physique à l’intérieur de la puce et du PCB.
Habituellement, il existe une limite logique raisonnable en dessous de laquelle plus de détails n’ajoutent aucune valeur. De toute évidence, si vous construisez un système d’exploitation, les appels système sont votre langage de niveau supérieur, tandis que tout ce qui se trouve en dessous des appels système fait partie de Le contexte domaine ou processus (encore une fois, limité à un niveau raisonnable).
Le modèle de domaine métier et le modèle de processus métier sont notre code de projet. Nous utilisons des langages de programmation pour coder et représenter des parties du domaine et des processus métier. En d’autres termes, le code est un encodage formalisé de l’entreprise, de son domaine et de ses processus. Cela signifie que le code est au mieux aussi bon que le domaine et les processus. Si vous avez un domaine flou ou des processus métier mauvais/inefficaces/incommodes, le code est au moins aussi mauvais (généralement pire). De plus, une carte n’est pas un territoire, de sorte que les deux modèles ne sont que des approximations du domaine et des processus commerciaux réels.
Il convient de noter que les relations entre les parties métier et leurs modèles sont bidirectionnelles. Le plus souvent, l’entreprise est prête à modifier les processus pour correspondre à celui proposé par le logiciel. Le niveau de flexibilité dépend fortement de plusieurs facteurs et peut varier. Habituellement, il y a un compromis entre le prix/délai et la précision de la modélisation de vos processus/domaine. De « acheter un logiciel prêt à l’emploi/abonnement au service ET ajuster tous vos processus au modèle proposé » (et obtenir un logiciel opérationnel presque instantanément pour quelques centaines/milliers $$) à « le logiciel doit reproduire exactement nos processus même s’ils sont stupides, et nous les détestons » (et dépensons des années et des millions de $$), et tout le reste.
Mais les processus ne sont pas les seuls à pouvoir changer. Le domaine du projet peut également changer. Cela se produit généralement lorsque la portée du projet est réduite ou étendue. Une décision de réduire ou d’étendre la portée peut être une conséquence de l’évaluation ou de l’analyse technique.
Néanmoins, il est souvent plus commode de considérer ces relations comme unidirectionnelles (même si elles ne le sont manifestement pas) et de supposer que les domaines et processus réels sont les sources de la vérité.
Notez que divers documents de conception, conceptions d’architecture et autres éléments similaires ne font pas partie de Le contexte. Ils pourraient exister et même être utiles s’ils correspondent précisément au code, mais le code est la source de vérité sur le modèle de domaine et le modèle de processus métier.
Une fois que nous commençons à penser au code du projet avec Le contexte en tête, on découvre rapidement les décisions pertinentes stockées dans Le contexte propriétés du code de contrôle :
- Le niveau de détail de la modélisation par rapport à la réalité
- Quelle est la précision de la modélisation
- Avec quelle facilité le contexte réel peut être restauré à partir du code (lisibilité du contexte)
- Combien de temps le projet sera utilisé
- À quel point il devrait être performant
Fondamentalement, tout ce qui concerne le projet est déterminé par Le contexte. Par exemple, si vous implémentez un outil de migration unique pour migrer un ancien système vers une nouvelle plate-forme, les exigences en matière de qualité du code, de maintenabilité, de couverture des tests, de lisibilité du contexte, etc. seront très différentes de celles d’un backend prévu pour être utilisé pendant au moins cinq ans. De plus, ces exigences ne doivent pas nécessairement être identiques dans l’ensemble de la base de code. Par exemple, nous pourrions sacrifier une certaine lisibilité du contexte dans une partie du code critique pour les performances afin d’obtenir les performances nécessaires.
Comme on peut le voir, une approche basée sur le contexte est très axée sur les affaires, contrairement aux approches traditionnelles, qui sont principalement axées sur les logiciels. Bien sûr, le lien avec l’entreprise a toujours existé, mais il ne s’agissait généralement que d’un intrant pour le développement de logiciels. Les spécifications et les exigences ont finalement été remplacées/complétées par des user stories et des epics lorsque l’industrie a adopté des méthodes agiles. Cela a considérablement amélioré la connexion avec l’entreprise, mais l’accent mis sur le logiciel est resté intact. Une vue contextuelle montre qu’il ne s’agit pas seulement d’une connexion, mais d’un couplage étroit, où l’entreprise est un moteur principal.
Le code
La principale conséquence de la compréhension des véritables relations entre les entreprises et les logiciels est la prise de conscience que les approches existantes du développement de logiciels pourraient ne pas être complètement à la hauteur de la tâche. Même un coup d’œil rapide montre des problèmes importants avec l’approche traditionnelle basée sur les meilleures pratiques.
La première chose à noter : L’approche traditionnelle essaie d’établir des pratiques identiques pour tous les projets. Comme on le sait, chaque projet est unique, et fixer des exigences identiques ne semble pas être une solution adéquate (ce genre de cas ressemble à la fameuse histoire pilote moyenne).
Deuxièmement, mais non moins important : une partie importante de l’approche traditionnelle repose sur la lisibilité du code comme justification. Dans l’ensemble, la lisibilité du code est souvent considérée comme l’une des propriétés les plus importantes du code. Le problème est que personne ne sait ce qu’est la « lisibilité du code ». Bien sûr, chaque développeur chevronné sait qu’il existe, mais il n’y a pas de définition raisonnable pour cela. Les termes existants sont soit auto-récursifs (c’est-à-dire amusants mais inutiles), soit reposent sur d’autres termes non définis tels que « l’intention ». Ce manque de définition signifie que chaque évaluation de la lisibilité du code est subjective et qu’il n’existe aucun moyen de valider une pratique exemplaire donnée qui prétend qu’elle « améliore la lisibilité du code ».
Même le terme « lisibilité du code » est trompeur. Si le code compile, il est lisible, au moins par le compilateur. Très probablement, avec un certain effort, le code est également lisible par l’homme. Ainsi, la « lisibilité du code » ne consiste pas du tout à lire le code.
Sans une compréhension claire de ce qu’est la lisibilité du code, l’ensemble traditionnel …