記事「KnitPkgを用いたMQL5向けパッケージベース開発手法」についてのディスカッション

[MetaQuotes]

新しい記事「KnitPkgを用いたMQL5向けパッケージベース開発手法」はパブリッシュされました:

MetaTrader向けにMQLを用いた高い信頼性と生産性を備えた開発を実現するため、MQL5/MQL4向けのプロジェクトマネージャであるKnitPkgを利用した、再利用可能な「パッケージ」を中心とする開発手法を紹介します。パッケージは、他のパッケージを構成する土台として利用できるだけでなく、EAやインジケータなど、MetaTraderプラットフォーム上で直接動作する最終成果物の基盤としても活用できます。

トレーダー兼開発者は、同じ数学ライブラリやユーティリティコードを共有する複数のMQL5プロジェクト（EA、インジケータ、ユーティリティなど）を保守することが少なくありません。現在、このようなコードの再利用は、プロジェクト間でフォルダをコピーし、#include文を手作業で修正するという従来の方法でおこなわれることが一般的です。しかし、更新を重ねるたびにバージョンの不整合が発生し、一方のプロジェクトには修正が反映されていても、別のプロジェクトには古いファイルが残るという状況が生じます。その結果、「クリーンなMetaTrader環境」でのビルドは、各ターミナルでこれまでにおこなわれた手作業の修正内容に依存してしまいます。本来必要なのは、コンポーネントをGitリポジトリで一度だけ実装し、SemVerによるバージョン管理をおこない、それを複数のプロジェクトから再利用できる仕組みです。そのような仕組みがあれば、インストールやビルドはどの環境でも再現可能となり、依存関係は固定され、成果物（#includeツリーまたは単一のヘッダーファイル）は自動生成されます。また、プロジェクト間でコードを移動するたびにパスを書き換えたり、ファイルをコピー＆ペーストしたりする必要もなくなります。

本記事では、このようなワークフローをMQL4/MQL5向けにKnitPkgパッケージを利用して実現する方法を紹介します。それぞれの機能を再利用可能でバージョン管理されたコンポーネントとして定義し、コピー＆ペーストではなくマニフェストを通じて各プロジェクトから利用します。本記事を通して、このアプローチがEAやインジケータ間での再利用、ビルド、公開をどのように堅牢なものへと変え、断片的なコードを、依存関係を明示的に管理できる土台へと整理するのかを説明します。

作者: Douglas Nascimento Rechia

[Stanislav Korotky]

面白そうですが、少し疑問があります。

もし誰かが、KnitPkgによって管理されるはずのMQL5プロジェクト／プログラム／パッケージを含むGitリポジトリ をクローンした場合、リポジトリ内に自動生成ファイル（_flatなど）が欠落しているため、コンパイルできないソースコードが得られる可能性が高いでしょう。 取得方法にかかわらず、リリースがコンパイル可能になるよう、必要な自動生成ソースをすべてGitにコミットするのは実現可能ではないでしょうか？

実際に自動生成されたコードをコンパイルしてデバッグしているため、依存関係に変更を加えるのがどれほど便利になるかは定かではありません。対応するオリジナルコードに簡単に「ジャンプ」できないのですが、何か見落としている点があるのでしょうか？ 例えば、インジケーター（あるいはエキスパートアドバイザー）の開発中に、barパッケージを変更する必要が生じたとします。その場合、どのように対応しますか？

最後に、サンプルコードの実装についていくつか疑問があります（おそらく単なるサンプルだからでしょうが）。例えば、各ティックやバーごとに`new`や`delete`が呼び出されている点などです。また、例えば次のようなコードがあります：

int OnCalculate(const int32_t rates_total,
                const int32_t prev_calculated,
                const int32_t begin,
                const double &price[])
{
   ...
   douglasrechia::TimeSeriesArray<double> priceArray(price, prev_calculated - InpSMAPeriod - 1, rates_total-1, false);
   ...
   for (int shift=shiftStart; shift >= 0 && !IsStopped(); shift--)
   {
      SMABuffer[shift] = douglasrechia::SMA(priceArray, InpSMAPeriod, shift);
   }
   ...
}

