|
「物理分析」という用語は、同僚の @NoaLand が推奨する書籍「Large-Scale C++ Programming」に記載されている物理設計に由来しています。 物理設計は、システム内の物理的な実体とそれらの相互関係を研究する学問です。論理設計はアーキテクチャ構造のみを研究しますが、物理設計は組織的な問題を研究します。 この本でいくつかの概念をざっと概観した後、物理設計アプローチ全体についてより深く理解することができました。そこで、*システムリファクタリング・マイグレーションガイド*で紹介されている「4段階リファクタリング」を取り入れることで、以前から持っていた考えを再確認しました。それは、特定の言語で設計されたシステムが妥当かどうかを分析するために、その言語に精通した開発者である必要はないということです。（追記：これは、私が既に複数の言語のコピー＆ペーストに精通していることを前提としています。） したがって、アーキテクチャの専門家になるために必要なのは、物理設計を分析する方法を学ぶことだけです。これは、どのプログラマーでもできることです。 この一連の理論は、いくつかの基本的な前提に基づいています。
ここでは、GitHub の Inherd オープンソース チームによって開発された研究開発パフォーマンス分析ツールである Coco を使用します (https://github.com/inherd/coco)。 この記事では、Redis のケーススタディを使用しています。オンライン版はこちらをご覧ください: https://inherd.org/cases/redis/ 「物理的な」アーキテクチャ設計 パッケージとは、私たちが知っているように、複数のコンポーネントを単一の物理的なまとまりのある単位にまとめたものと定義できます。パッケージはフォルダという形で構成され、その中の個々の物理単位はファイルです。ファイルへの変更を監視することで、フォルダの変更を検出し、ひいてはパッケージ全体の変更を監視できます。 これらの物理的な変更により、パッケージが安定しているかどうかを判断でき、そのサイズは全体的な設計の合理性を示します。以下は、2020年3月1日以降のRedisのさまざまなモジュールのソースコードの変更点です。 Redisの変更 (追記: この画像はインタラクティブな Web ページからのものです。左側のカラフルなセクションは src/ で、これがメインのソース コードです。右側は依存モジュール、上部はテスト モジュールへの変更を示しています。) 上記の画像から: 頻繁に変更されるモジュールを観察します。これにより、どのモジュールが最も変更されているかが明確にわかります。ビジネスコードの場合、タイムラインを使用することで、異なる期間にわたる変更を観察できます。 パッケージサイズを把握しましょう。画像では、redis-cli.c:41 です。41 は 2020 年 3 月 1 日以降の変更回数を表しています。ファイルにマウスを合わせると、7012 行あることがわかります。 「システム リファクタリングおよび移行ガイド」で定義されている高参照、高変更関係に基づきます。 高い引用数 - 高い改変数 行数が多く、頻繁な変更がパッケージを非常に不安定にし、エラーが発生しやすくすることを示すために、やや精度の低いモデルを提案することもできます。ビジネスシナリオでは、業務A用の関数を実装したにもかかわらず、それが業務B用に頻繁に変更されている場合、参照は不正確であり、ある程度の結合があることを示しています。 変更頻度 変更頻度は非常に興味深い指標です。バージョン管理ツールから、変更履歴に関する情報を得ることができます。まとめると、一般的に知られている事実には以下のようなものがあります。
次の図は、すべての Redis コミットと時間の関係を示しています。 Redis コミット貢献 グラフを見ると、2014年から2015年にかけて多くのコードコミットが行われたことがわかります。これをその後のリリース頻度と比較すると、この期間に多くの新バージョンがリリースされたことがわかります。これらの現象は、以下のことを示唆している可能性があります。
これに加えて、あまり興味深くないもう 1 つの指標は、行数の変化です。 Redisラインの歴史 グラフからわかるように、2011年から2012年頃にコード量が劇的に変化しました。これは、機能ブランチの仕組みを導入したことが原因だと思います。つまり、開発が完了した後にのみ、機能がメインブランチにマージされるのです。 この傾向は、以下のリリース頻度からもわかります。 リリース頻度と展開 Git でリリース頻度の情報を確認するには、次の 2 つの部分だけを確認します。
以下は、Redis の分岐履歴です。 Redis ブランチ この図は、ARMやACLログといったRedisのさまざまな機能の開発状況を明確に示しています。また、バージョン2.8に加えられた変更がバージョン3.0以降にも反映されているなど、バージョンごとのメンテナンス状況も示しています。 同様に、Redis はソフトウェアのデプロイメントに標準的な Git プラクティスを使用しているため、2019 年のタグから全体的なソフトウェアのデプロイメント ステータスを確認できます。 Redisタグ わあ、上の画像を見るとバージョン6.0ですね。信じられないくらい速いですよね？5.1.xなんていらなくて、一気に666に進化しました！ 学習コストと知識管理 ソフトウェア開発は知識の生産と消費のプロセスです。—「ソフトウェア開発管理がなぜ難しいのか」より プロジェクトの難易度は、開発者のレベルや段階（技術準備、事業回復、成長の最適化、アーキテクチャの進化など）によって異なります。理論的には、開発者の提出内容を調べて学習曲線を測定することで、これを分析できます。開発者が提出する提出回数は、時間の経過とともに徐々に増加し、最終的には安定します。 したがって、Redis プロジェクトからこのモデルを構築しようとしました。 Redis 曲線 しかし、それは失敗に終わりました。後に、このモデルはオープンソースプロジェクトには適していないことが判明しました。 商用ソフトウェアと比較すると、オープンソースソフトウェアはより動的です。チームのライフサイクルは6ヶ月を超えることはほとんどなく、様々な形で頻繁に再編成されます。—『ソフトウェアの道：ソフトウェア開発における議論の的となる問題の分析』より ただし、これは通常のソフトウェア開発チームにも適用できると考えています。 その後、私たちはこの問題を再検討し、個人の提出時間を使用してプロジェクトの安定性と知識の普及の信頼性を評価するという、オープンソースプロジェクトに適したモデルを再考しました。 以下は、Redis プロジェクトにおける開発者の最初のコミットと最後の開発時間のタイムラインです。 Redisメンバー これは、オープンソースプロジェクトの典型的なチームモデルを反映しており、通常は少数の開発者のみが関与します。商用ソフトウェアの場合、上記のタイムラインであれば開発を継続できます。しかし、コア開発者がチームを離れると、プロジェクトは非常に不安定になり、ソフトウェアには多数の未知のバグが蔓延することになります。 他の この観点から見ると、Cocoはアーキテクチャ分析への参入障壁を下げているのではないでしょうか。ぜひCocoをお試しください。GitHubから直接ダウンロードできます: https://github.com/inherd/coco/releases この記事で紹介した解析内容の一部は、私が以前作成した解析ツールCocaに既に組み込まれています。しかし、構文解析のコストが高いため、Cocoでは軽量な解析手法を採用しました。今後の記事で、より多くの実装方法を紹介する予定です。また、WeChat ID phodal02（Inherdを指定してください）を追加して、関連する議論に参加することもできます。 この記事では Redis のケーススタディを使用しています。オンライン版はこちらをご覧ください: https://inherd.org/cases/redis/ 関連リソース: 《ポリグロットコードエクスプローラーのご紹介》 「あなたのコードは犯罪現場だ」 この記事はWeChat公式アカウント「phodal」から転載したものです。以下のQRコードからフォローできます。転載の許可については、「phodal」公式アカウントにお問い合わせください。 |
DUICUO
ランダムにおすすめされた記事
-
VSCodium: 100% オープンソースの VS Code
2026-01-04
-
以下に、推奨される XML 解析ツールをいくつか紹介します。非常に便利です。
2026-01-03
-
DeepSeek が FlashMLA をオープンソース化しましたが、これはいったい何なのでしょうか? (やっと分かりました...)
2026-01-03
-
オープンソース テクノロジーにおける 5 つの主要なオープンソース ライセンスを見てみましょう。
2026-01-04
-
Xshell と iTerm2 とはお別れです。このオープンソースのターミナル ツールは本当に素晴らしいです。
2026-01-04
-
オープンソース ソフトウェアを作成したが、特許を申請しておらず、訴訟を起こされた場合はどうすればよいですか?
2026-01-04