【ITニュース解説】OSD600 Lab 4

システムエンジニアを目指す初心者の皆さん、ソフトウェア開発において他の開発者と協力しながら新しい機能を実装する過程は、非常に重要で多くの学びがある。今回は、Gitというバージョン管理システムを用いて共同作業を行い、既存のソフトウェアに機能を追加する具体的なプロジェクトを通して、その技術的な側面と開発のプロセスを解説する。

この開発プロジェクトの主な目的は、Gitのリモートリポジトリとマージ機能を使った共同作業を実践することだった。プログラミング言語はC++が選ばれ、Python経験が豊富な開発者にとって、C++での開発は新たなスキル習得の機会となった。

今回実装した機能は、ソフトウェアのコマンドライン引数（CLI引数）を、TOML形式の設定ファイルで指定できるようにすることである。CLI引数はプログラムの動作を制御するオプションだが、設定ファイルを使うことで、よく使う設定を一度記述しておけば、毎回長いコマンドを打ち込む手間を省けるという利点がある。

プロジェクト開始にあたり、まだプルリクエスト（PR）が出ていない既存のC++リポジトリを選定し、オーナーにissueを立てて許可を得てから着手した。C++の経験が浅かったため、TOMLファイルをC++で扱う方法や、既存コードへの組み込み方を調査することから始めた。「tomlplusplus」というライブラリがTOMLファイルの解析に適していることを見つけ、既存のCMakeファイルを使ってこれをプロジェクトに組み込んだ。

tomlplusplusの導入後、「loadFromConfig」という新しい関数をコードに追加した。この関数は、config.tomlという設定ファイルを読み込み、そこに記述されたオプション値（例えば、出力ファイル名、含めるべきファイルのパターン、除外するファイルのパターン、最近更新されたファイルのみを対象とするか、など）を、プログラム内部でCLIオプションを管理する構造体（Options struct）に設定する役割を担う。これにより、ユーザーは頻繁に使う設定をconfig.tomlに一度記述すれば、毎回コマンドラインで指定する必要がなくなる。

具体的な実装では、まずtoml::parse_file(path)でTOMLファイルを解析し、内容をテーブル形式で読み込む。次に、tbl["キー"].value<std::string>()のような形式で各オプションの値を読み出し、プログラム内部の変数に格納する。例えば「include」オプションのように、単なる文字列だけでなく、そのパターンを使ってファイルをフィルターするような特別な処理が必要な場合は、読み込んだパターン文字列を基にラムダ式という無名関数を作成し、フィルター関数として設定するといった工夫も行った。

実装中に直面した課題の一つに、「include」オプションがTOMLファイル経由で期待通りに動作しない問題があった。「output」オプションは問題なかったが、「include」オプションは、onlyIncludedExtensionsのような特定のフィルター関数を通す必要があったにもかかわらず、TOMLファイルからの読み込み時にその処理を適用していなかったことが原因だった。コマンドラインから指定する場合は自動的に適用されるフィルターを、設定ファイルからの読み込み時にも適用するよう修正することで解決した。

次に、設定ファイルの読み込み機能をプログラムのメイン処理に組み込んだ。main.cppでは、CLI引数を解析する既存の処理に加えて、今回作成した設定ローダー（config::loadFromConfig）を追加した。そして、オプションのマージロジックを実装し、コマンドライン引数が設定ファイルの設定よりも優先されるようにした。例えば、config.tomlにoutput = "report.md"とあっても、--output custom.mdと指定すればcustom.mdが使われる。CLI引数が空で、TOML設定ファイルにも項目がなければ、プログラム内部のデフォルト値が使われる。

開発中に、コードを変更してもプログラムの動作が変わらないという問題に遭遇した。これは、コードを修正するたびに新しいビルドを作成し直していなかったため、常に古いバージョンのプログラムをテストしていたことが原因だと判明した。このような初歩的なミスに気づくまで時間がかかってしまったが、これは開発においてよくある落とし穴の一つである。

正しくビルドした後、以下のようなサンプルconfig.tomlファイルを使って機能をテストした。

Copy
1output = "report.md"
2include = ""
3exclude = "LICENSE"
4recent = true

この設定ファイルが置かれた状態でrepoctx .のようなコマンドを実行すると、report.mdへの出力やLICENSEファイルの除外といった設定が自動的に適用されることを確認できた。もちろん、--output custom.mdのようにコマンドラインで引数を渡せば、設定ファイルの内容を一時的に上書きすることも可能だ。

機能実装とテストが完了した後、変更内容と使用例を文書化し、プルリクエストを提出した。プロジェクトの作者からは、不要なファイルの削除、コードコメントの追加、そしてブラケットのフォーマット修正（IDEの自動フォーマットが原因）を依頼された。これらの修正を適用した後、変更はプロジェクトに無事マージされた。

Gitの操作については、大きなトラブルはなかったが、プルリクエストのマージをコマンドラインではなく、GitHubのウェブUIやVSCodeのGit機能を使って行ってしまった点が反省として挙げられる。コマンドラインでの操作に慣れることは、より複雑な状況に対応するために重要である。

リモートリポジトリを使ったテストは有効だった。ブランチを作成し、他の開発者の作業や自身の既存作業を上書きする心配なく、自由に試行錯誤できた。例えば、他の開発者が作成したTOMLファイルが自分の作業ディレクトリと異なる場所にあり、プログラムが設定ファイルを認識しないという問題を発見し、ファイル構造に関する問題を解決できた。

他の開発者が提出した課題の解説は明瞭で、そのプルリクエストもテストでは問題なく、変更内容も分かりやすく説明されていた。このように、共同開発ではお互いのコードをレビューし、フィードバックし合うことが、プロジェクト全体の品質向上に繋がる重要なプロセスである。