Lorsque nous avons formé nos équipes, nous avons recherché des principes qui résonnaient avec nos idées de simplicité, de modularité et de test continu d'idées par prototypage. Nous avons constaté que la simplicité est cruciale car la complexité engendre le chaos et le désastre, en particulier lorsque les choses tournent mal, comme c'est souvent le cas.

Nous avons trouvé l'inspiration dans l'Est, où nous avons lu des articles sur des inventeurs qui ont fabriqué des produits d'une incroyable robustesse tout en étant contraints par le manque de ressources financières. Tout d'abord, ils ont réussi à faire fonctionner les bases. Ensuite, ils ont traîné leurs inventions dans la terre et la boue et les ont lâchées des hauteurs.

Maintenant, l'équipe est tombée sur des principes similaires, la philosophie Unix, qui est venue des laboratoires Bell à la fin des années soixante-dix.

Dans le Bell system Technical Journal, juillet-août 1978, on peut lire sur les principes directeurs, et plusieurs maximes se sont imposées parmi les constructeurs du système Unix pour expliquer et promouvoir son style caractéristique.

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Ensuite, bien sûr, nous sommes tombés sur le livre légendaire " L'art de la programmation Unix" d'Eric Steven Raymond .

Bien qu'Eric ait condensé la philosophie Unix en tant que principe KISS de

"Gardez-le simple stupide"

de son livre nous avons extrait 17 règles ,

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for “one true way”.
Rule of Extensibility: Design for the future because it will be here sooner than you think.

Génération de code avec Matlab Simulink

Nous avons également appliqué de nombreux principes Unix aux directives de nos développeurs de fonctions, les ingénieurs qui utilisent Matlab et Simulink pour dessiner des diagrammes de contrôle qui à leur tour génèrent du code C. Nous entendons souvent des programmeurs qui viennent d'autres industries, et en particulier ceux qui aiment C++, que cette méthode est inférieure, mais ayant utilisé les deux, je peux clairement voir les avantages de la génération de code Simulink . Pour les grands systèmes de contrôle, qui sont utilisés dans les véhicules et qui peuvent inciter les véhicules à présenter un comportement indésirable, le logiciel doit également être bien documenté, et dans une telle tâche, cette méthode est difficile à battre.
L'une des raisons est que le générateur de code limite les constructions possibles. Une autre est que nous n'autorisons que certaines bibliothèques sûres. Et enfin, nous avons des centaines de scripts de vérification des modèles de conception dans Simulink, ainsi que des vérifications du code généré. Un pipeline de vérification Simulink Zuul typique :

- project:
   name: repo
   check:
    jobs:
     - buildavoidance-nodeless
     - common-gcc_check
     - common-pybuild_diff
     - common-signal_consistency
     - common-cppcheck
     - common-checkscript
     - common-unittests_shared
     - ProjectA-unittests
     - common-simdiff
     - common-mxray
     - common-mxam
     - common-mxam_safety
     - common-ci_of_ci
     - Polyspace code prover

Cet outil utilise trois mesures principales, la complexité cyclomatique McCabe, la complexité Halstead et l'incohérence. Le nombre principal est le volume Halstead pondéré qui correspond très bien à la conception de Simulink. Nous avons porté un jugement subjectif sur 500 modèles Simulink, où nous avons classé leur complexité de 1 à 10. Après avoir scanné les mêmes modèles avec l'outil, nous avons obtenu un résultat très proche de notre propre jugement.

Pour certaines tâches, il est préférable d'écrire le code à l'aide d'un clavier, mais cela peut facilement être intégré aux modèles Simulink. Dans nos kits de développement logiciel, que nous avons mis en place, nous soulignons que les développeurs qui génèrent du code sont également responsables du code. C'est l'une des raisons pour lesquelles nous laissons ces développeurs pousser le code vers Gerrit et également écrire des tests unitaires qui vérifient le code compilé, sans appuyer sur play dans une simulation Simulink.

