チームを編成したとき、シンプルさ、モジュール性、およびプロトタイプによるアイデアの継続的なテストという私たちのアイデアに共鳴する原則を探しました。複雑さはカオスと災害を生むため、シンプルさが重要であることがわかりました。特に物事がうまくいかない場合はよくあることです。

私たちは東部でインスピレーションを得ました。そこでは、資金不足という制約の下で信じられないほど堅牢な製品を作った発明者について読みました。まず、彼らは基本的な作業を行いました。次に、発明品を土や泥の中を引きずり、高所から落としました。

現在、チームは、70 年代後半にベル研究所からもたらされた、同様の原則である Unix 哲学に出くわしました。

1978 年 7 月から 8 月に発行されたベル システム テクニカル ジャーナルから、指導原則について読むことができ、いくつかの格言が Unix システムの構築者の間でその特徴的なスタイルを説明し、促進するために通用するようになりました。

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.

それからもちろん、エリック・スティーブン・レイモンドによる伝説的な本「The Art of Unix Programming」に出くわしました。

Eric は Unix の哲学をKISS Principle of

「シンプルに保ちなさい」

彼の本から 17 のルールを抽出しました。

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.

Matlab Simulink によるコード生成

また、関数開発者 (Matlab と Simulink を使用して C コードを生成する制御図を作成するエンジニア) のガイドラインに Unix の原則の多くを適用しました。異業種出身のプログラマー、特に C++ が好きなプログラマーからは、この方法は劣っているという意見をよく耳にしますが、両方を使用してみると、Simulink コード生成の利点がはっきりとわかります。車両で使用され、車両に望ましくない動作を引き起こす可能性がある大規模な制御システムの場合、ソフトウェアも十分に文書化する必要があり、そのようなタスクでは、この方法に勝るものはありません。
理由の 1 つは、コード ジェネレーターが可能な構成を制限することです。もう 1 つは、特定の安全なライブラリのみを許可することです。最後に、Simulink の設計パターンのチェック スクリプトと、生成されたコードのチェックが数百あります。典型的な Simulink Zuulチェック パイプライン:

- 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

このツールは、McCabe Cyclomatic Complexity、Halstead Complexity、および Incoherence という 3 つの主要なメトリックを使用します。主要な数値は、Simulink の設計に非常によく適合する加重ハルステッド ボリュームです。500 個の Simulink モデルについて主観的な判断を下し、複雑さを 1 ～ 10 の段階で評価しました。ツールで同じモデルをスキャンした後、私たち自身の判断に非常に近い結果が得られました。

タスクによっては、キーボードを使用してコードを記述したほうがよい場合もありますが、これは Simulink モデルと簡単に統合できます。私たちがまとめたソフトウェア開発キットでは、コードを生成する開発者もコードに対して責任があることを強調しています。これが、これらの開発者がコードを Gerrit にプッシュし、コンパイルされたコードを検証する単体テストを記述し、Simulink シミュレーションで再生を押さないようにする理由の 1 つです。

したがって、Simulink 設計で強調する Unix 哲学の側面は次のとおりです。

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.

木を育てて育てる。最初のステップは、木を入手することです。これは、プレ盆栽（剪定して配線するための粗い材料）を購入するか、いくつかの可能な栽培技術のいずれかを使用して行うことができます. ただし、非常に重要なのは、状況に合った樹種を選択することです。

トレーニングとスタイルのテクニック。盆栽にとって最も重要なテクニックから始めましょう。剪定。剪定は、木を小型化するだけでなく、形を整えるためにも重要です。目標は、できるだけ自然に似た盆栽を作ることです。不自然なねじれや曲がりのある枝を取り除きます。木のてっぺんから不釣り合いに太い枝を取り除く

お手入れとメンテナンス。盆栽の木を育てる方法に関する情報の重要な部分は、そのメンテナンスとケアです.

Simulinkモデルに変換…

木を手に入れます。実装する前に、最適なフローとサブシステムの使用について考えてください。

剪定。関数が大きくなるにつれて、サブシステムを使用して適切なサイズを維持します。分岐と信号線をできるだけ少なくしてフローを作成します。サブシステムを相互にフィードするように配置します。小さな決定はサブシステムに保持できます。スパゲッティを避けるために信号を封じ込めるようにしてください。

お手入れとメンテナンス。システムが大きくなると、サブシステムの順序の変更が必要になる場合があります。異なるサブシステムで異なる種類のロジックを構築することも有益です。各サブシステムに単一の責任を持たせることをお勧めします。1 つのことを行う必要があります。これにより、良好な結束がもたらされます。

キーボードで書かれたコード

キーボードで書かれたコードに関しては、CI システム Zuul でコードの複雑さを分析してゲートするための良い方法がありません。私たちが現在持っている唯一の測定値は循環的複雑度であり、多かれ少なかれテストがどれほど難しいかを示しています。とはいえ、パイプラインには何かがあります。それは私の同僚で同志のVard Antinyanからのものです。

エリック・スティーブン・レイモンドが述べているように、

あなたは忠実であり、卓越性を追求しなければなりません。

ソフトウェア設計は、あらゆる知性、創造性、情熱を注ぎ込む価値のある技術であるという結論に達する必要があります。そうしないと、だまされて、設計と実装にアプローチするための安易な道、型にはまった方法に陥ってしまいます。考えるべきときにコーディングに突入します。特にアジャイル環境で作業している場合は、スプリント ホイールで実行するだけで、実行する必要があるときに不注意に複雑になる可能性があります。

容赦なく単純化

そして、なぜコードが肥大化してデバッグが難しいのか不思議に思うでしょう。

誰かがすでに問題を解決している場合は、プライドや政治に引きずられて、再利用するのではなく、もう一度問題を解決してはいけません。

私の同僚の誰かがより良いものを持っていれば、私は誇りを持ってそれを盗みます. そしてもちろん、できることはすべて自動化したいので、長期的には時間を節約できます。

プログラミングは楽しい芸術であり、私たちが感謝し、情熱を傾けるものであるべきです。これが欠けている場合は、何か他のことをする必要がありますか?

あなたは気にする必要があります。あなたは遊ぶ必要があります。喜んで探索する必要があります。