重要なアルゴリズムの開発：実装

1. 設計
2. 実装
3. 統合

キャリア開発を始めたばかりの頃、なぜオープンソースが必要なのか理解できませんでした。そのため、私はサイドプロジェクトも理解していませんでした。結局、なぜ無料で貴重な作品を提供するのですか？長年にわたり、オープンソースプロジェクトでの作業、およびApex.AI、ROS 2、Autoware.Autoでの作業を通じて、オープンソースについてある程度理解しました。



エンジニアは作成が大好きです。人々は認識と感謝を望んでいます。



これらの要素を組み合わせると、オープンソースへの道が開かれます。私の創造的なニーズを満たすために何かを構築している場合は、他の人に私の作品を評価してもらい、実用的な使用方法と価値を見つけさせてみませんか？結局、私はお金のためにこれをしていません。



サイドプロジェクトについては、専門的に開発し始めて、仕事のさまざまな側面にもっと注意深く取り組み始めて初めて、その魅力に気付きました。人々が支払う信頼できる製品を作成するには、ワークフローを人為的に制限することがしばしば必要になります。設計分析。コードレビュー。コーディング標準、スタイルガイド、テストカバレッジメトリックなど。誤解しないでください。これらはすべて、高品質の製品を開発するために必要となる可能性が高い良いものです。それは、時々、開発者が少しの自由を望んでいるだけのことです。開発者は、自分が望むもの、自分が望む方法、いつ望むかを作成したいと思うかもしれません。会議、レビュー、ビジネスケースはありません。



では、安全または高品質のアルゴリズムを開発する際に、これらの側面をどのように組み合わせるのでしょうか。オープンソースの世界の魅力の大部分は自由であり、より信頼性の高いコードの開発を保証するのに役立つ慣行はその自由を制限します。



私が見つけた答えは、オープンで一貫した規律に従い、オープンソースの世界から来た多くのクールなツールを自由に使用することです。

オープンソースプロジェクトの計画

エンジニアは、これらの問題に対処するための特定のスキルセットを必要とします。エンジニアは集中する必要があり、優れた問題解決スキルが必要です。エンジニアはまた、懸念事項を分離し、上記のすべての知識を得るために必要な確かな基本スキルを備えている必要があります。



この特定のスキルセットは、エンジニアをやや圧倒する可能性があります。



エンジニアが持つすべての技術的能力について、最終的には能力が制限されます。ほとんどの開発者は、個々のコード行を記述している間、プロジェクト全体を念頭に置くことができないと主張します。さらに、ほとんどの開発者は一般的なビジネス目標を忘れずにプログラムを作成し、より広範なプロジェクトを頭に留めることはできないと私は主張します。



これがプロジェクト管理の黒魔術の出番です。



私たちの開発者は人事、技術、またはプロジェクトマネージャーと幾分物議を醸す関係にあるかもしれませんが、これらの人々のすべてが重要な仕事をしていることを認識すべきです。管理職の最も優れた代表者は、開発者が重要なタスクを見失うことのないようにし、苛立たせる刺激が私たちがすべての武器で問題を撃つことを妨げないようにします。



また、さまざまなマネージャーの重要性は理解していますが、これらのスキルを持つ人々は通常、楽しみを持つことを目的とする典型的なオープンソースプロジェクトには関与しません。



では、どうしたらいいでしょうか。



まあ、私たちの開発者は私たちの手を汚し、少し前に計画を立てることができます。



前回の投稿で、設計と開発の計画段階について詳しく説明した ので、これらの会話には触れません。要するに、設計とアーキテクチャを考慮に入れると、原則として、多くのコンポーネントで構成され、いくつかの依存関係を形成します。独自のプロジェクトでは、自分でデザインを作成し、そのコンポーネントを個別に収集します。



プロジェクト計画の側面に戻ると、依存関係が最も少ないコンポーネントから始めたいと思います（1 分と考えてください）！）その後、作業を​​続け、開発を継続するために必要な場所に実装スタブを追加します。この作業順序では、通常、多くのチケットを作成できます（タスクのトラッカーにそのような機能がある場合、アーキテクチャの依存関係に対応するいくつかの依存関係があります）。これらのチケットには、タスクを詳しく説明する前に覚えておくと役立つ一般的な注意事項が含まれている場合があります。チケットはできるだけ小さく、具体的にする必要があります。それに直面しましょう-私たちの焦点とコンテキストを保持する能力は限られています。開発タスクが細かく分割されているほど簡単になります。では、難しいタスクをできるだけ単純にしてみませんか？



