【ITニュース解説】OSD600: First step

システムエンジニアを目指す人にとって、プログラム開発だけでなく、他の人と協力してより良いソフトウェアを作り上げるための重要な経験について解説する。

今回の経験は、クラスメイトとペアを組み、互いのプログラムをレビューし、改善点を提案し合うというものだった。これは単にコードを書くスキルだけでなく、チーム開発で不可欠な、他者の視点を取り入れる貴重な機会となった。同じ課題に対し、人によってアプローチや解決方法が異なることに気づき、自分では思いつかないようなアイデアや改善点を発見できるのが、コードレビューの醍醐味である。

このコードレビューでは、「非同期（Async）」というアプローチを選択した。非同期とは、リアルタイムでチャットツールを使って意見交換するのではなく、各自が都合の良い時間に、じっくりと相手のコードを分析し、GitHubのような開発プラットフォームで使われる「Issue」という機能（これは課題や改善提案、バグ報告などを記録し、管理するためのチケットのようなものだ）を使ってフィードバックを書き込む方法だ。この方法の最大の利点は、時間をかけて深くコードを読み解ける点にある。また、すべてのフィードバックが記録として残るため、後からいつでも参照できる。これにより、問題点を整理しやすくなり、プロジェクトがどのように改善されたかを追跡する上でも非常に有効だった。

具体的にレビューしたコードは、Pythonで書かれた、Gitリポジトリの情報を一つのテキストファイルにまとめるプログラムだった。クラスメイトのコードは非常に構造がしっかりしており、特にargparseとpathlibというPythonのライブラリが効果的に使われていることに感銘を受けた。argparseは、プログラムをコマンドラインから実行する際に、例えば「-o 出力ファイル名」のようにオプションを指定できるようにするためのライブラリであり、プログラムの柔軟な操作を可能にする。pathlibは、ファイルやディレクトリのパスを扱いやすくするライブラリで、パスの結合や操作を直感的に行えるようにする。自分もargparseを使う必要は認識していたが、pathlibの活用方法はクラスメイトのコードから学ぶことができた。

また、実装を始める前に、プログラム全体の基本的な構造を先に組み立てておくことの重要性も再認識した。クラスメイトは、まだ実装されていない機能の場所に「TO BE IMPLEMENTED」（これから実装する）といったタグを付けて、必要な関数（ヘルパー関数と呼ばれる、特定の小さな処理を行う部品）の骨格だけを先に用意していた。これは、全体像を把握しやすくなり、後で具体的な処理を書き加えていく際の道しるべとなる。

コードレビューを通じて、いくつかの「Issue」（課題や改善提案を記録するチケット）を立てた。レビューしたコードはまだ開発の初期段階で、「TO BE COMPLETED」（未完了）とマークされた部分が多かったため、ドキュメントに関するIssueを2つ、機能実装に関するIssueを2つ作成した。

最初のIssueは、README.mdファイルにPython環境のセットアップ方法や必要なライブラリのインストール手順が不足していたことに関するものだ。README.mdは、プロジェクトの「取扱説明書」のようなものであり、新しくプロジェクトに触れる人がスムーズに開発を始められるよう、丁寧な説明が不可欠である。もう一つのREADME.mdに関するIssueは、プロジェクトにライセンスファイルは存在していたものの、その情報がREADME.mdに明記されていなかった点だ。オープンソースプロジェクトにおいて、ライセンスは誰がどのようにそのコードを使えるかを明確にするために非常に重要であるため、README.mdでの明記が推奨される。

機能実装に関するIssueとしては、Gitリポジトリの詳細情報を取得する役割を持つwrite_git_info関数と、ディレクトリ構造をツリー形式で生成するwrite_struct_tree関数が「TO BE IMPLEMENTED」の状態だったため、これらを具体的な実装タスクとしてIssueに登録した。これにより、未着手の機能が明確になり、進捗を管理しやすくなる。

次に、自分の書いたコードが他の人にレビューされる経験についてだ。最初は、自分の書いたものが他人の目に触れることに少し恥ずかしさを感じた。しかし、チームメイトが作成してくれたIssueを見て、その感情は大きく変わった。フィードバックは批判ではなく、プロジェクトをより良くするための具体的な提案であると気づいたのだ。

自分のコードに対して指摘されたIssueはいくつかあった。一つは、ディレクトリ構造をツリー形式で表示する部分で、単にファイルの一覧を羅列しているだけで、期待通りのツリー構造になっていなかった点だ。これは自分でも認識していたが、改めてIssueとして明確にされたことで、優先的に取り組むべき課題となった。また、ファイルの絶対パスを正しく表示するつもりだったにもかかわらず、実際には機能していなかったというバグも発見された。これは、自分でいくら確認しても見つけられなかったバグであり、クラスメイトのレビューのおかげで気づくことができた。人の目が入ることで、思い込みによる見落としを防げる良い例だ。さらに、まだ実装に着手していなかった-oオプション（出力ファイルを指定するオプション）についてもIssueが立てられた。人間の記憶は曖昧なため、Issueとして記録することで、やるべきことを忘れずに、計画的に作業を進められるようになる。

この一連のラボを通じて、いくつかの重要な教訓を得た。まず、これまで深く考えていなかったREADME.mdファイルの重要性についてだ。README.mdは、プロジェクトの第一印象を決め、他の人がプロジェクトを理解し、参加するきっかけを作る。つまり、プロジェクトの顔となる文書である。次に、建設的なフィードバックは決して批判ではないということだ。フィードバックは、プロジェクトの改善点を示し、潜在的な欠陥やバグに自分で気づく時間を大幅に節約してくれる、非常に価値のあるものである。そして最後に、Issueがいかに効果的なツールであるかに感銘を受けた。漠然としたアイデアやバグ報告が、Issueを通じて明確で整理されたタスクへと変わり、次に何をすべきか、どこに向かうべきかの具体的な方向性を示してくれる。プロジェクト開発において、Issueは迷いをなくし、効率的に作業を進めるための羅針盤のような役割を果たす。