Als wir unsere Teams bildeten, suchten wir nach Prinzipien, die mit unseren Vorstellungen von Einfachheit, Modularität und kontinuierlichem Testen von Ideen durch Prototyping übereinstimmten. Wir haben festgestellt, dass Einfachheit entscheidend ist, da Komplexität zu Chaos und Katastrophen führt, insbesondere wenn etwas schief geht, wie es oft der Fall ist.

Wir fanden Inspiration im Osten, wo wir von Erfindern lasen, die Produkte mit unglaublicher Robustheit herstellten, während sie unter den Zwängen fehlender finanzieller Ressourcen standen. Zuerst haben sie die Grundlagen zum Laufen gebracht. Als nächstes schleppten sie ihre Erfindungen durch Schmutz und Schlamm und ließen sie aus großer Höhe fallen.

Nun stieß das Team auf ähnliche Prinzipien, die Unix-Philosophie, die Ende der siebziger Jahre aus den Bell-Labors stammte.

Aus dem Bell system Technical Journal, Juli-August 1978, kann man über die Leitprinzipien lesen, und mehrere Maximen haben sich unter den Erbauern des Unix-Systems durchgesetzt, um seinen charakteristischen Stil zu erklären und zu fördern.

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.

Dann sind wir natürlich über das legendäre Buch „ The Art of Unix Programming“ von Eric Steven Raymond gestolpert .

Obwohl Eric die Unix-Philosophie als KISS-Prinzip verdichtet

"Halten Sie es einfach blöd"

aus seinem Buch haben wir 17 Regeln extrahiert ,

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.

Codegenerierung mit Matlab Simulink

Wir haben auch viele der Unix-Prinzipien auf die Richtlinien unserer Funktionsentwickler angewendet, der Ingenieure, die Matlab und Simulink verwenden, um Steuerdiagramme zu zeichnen, die wiederum C-Code generieren. Wir hören oft von Programmierern, die aus anderen Branchen kommen, und insbesondere von denen, die C++ lieben, dass diese Methode minderwertig ist, aber nachdem ich beide verwendet habe, kann ich die Vorteile der Simulink-Codegenerierung klar erkennen . Bei großen Steuerungssystemen, die in Fahrzeugen eingesetzt werden und die Fahrzeuge zu unerwünschtem Verhalten veranlassen können, muss auch Software gut dokumentiert werden, und bei einer solchen Aufgabe ist diese Methode kaum zu übertreffen.
Ein Grund ist, dass der Codegenerator mögliche Konstrukte einschränkt. Ein weiterer Grund ist, dass wir nur bestimmte sichere Bibliotheken zulassen. Und schließlich haben wir Hunderte von Prüfskripten der Entwurfsmuster in Simulink sowie Prüfungen des generierten Codes. Eine typische Simulink -Zuul - Prüfpipeline:

- 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

Dieses Tool verwendet drei primäre Metriken, McCabe Cyclomatic Complexity, Halstead Complexity und Inkohärenz. Die primäre Zahl ist das gewichtete Halstead-Volumen, das sehr gut zum Design von Simulink passt. Wir haben 500 Simulink-Modelle subjektiv beurteilt und ihre Komplexität von 1–10 bewertet. Nachdem wir dieselben Modelle mit dem Tool gescannt hatten, kamen wir zu einem Ergebnis, das unserem eigenen Urteil sehr nahe kam.

Für einige Aufgaben ist es besser, den Code mit einer Tastatur zu schreiben, aber dies kann leicht in die Simulink-Modelle integriert werden. In unseren Software Development Kits, die wir zusammengestellt haben, betonen wir, dass Entwickler, die Code generieren, auch für den Code verantwortlich sind. Das ist einer der Gründe, warum wir diese Entwickler den Code an Gerrit pushen und auch Komponententests schreiben lassen, die den kompilierten Code verifizieren, und nicht auf Play in einer Simulink-Simulation drücken.

Die Aspekte der Unix-Philosophie, die wir für das Simulink-Design betonen, sind also:

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.