プロジェクトが発展するにつれ、あなたの仕事は優先度の高い順にチケットを受け取り、それに割り当てられたタスクを完了することです。



明らかに、これはプロジェクト管理の大幅に簡略化されたバージョンです。リソース、計画、競合するビジネスケースなど、真のプロジェクト管理には他にも多くの側面があります。オープンソースでのプロジェクト管理は、より簡単でより自由になる場合があります。おそらく、オープンソース開発の世界では、本格的なプロジェクト管理の事例があるでしょう。

オープン開発

一連のチケットを入力し、作業計画を立て、すべての詳細を理解したら、開発に進むことができます。



しかし、オープン開発の西側に存在する自由の要因の多くは、安全なコードの開発にあるべきではありません。オープンソースのツールを使用して、いくつかの規律を持って（そして友達を作って）、多くの落とし穴を回避できます。



私は、仕事の質を向上させる手段としてのしつけの大きな支持者です（結局、しつけは、StrengthsFinderでの私の評価で6位にあります。）。オープンソースツールを使用し、他の人の意見を聞き、結果に基づいて行動し、ワークフローを守るのに十分な規律があるので、オープンソースの世界のカウボーイアプローチに潜む欠陥の多くを克服できます。



簡単に言うと、次のツールとプラクティス（いくつかの注意点がありますが、どのプロジェクトでも簡単に適用できます）を使用すると、コードの品質が向上します。

1. テスト（より良いのは、テスト駆動開発）
2. 静的分析
3. 継続的インテグレーション（CI / CD）
4. コードレビュー

また、コードを直接作成するときに遵守するいくつかの原則も示します。

1. ドライ
2. 言語とライブラリの完全な使用
3. コードは読みやすく、盲目的に明白でなければなりません。

このテキストを、私の良き同僚であるYunusによる10回のマージ要求で完了したNDTローカリゼーションアルゴリズムの実際の実装に関連付けます。彼は直接の仕事に忙しいので、彼の作品について書くことによって、私は架空のメダルをいくらか独り占めすることができます。 さらに、いくつかのプロセスと実践を説明するために、MPCコントローラー用のオープンソースアルゴリズムを開発する例を示します。約30以上のマージ要求でややルーズな（カウボーイ）スタイルで開発されました。メインの作業が完了した後に行われた追加の編集や改善は含まれません。

テスト中

テストについて話しましょう。



私は（私の基準では）長くて難しいテストとの関係を持っていました。私が最初に開発者としての地位を得て最初のプロジェクトに着手したとき、自分のコードが機能することをまったく信じていなかったので、少なくとも意味のあるユニットテストを書き始めたチームで最初になりました。しかし、自分のコードが機能しないことは間違いありませんでした。



それ以来、私のテストとの激動の関係は、一晩の映画に値する多くのねじれと回転を経てきました。時々私はそれが好きだった。時々私はそれをすべて嫌っていました。あまりにも多くのテストを書きました。コピーと貼り付けが多すぎ、冗長なテストが多すぎます。その後、テストは日常的な作業になり、開発の一部になりました。最初にコードを記述し、次にコードのテストを記述しました。これが順序です。



現在、私はテストと通常の関係があります。どんなアプリケーションに取り組んでいても、それは私のワークフローの不可欠な部分です。



私にとって変化したのは、mpcプロジェクトで使用し始めたテスト駆動型開発手法です。前のテキストでテスト駆動開発



について簡単に説明しましたが、プロセスの別の説明を次に示します。

1. 仕様を作成します（使用例、要件など）。
2. API /アーキテクチャを実装する
3. APIと設計仕様に基づいてテストを記述します。彼らは失敗する必要があります。
4. ロジックを実装します。テストに合格する必要があります

このプロセスにはいくつかの反復があります（テストがスタブで失敗しない、実装がテストに失敗する、APIが扱いにくいなど）が、全体的に非常に役立つと思います。