price 配列をpriceArrayの コンストラクタ（そこで配列の一部がコピーされる）に渡してから、そのpriceArrayを SMA に渡すのはどのような目的があるのでしょうか？コピーせずに、元のprice 配列を参照渡しでSMA に渡せばよいのではないでしょうか？

[Douglas Nascimento Rechia]

Stanislav Korotky Gitリポジトリ をクローンした場合、リポジトリ内に自動生成ファイル（_flatなど）が欠落しているため、コンパイルできないソースコードが得られる可能性が高いでしょう。 取得方法にかかわらず、リリースがコンパイル可能になるよう、必要な自動生成ソースをすべてGitにコミットすることはできないでしょうか？

実際に自動生成されたコードをコンパイルしてデバッグしているため、依存関係に変更を加えるのがどれほど便利になるかは定かではありません。対応するソースコードに簡単に「ジャンプ」できないのですが、何か見落としている点があるのでしょうか？ 例えば、インジケーター（あるいはエキスパートアドバイザー）の開発中に、barパッケージを変更する必要があるとします。その場合、どのように対応しますか？

最後に、サンプル実装のいくつかの点（おそらく単なるサンプルだからでしょうが）について疑問を感じています。例えば、ティックやバーごとに new/delete を行っている点などです。また、例えば次のようなコードがあります：

price 配列をpriceArrayコンストラクタ（そこで配列の一部がコピーされる）に渡してから、そのpriceArrayを SMA に渡すのはどのような目的があるのでしょうか？コピーせずに、元のprice 配列を参照渡しでSMA に渡せばよいのではないでしょうか？

スタニスラフさん、

記事をお読みいただき、これらの点を指摘してくださりありがとうございます。

生成されたコードのコミットについてですが、KnitPkgの考え方は、自動生成されたアーティファクト（フラットヘッダー、解決済みのインクルードなど）はGitリポジトリ内に存在すべきではない、というものです。そうしないと、事実上リポジトリ間でコードが重複し、同期がずれるリスクが生じるからです。 ある機能がパッケージ／リポジトリ内で実装されている場合、それが唯一の「真実の源」となります。利用者は（SemVerの範囲を使用して）依存関係を宣言し、kp install や kp autocomplete に、派生ファイルをローカルで再生成させます。 こうすることで、許可された SemVer 範囲内で依存関係が更新された際、プロジェクトは自身のリポジトリにコミットされた古い生成コードに「縛られる」ことなく、新しいバージョンをスムーズに反映できます。依存関係のバージョンを更新する具体的な例は、こちらの ドキュメントに記載されています。

「依存関係に変更を加えるのがどれほど便利か」というご懸念についてですが、これはツールを設計する際に私が考慮した点でもあります。KnitPkgはローカル依存関係の使用をサポートしているため、プロジェクトをローカルディレクトリにあるパッケージに直接指定し、そのパッケージを修正して、開発中に実際の利用プロジェクトで変更をテストすることができます。 このワークフローの詳細については、KnitPkgのドキュメントの「ローカル依存関係」セクションに説明があります：https://docs.knitpkg.dev/user-guide/local-dependencies/

price → TimeSeriesArray → SMA についてですが、ここでの意図は、最も効率的な微細な最適化を示すことではなく、標準化されたインターフェースを示すことにあります。SMA は ITimeSeries（TimeSeriesArray そのものではありません）を受け取り、「最新データがインデックス 0、次が 1、というように並んでいること」のみを重視します。 TimeSeriesArrayは、例で使用されている実装の一つに過ぎず、たまたまpriceのスライスをコピーしているだけです。他の誰かが、キャッシュに優しい構造を用いた別のITimeSeriesを実装することも可能です。重要なのは、計算と具体的な格納レイアウトを切り離すことです。ITimeSeriesの実装がいかにスマートで効率的であるかは、設計と創造性の問題となります。

こうした設計上の選択についてはいつでも喜んで議論しますし、KnitPkgに関するフィードバック（ワークフローやサンプルコードについてでも）は大歓迎ですので、これらのアイデアについて遠慮なく異論を唱えたり、発展させたりしてください。