Bäume anbauen und kultivieren . Der erste Schritt besteht darin, einen Baum zu erwerben, was durch den Kauf eines Prebonsai (Rohmaterial, das beschnitten und gedrahtet werden muss) oder durch die Anwendung einer von mehreren möglichen Kultivierungstechniken erfolgen kann. Sehr wichtig ist jedoch die Auswahl einer Baumart, die zu Ihren Gegebenheiten passt.

Techniken trainieren und stylen. Beginnen wir mit der wichtigsten Einzeltechnik für Bonsai; Beschneidung. Das Beschneiden ist entscheidend, um Bäume miniaturisiert zu halten und sie zu formen. Das Ziel ist es, einen Bonsai zu schaffen, der der Natur so nahe wie möglich kommt. Äste mit unnatürlichen Drehungen und Wendungen entfernen. Entfernen Sie unverhältnismäßig dicke Äste von der Spitze des Baumes

Pflege und Wartung. Ein entscheidender Teil der Informationen darüber, wie man einen Bonsai-Baum anbaut, ist seine Wartung und Pflege.

In Simulink-Modelle konvertiert…

Holen Sie sich einen Baum. Denken Sie vor der Implementierung über den besten Fluss und die beste Verwendung von Subsystemen nach!

Beschneidung. Wenn die Funktion wächst, verwenden Sie Subsysteme, um eine angemessene Größe beizubehalten. Erstellen Sie einen Fluss mit möglichst wenigen Abzweigungen und Signalleitungen. Platzieren Sie Subsysteme so, dass sie sich gegenseitig speisen. Kleine Entscheidungen könnten in Subsystemen gehalten werden. Versuchen Sie, die Signalisierung einzudämmen, um Spaghetti zu vermeiden.

Pflege und Wartung. Wenn das System wächst, kann eine Änderung der Subsystemreihenfolge erforderlich sein. Es könnte auch von Vorteil sein, verschiedene Arten von Logik in verschiedenen Subsystemen zu strukturieren. Eine bewährte Vorgehensweise besteht darin, jedem Subsystem eine einzige Verantwortung zuzuweisen. es sollte eine Sache tun. Dies wiederum führt zu einer guten Kohäsion.

Von einer Tastatur geschriebener Code

Wenn es um Code geht, der von einer Tastatur geschrieben wird, haben wir in unserem CI-System Zuul keine guten Methoden zum Analysieren und Gating der Codekomplexität. Das einzige Maß, das wir jetzt haben, ist die zyklomatische Komplexität, und das sagt uns mehr oder weniger nur, wie schwer es sein wird, es zu testen. Allerdings haben wir etwas in der Pipeline, und zwar von meinem Kollegen und Genossen Vard Antinyan , der das Thema sehr detailliert recherchiert hat.

Wie Eric Steven Raymond feststellt,

Sie müssen Exzellenz treu bleiben und danach streben.

Sie müssen zu dem Schluss kommen, dass Softwaredesign ein Handwerk ist, das all die Intelligenz, Kreativität und Leidenschaft wert ist, die Sie aufbringen können. Andernfalls werden Sie auf den einfachen Weg verleitet, stereotype Herangehensweisen an Design und Implementierung; Sie werden ins Programmieren stürzen, wenn Sie nachdenken sollten. Besonders wenn Sie in einer agilen Umgebung arbeiten, laufen Sie möglicherweise einfach in Ihrem Sprintrad und verkomplizieren möglicherweise nachlässig, wenn Sie es sollten

schonungslos vereinfachen

und dann werden Sie sich fragen, warum Ihr Code aufbläht und das Debuggen so schwierig ist.

Wenn jemand ein Problem bereits einmal gelöst hat, lassen Sie sich nicht von Stolz oder Politik dazu verleiten, es ein zweites Mal zu lösen, anstatt es erneut zu verwenden.

Wenn einer meiner Kollegen etwas Besseres hat, werde ich es mit Stolz stehlen. Und natürlich wollen wir alles Mögliche automatisieren, das spart langfristig Zeit.

Programmieren sollte eine freudvolle Kunst sein, etwas, das wir schätzen und leidenschaftlich lieben. Wenn uns das fehlt, sollten wir vielleicht etwas anderes tun?

Sie müssen sich kümmern. Sie müssen spielen. Sie müssen bereit sein, zu erkunden.