実装前の計画について多くのことを話しましたが、テスト駆動開発はその機会を与えてくれます。最初の点が指摘されました。次に、アーキテクチャとAPIについて考え、それらをユースケースにマッピングします。これにより、コードに近づく絶好の機会が得られますが、問題についてより広く考えることができます。第二の点が指摘された。



次に、テストの作成に進みます。実装前にテストを書くことの利点にはいくつかの理由があり、それらはすべて重要だと思います。

1. テストは、アドオンとしてではなく、最優先オブジェクトとして作成する必要があります。
2. , – .
3. API , .
4. , , , , .

全体として、テスト駆動開発のメリットは非常に大きいと思います。繰り返しますが、皆さんにも少なくとも試してみることを強くお勧めします。



Autoware.Autoに戻りましょう。 Yunusは、テスト主導の開発手法に固執していませんが、NDT開発中にマージ要求ごとにテストを作成しました。同時に、テストコードの量は実装コードの量と同じで（場合によってはそれを超えることもあり）、これは良好です。比較すると、おそらくオープンソースプロジェクトの標準だけでなくテストのベンチマークであるSQLiteは、実装コードの662倍のテストコードを持っています... Autoware.Autoではまだこの段階ではありませんが、NDTに関連するマージリクエストの履歴を見ると、テストコードの量が90％のカバレッジに達するまでゆっくりとクロールされていることがわかります（ただし、それ以降は減少しています）他のデザインと外部コードによる）。



そしてそれはクールです。



同様に、私のmpcプロジェクトには、テスト自体を含むすべてのテストがあります。さらに、バグが修正され、再び表示されないことを確認するために、常に慎重に回帰テストを実施しています。



元気です。

静的分析

多くの概念は、それらに含まれる定義が大幅に拡張される可能性があるという点で興味深いものです。たとえば、テストは手書きの機能テストをはるかに超えています。実際、スタイルチェックやバグハンティングもテストの一種と見なすことができます（これは本質的には検査ですが、定義を拡張すると、テストと呼ぶことができます）。



このような「テスト」は、やや面倒で扱いにくいものです。結局のところ、検証、整列のタブ/スペースの検証？結構です。



しかし、プログラミングについて最も楽しく価値のあるものの1つは、苦痛で時間のかかるプロセスを自動化する機能です。同時に、コードは誰よりも速くより正確に結果を得ることができます。コード内のバグや問題のある、またはエラーが発生しやすい構造で同じことができるとしたらどうでしょうか。



まあ、私たちはできる-静的分析ツールで。



静的分析については以前のブログ投稿で十分に長く書いたので、その利点と使用できるツールについては詳しく説明しません。



Autoware.Autoでは、少し小さいバージョンのament_lintセットを使用しますROS 2の親しい友人から。これらのツールは多くの利点をもたらしますが、おそらく最も重要なことは、スタイルの紛争を排除するためにコードを自動フォーマットすることです。公平なツールは、何が正しいか、何が悪いかを教えてくれます。興味があれば、clang-formatはuncrustifyよりも厳密であることに注意します。



mpcプロジェクトでは、もう少し進んだ。その中で、clang-tidyおよびClang 静的アナライザーからのすべての警告に加えて、ClangコンパイラーのWeverythingフラグを使用しました。驚いたことに、商用開発で​​はいくつかのオプションを無効にする必要がありました（冗長な警告と概念の混乱のため）。）。外部コードとやり取りするとき、私は多くのチェックを無効にする必要がありました-それらは不必要なノイズにつながりました。



最終的に、私は広範な静的分析を使用しても通常の開発に大きな影響を与えないことを認識しました（新しいコードを記述し、学習曲線上の特定のポイントを通過した後）



、特に最初から使用する場合、静的分析の値を定量化することは困難です。ポイントは、静的解析が導入される前にエラーが存在していたかどうかを推測するのが難しいということです。



ただし、警告と静的分析を使用することは、正しく使用した場合でも、何が行われたかを確認できない場合の1つだと思います。。つまり、静的アナライザーがオンになっているときの値はわかりませんが、すぐには表示されないことに気づくでしょう。

CI / CD

厳密なテストと静的/動的コード分析が大好きなのと同じように、すべてのテストとチェックは、実行しなければ価値がありません。CIは、最小限のオーバーヘッドでこれらの課題に対応できます。CI / CD



