【ITニュース解説】Code Review and Testing – Lessons Learned (OSD600LAB_1)

システムエンジニアを目指す上で、ソフトウェア開発の質を向上させるための重要な工程が「コードレビュー」と「テスト」である。これは、プログラムが正しく動作するかを確認するだけでなく、将来にわたってソフトウェアが使いやすく、変更しやすい状態を保つために不可欠な作業だ。

ある開発者が、オープンソースプロジェクトでのコードレビューとテストの経験から得た教訓について語っている。彼はまず、レビュー対象のツールがどのように動作すべきかを理解するために、プロジェクトのリポジトリにある説明書、つまりREADMEファイルを丁寧に読み込んだ。これにより、ツールの基本的な目的や使い方を把握したのだ。次に、実際にそのツールを自分のパソコンで動かしてみる「ローカルテスト」を行った。このテストでは、正しいファイルだけでなく、存在しないファイル、大きすぎるファイル、ディレクトリなど、様々な種類の入力を与えてみた。これは、ツールがどのような状況でエラーを起こすのか、あるいは予期せぬ動作をするのかを探るための重要なステップだった。テストを通じてツールの振る舞いを観察した後、彼は実際にツールの心臓部であるソースコード、具体的にはJavaScriptファイル（utils.jsとindex.js）を読み込んだ。ここでは、ファイルパスの処理方法、エラーが発生した際の対応、ファイルの読み込みロジックといった技術的な側面に注目し、潜在的な問題点がないかを探したのである。

彼は、コードレビューを行う際、「非同期アプローチ」を好むと述べている。これは、レビュー担当者が自分の都合の良い時間にコードを検証し、問題点を見つけたらそれを文書化し、後でコードの作者にフィードバックするという方法である。この方法の利点は、レビューに十分な時間をかけられるため、プロジェクトの細部にまで深く掘り下げて確認できる柔軟性にある。一方、作者と同時にその場でコードを確認する「同期アプローチ」も、迅速なフィードバックには有効だが、深い検証には不向きな場合もある。非同期アプローチは、より綿密なレビューを行う上で非常に有効な選択肢となる。

他人の書いたコードをテストし、レビューする経験は、彼にとって興味深くもあり、同時に多くの困難を伴うものだった。まず、そのコードがどのように動くのか、その仕組みを理解するまでにかなりの時間を要したという。そして最大の課題は、「開発者が意図していた正しい動作」と「実際に起きているバグ」との違いを見極めることだった。一見するとバグに見えても、それが開発者の意図した仕様である可能性もあるため、この区別は非常に難しい作業である。彼が特に驚いたのは、あるツールが16KBを超えるファイルを何の警告もなしに読み飛ばしてしまう挙動だった。ユーザーはファイルが処理されたと思うかもしれないのに、実際には一部のデータが無視されていたため、これは最終的な利用者にとって大きな混乱を招く可能性があった。本来であれば、このような場合には何らかのメッセージを表示して、ユーザーに状況を知らせるべきであると彼は感じたのだ。

逆に、自分の書いたコードを他の人にテストされ、レビューされる経験もまた、多くの学びをもたらした。当初、彼は自分のコードにまだ未完成な部分や改善の余地があることを自覚していたため、他者から指摘を受けることに対して少々緊張し、最初は不快感さえ覚えたという。しかし、レビューのプロセスを進めるうちに、彼はその考えを改めた。コードレビューは、誰かを批判するためのものではなく、プロジェクト全体をより良いものにするための建設的なプロセスであると気づいたのだ。実際に、レビューを通じて得られた貴重なフィードバックの量に触れたことで、彼はむしろ励まされる気持ちになった。特に驚いたのは、ツールのセットアップ手順が不明瞭であるなど、一見些細に見えるような問題でも、そのツールを使おうとする他の人にとっては大きな障害となり得るという事実だった。これは、機能が正しく動くだけでなく、その使い方を明確に伝えることの重要性を改めて認識させる出来事であった。

今回のテストとレビューの過程で、彼は機能面と使いやすさの両面で様々な問題を発見した。具体的な例として、まず機能面では、存在しないファイルパスをツールに渡した場合に、プログラムが予期せぬ終了（未処理の例外）を起こす問題があった。これは、ファイルの情報取得を行うfs.statSyncという処理の前に、対象のファイルが存在するかどうかを適切に確認していなかったことが原因だった。また、パスを連結する際に、Windows環境で問題を起こす可能性のある「/」記号を直接使用していた「クロスプラットフォーム互換性」の問題も指摘された。Windowsでは「\」を使うのが一般的であり、このような記述は異なるOSでプログラムが正しく動作しない原因となることがある。使いやすさの面では、ツールのREADMEファイルにプロジェクトの要件や具体的な使用方法に関する重要な情報が不足しており、特にnpm linkのような開発者向けのセットアップ手順が不明瞭であったため、新しいユーザーがツールを使い始める際に混乱を招く原因となっていた。最後に、先述の16KBを超えるファイルをサイレントにスキップする問題は、利用者にとって結果が不完全であることすら気づかせないため、大きな混乱を招く可能性があった。これらの問題を通して、彼はエラーハンドリング（プログラムがエラーに適切に対応すること）、クロスプラットフォーム互換性（異なるOSでもプログラムが動作すること）、そして明確なドキュメントの重要性を深く学んだのだ。

彼はレビュー中にいくつかの問題点を具体的にIssueとして記録し、プロジェクトの改善を促した。例えば、「存在しないファイルを与えるとツールがクラッシュする」という問題は、無効なパスに対するエラー処理が欠けていたため、明確なエラーメッセージを表示する代わりに例外をスローしてしまう状況を指摘している。また、「buildTree関数内のパス連結がWindowsで壊れる可能性がある」という問題は、path.join()のようなOSに合わせてパスを生成する関数ではなく、「/」を直接使っていたために、Windows環境で無効なパスが生成される危険性を示した。さらに、「readFileContentsが16KBを超えるファイルを警告なくスキップする」という点では、サイズ制限を超えたファイルが警告なしに無視され、結果として出力が不完全になりユーザーを混乱させることを指摘した。最後に、「READMEに情報が不足し、手順が不明瞭である」という点では、プロジェクトの要件や、npm linkのような具体的な使用方法の記述が不足しており、新しいユーザーがツールをセットアップするのを難しくしていたと述べている。

彼が発見したこれらの問題はまだ全て修正されたわけではない。現在も作業を進めている途中で、READMEの更新のような比較的簡単なものもあれば、より複雑で時間のかかる修正もあるという。

このテストとレビューのプロセス全体を通じて、彼は多くの重要な教訓を得た。コードレビューは単にバグを見つけるだけの作業ではない。それは、ソフトウェアの使いやすさを高め、ドキュメントを改善し、将来にわたってコードが変更しやすく保守しやすい状態を保つための総合的な活動であると学んだのだ。他者のプロジェクトをテストする経験は、自分の書いたプログラムがユーザーにどのように使われるか、どのような問題に直面するかについての貴重な洞察を与えてくれた。そして彼は、機能するコードを書くことと同じくらい、ユーザーに状況を正確に伝える明確なエラーメッセージや、分かりやすいドキュメントを提供することが重要であるという結論に至った。これらの学びは、システムエンジニアとして高品質なソフトウェアを開発していく上で、非常に重要な視点となるだろう。