Ainsi, les aspects de la philosophie Unix sur lesquels nous insistons pour la conception de Simulink sont :

Rule of Modularity: ‘Write simple parts connected by clean interfaces’
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Transparency: Design for visibility to make inspection and debugging easier
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Least Surprise: Pay attention to your expected audience.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Faire pousser et cultiver des arbres . La première étape consiste à acquérir un arbre, ce qui peut se faire en achetant un prébonsaï (matériel brut à tailler et à câbler) ou en utilisant l'une des nombreuses techniques de culture possibles. Cependant, il est très important de sélectionner une espèce d'arbre qui correspond à votre situation.

Techniques d'entraînement et de style. Commençons par la technique la plus importante pour Bonsai ; taille. L'élagage est crucial pour garder les arbres miniaturisés ainsi que pour les façonner. L'objectif est de créer un bonsaï qui ressemble le plus possible à la nature. Enlevez les branches avec des rebondissements non naturels. Enlevez les branches disproportionnellement épaisses du haut de l'arbre

Entretien et maintenance. Une partie cruciale de l'information sur la façon de faire pousser un bonsaï est son entretien et son entretien.

Convertis en modèles Simulink…

Obtenez un arbre. Réfléchissez au meilleur flux et à l'utilisation des sous-systèmes avant de mettre en œuvre !

Taille. Au fur et à mesure que la fonction grandit, utilisez des sous-systèmes pour conserver une taille raisonnable. Créez un flux avec le moins de branches et de lignes de signal possible. Placez les sous-systèmes de manière à ce qu'ils s'alimentent mutuellement. Les petites décisions pourraient être conservées dans des sous-systèmes. Essayez de contenir la signalisation pour éviter les spaghettis.

Entretien et maintenance. Si le système se développe, il peut être nécessaire de modifier l'ordre des sous-systèmes. Il pourrait également être avantageux de structurer différents types de logique dans différents sous-systèmes. Une bonne pratique consiste à laisser chaque sous-système avoir une seule responsabilité ; ça devrait faire une chose. Cela conduit à son tour à une bonne cohésion.

Code écrit par un clavier

En ce qui concerne le code écrit par un clavier, nous n'avons pas de bonnes méthodes pour analyser et délimiter la complexité du code dans notre système CI Zuul. La seule mesure que nous ayons maintenant est la complexité cyclomatique, et cela nous indique plus ou moins à quel point il sera difficile de tester. Bien que nous ayons quelque chose en préparation, et cela vient de mon collègue et camarade Vard Antinyan , qui a étudié le sujet en détail.

Comme le dit Eric Steven Raymond,

vous devez être loyal et viser l'excellence.

Vous devez arriver à la conclusion que la conception de logiciels est un métier qui vaut toute l'intelligence, la créativité et la passion que vous pouvez rassembler. Sinon, vous serez trompé dans le chemin facile, les manières stéréotypées d'aborder la conception et la mise en œuvre ; vous vous précipiterez dans le codage alors que vous devriez réfléchir. Surtout si vous travaillez dans un cadre Agile, vous pourriez simplement courir dans votre roue de sprint, et vous pourriez compliquer négligemment quand vous devriez être

simplifier sans relâche

et alors vous vous demanderez pourquoi votre code gonfle et le débogage est si difficile.

Si quelqu'un a déjà résolu un problème une fois, ne laissez pas la fierté ou la politique vous inciter à le résoudre une deuxième fois plutôt que de le réutiliser.

Si l'un de mes collègues a quelque chose de mieux, je le volerai avec fierté. Et bien sûr, nous voulons automatiser tout ce que nous pouvons, cela fera gagner du temps à long terme.

La programmation doit être un art joyeux, quelque chose que nous apprécions et qui nous passionne. Si nous manquons de cela, alors peut-être devrions-nous faire autre chose ?

Vous devez vous en soucier. Vous devez jouer. Vous devez être prêt à explorer.