インフラストラクチャが最新の開発に不可欠であり、バージョン管理システムを使用し、開発標準（少なくともスタイルガイド）を持っていることは、誰もが同意していると思います。ただし、優れたCI / CDパイプラインの価値は、その操作が再現可能でなければならないことです。



CI / CDパイプラインは、少なくともコードをビルドして、コードをリポジトリにプッシュする前にテストを実行する必要があります。結局のところ、アセンブリやある種のテストを破って、すべてを迅速かつ恥ずかしそうに修正しなければならないその人（または女の子、またはペルソナ）になりたい人は誰もいません。 CI（したがって、親愛なるDevOpsエンジニア）は、この恥からあなたを守ります。



しかし、CIはあなたのためにもっと多くのことができます。



堅牢なCIパイプラインを使用すると、オペレーティングシステム、コンパイラ、およびアーキテクチャの任意の数の組み合わせをテストできます（組み合わせテストを考慮して、いくつかの制限があります）。また、ビルドを実行したり、テストを実行したり、開発者が手作業で実行するにはリソースを集中的に使用したり、面倒だったりする操作を実行することもできます。頭を飛び越えることはできません。



元のステートメントに戻って、オープンソースプロジェクトにCI / CDパイプライン（Autoware.Autoで使用）を含めると、管理不可能な開発に乗りやすくなります。テストをビルドまたはパスしない場合、コードはプロジェクトに入ることができません。厳格なテスト規則に準拠している場合は、コードが機能することを常に確認できます。



Autoware.AutoのCI：

1. コードを収集する
2. テストを実行します（スタイル、リンターチェック、機能テスト）。
3. テストカバレッジを測定
4. コードが文書化されていることを確認します

次に、mpcプロジェクトで急いでコンパイルしたCI：

1. コードを収集する
2. スキャンを実行します（Clang静的分析）
3. テストを実行します（テストが失敗してもCIを停止しません）。

経験豊富なDevOpsエンジニア（J.P. SamperやHao Pengなど）が組み立てたCIパイプラインは、さらに多くのことができます。DevOpsエンジニアを大切にしてください。彼らは（開発者としての）私たちの生活をはるかに簡単にします。

コードレビュー

ベンチマーク、アナライザー、CIは優れています。テストを実行してすべてを分析し、これらのテストがCIを使用して行われることを確認できますよね？



残念だけど違う。



繰り返しになりますが、世界中のすべてのテストは、それが悪い場合には無意味です。では、テストが適切であることをどのように確認しますか？



残念ながら、私には魔法の答えはありません。実際、以前のエンジニアリング手法であるピアレビューに戻ります。特に、コードレビューに。



一般に、2つのヘッドの方が1つよりも優れていると考えられています。実際、この概念は文学だけでなく理論によっても支持されていると私は主張します。



メソッドのアンサンブル機械学習では、この理論を説明しています。メソッドのアンサンブルを使用すると、統計モデルのパフォーマンスを改善するための迅速かつ簡単な方法であると考えられています（よく知られているブースティング法はその一例です）。同様に、純粋に統計的な観点から見ると、サンプル数が多いほど、（仮定により）分散は小さくなります。つまり、より多くの従業員をつなぐと、真実により近づく可能性が高くなります。チームビルディングの演習を



行うことにより、このテクニックを実際の例で試すことができます。あまり面白くないバージョンでは、ランダム統計を個別に、またはグループで推測する必要があります。



理論とチームビルディングは別として、コードレビューは重要で強力なツールです。当然のことながら、コードレビューはあらゆる専門的な開発プロセスの不可欠な部分であり、ISO 26262規格によっても推奨されていますが、



これらはすべて、1人の子供が7乳母になる危険が常にあることを示唆しています。さらに、コードレビューによって特定の問題が発生する場合があります。



ただし、レビュー担当者と査読者の両方が次のことを覚えていれば、コードレビューは楽しく簡単にできると思います。

1. あなたはあなたのコードではありません。
2. あなたは他の人と話している。
3. 礼儀正しく
4. 誰もが同じ目標に向かって努力しています。コードレビューはいかなる競争も表していません（ただし、プログラミングで発生することもあります）

コードレビューを適切に行う方法について、私よりも賢くてすばらしい人がたくさん書いています。彼らの仕事を見てください。最後に言えることは、コードの信頼性を高めたい場合はコードレビューを行う必要があるということです。

ドライ

開発環境を作成するために使用できるプロセスとツールについて詳しく説明しました。チェックと、チェックを実行してコードが十分であることを確認するツールです。



次に、プログラミングの腕前について簡単に説明し、個々のコード行の記述の背後にあるプロセスと意図についての考えを共有します。



コードを大幅に改善するのに役立ついくつかの概念があります。それらの概念の1つは、意図、セマンティクス、および読みやすさを記憶する機能でした。これについては、後で少し説明します。もう一つは、理解のあるOOPや関心事の分離。最後の重要なアイデアはDRY（あるあなた自身を繰り返してはいけない）、または原則「DOは自分自身を繰り返していません。」



DRYは学校で教えられていることであり、他の多くのことと同様に、私たちはこの考えを遠くの棚に置いており、試験以外では（少なくとも私にとっては）それをあまり重視していません。しかし、学校の他の多くの場合と同様に、私たちはそのようなことを何も学びません。実際、これは良い習慣です。



簡単に言えば、コードを頻繁にコピーして貼り付けたり、非常によく似たコードを頻繁に作成したりする場合、これは繰り返し可能なコードが機能または抽象化の一部になることを示す非常に良い兆候です。



ただし、DRYは、一部のコードを関数に移動する必要があることを確認するだけではありません。この概念は、いくつかのアーキテクチャ上の決定の基礎としても役立ちます。



このアプローチはいくつかのアーキテクチャの概念（エイリアス、接続、懸念事項の分離など）と交差しますが、DRYがアーキテクチャにどのように適用されるかの例は、私のmpcプロジェクトで見ることができます。mpcコントローラーの開発中に、別のコントローラーを作成する場合、コードを複製する必要があることに気付きました。状態、投稿、サブスクリプション、コンバージョンなどを追跡するための定型コードについてです。つまり、mpcコントローラーとは別のタスクであるように見えました。



これは、一般的なデザインと機能を別のクラスに分ける必要があることを示す良い兆候でした。見返りは2つありました。mpcコントローラーは、mpcに関連するコードに100％集中しており、関連付けられているモジュールは、単なる構成テンプレートです。つまり、アーキテクチャの抽象化により、別のコントローラーで作業するときにすべてを書き直す必要はありません。



世界は灰色の濃淡で構成されているため、これらの設計上の決定は、注意深く適切な考え方で掘り下げる必要があります。それ以外の場合は、行き過ぎて、必要のないところに抽象化を作成し始めることができます。ただし、開発者がこれらの抽象化モデルの概念を意識している場合、DRYはアーキテクチャ上の決定を形作る強力なツールです。私の意見では、DRYはコードをクリーンで高密度に保つための主要な概念です。



結局のところ、コードの主要な利点の1つは反復的なタスクを実行できることです。そのため、適切に設計された関数とクラスに反復をシフトしてみませんか？

言語とライブラリの完全な使用

私の意見では、DRYは非常に重要で普及している概念であり、この点は実際にはDRYの会話のほんの一部にすぎません。



使用する言語が何かをサポートしている場合は、オプトアウトする十分な理由がない限り、通常はインライン実装を使用する必要があります。そして、C ++には多くのものが組み込まれています。



プログラミングはスキルであり、スキルレベルには大きな違いがあります。このスキルの山の高さを垣間見ただけで、一般的に、標準を作成する人は私よりも一般的なパターンを実装する方が優れていることがわかりました。



ライブラリの機能についても同様の議論をすることができます（ただし、それほど明確には分類されていません）。他の誰かがすでに同じことを行っており、おそらく良いレベルであるため、ホイールを再発明する理由はありません。



それでも、これは他の多くの場合と同様に、この段落は推奨事項であり、適用する厳格で緊急の規則ではありません。ホイールを再発明する価値はありませんが、標準的な実装は一般的に非常に優れていますが、正方形の部品を丸い穴に押し込もうとしても意味がありません。あなたの頭で考えなさい。

読みやすいコード

私のプログラミングスキルの向上に役立った最後のコンセプトは、プログラミングはコードを書くことではなく、コミュニケーションについてだということでした。他の開発者とのコミュニケーションではない場合は、未来からのあなた自身とのコミュニケーション。もちろん、メモリ、数学、Big Oの複雑さについて考える必要がありますが、それが完了したら、意図、意味論、明快さについて考える必要があります。このトピックについて



は非常に有名で広く推奨されている本であるClean Codeがあるので、このトピックに追加できることはあまりありません。ここでは、コードを記述してコードレビューを行うときに参照するいくつかの一般的な情報を示します。

1. クラスを明確かつ集中的に保つようにしてください：
   
   
   • 引っ掛かりを最小限に抑える
   • ()
     
     
     
     
     • const, noexcept? ? (, )
2. 
   
   
   
   
   • , (, , ).
   • (, )
   • .
3. -
   
   
   
   
   • «», , .
   • (, ).
   • ( ) ().
4. ? ()
   
   
   
   
   • , ().
   • , , , (, ).

この種の問題に対処するもう1つの優れたリソースは、ISO C ++コアガイドラインです。



これらの原則はどれも革命的、新しい、またはユニークなものではないことを繰り返しますが、原則の記述に価値がある場合（またはそれを読んだときに誰かが「あは」と言う場合）、この投稿を書くためにビットとトラフィックを無駄にしませんでした。 ...

思い返す

これらは、NDTローカリゼーションアルゴリズムの開発と実装、およびMPCコントローラーでの作業に使用したツール、原則、プロセスの一部です。多くの作業が行われ、楽しかったです。それについて話すのはそれほど面白くありませんでした。



全体的に、私は私が述べたツールと実践をうまく利用しましたが、完全ではありませんでした。



したがって、たとえば、NDTで作業するときは、テスト駆動開発のイディオムには従いませんでした（ただし、すべてを完全にテストしました！）。次に、MPCでテスト駆動型の開発手法を使用しましたが、このプロジェクトはAutoware.Autoに組み込まれたより強力なCIの恩恵を受けませんでした。さらに、MPCプロジェクトは公開されていなかったため、コードレビューのメリットがありませんでした。



どちらのプロジェクトも、静的分析の導入、より詳細なテスト、およびフィードバックの恩恵を受けることができます。しかし、私たちは一人で作成したプロジェクトについて話しているので、行われたテストと受け取ったフィードバックで十分だと思います。静的分析に関しては、より良い、より近いフォームは、一般的に製品開発の関心の領域に入り、オープンソースの開発者コミュニティから離れます（興味深いアイデアが地平線に現れるかもしれませんが）。



2つのアルゴリズムの同時開発については、言うまでもありません。私は、上で概説した原則に従って、できる限りの努力をしました。



私たちは大きな問題を小さな部分に分解する優れた仕事をして（NDTアルゴリズムのMRコンポーネントはもっと小さいかもしれませんが）、広範囲にわたるテストを行ったと思います。予備的な結果はそれ自体が物語っていると思います。

前進運動

実装後、統合の時間です。独自の複雑なコンポーネントを持つ大規模なシステムに接続する必要があります。このシステムは、入力を受け取り、ダイジェストして、アルゴリズムの結果を生成します。システム全体の計画を追跡し、低レベルの問題を修正する必要があるため、統合はおそらくアルゴリズム開発の最も難しい部分です。多くのコード行に誤りがあると、アルゴリズムの統合が妨げられる可能性があります。



これについては、このシリーズの3番目の最後の投稿で説明します。



プレビューとして、開発プロセス中に、mpcコントローラーの使用と統合中に大きなエラーが1つも検出されなかったと言います。確かに、スクリプトの作成、組み立て、テスト、入力データの検証はスキップされ、QoS設定の非互換性に関する問題もありましたが、コードに問題はありませんでした。



実際、ほとんどそのままで（QoSの非互換性を無視してオプションを設定する）実行できました。



同じのようなマイナーな問題の数に走ったNDTアルゴリズム、ために行くの共分散の不安定さ、文字列を検索中にエラー既存のコードでは、と間違って整列マップ。とにかく、箱から出してすぐに作業することもできました。



誰もが見られるように設計された製品には悪くない。



チャンネル登録：

@TeslaHackers — Tesla-, Tesla

@AutomotiveRu — ,

---

:

• - Automotive, Aerospace, (50+)
• [] (, , )
• DEF CON 2018-2019
• [] Motornet —
• 16 , 8
• open source
• McKinsey: automotive
• …