【ITニュース解説】🚀Life of a Software Engineer: How I Patched an NPM Package and Saved the Day

システム開発の現場では、予期せぬトラブルが発生することが少なくない。あるプロジェクトで、まさにそのような問題が突然持ち上がった。それは、ウェブブラウザ上で動くアプリケーションで、PDFやその他のドキュメントを生成する機能に関するものだった。最新のGoogle Chromeブラウザのアップデートがリリースされたことをきっかけに、これまで数秒で完了していたはずのドキュメント生成処理が、突然10分から15分もの長い時間を要するようになってしまったのだ。この遅延により、アプリケーションは処理中にフリーズし、利用者は操作不能な状態に陥り、結果としてドキュメント生成機能は事実上使用できない状況に追い込まれた。

この問題の原因は、プロジェクトで長らく使用されてきたhtml2pdf.jsというJavaScriptライブラリにあった。このライブラリは、HTML形式のコンテンツをウェブページ上に描画されるキャンバスという領域に変換し、それをPDFとして出力する役割を担っていた。しかし、その内部で利用している別のライブラリであるhtml2canvasが、Chromeの最新のレンダリング（表示）方式の変更に適切に対応できていなかったため、処理が極端に遅くなってしまったのである。ここで注意すべきは、利用者側のブラウザ（クライアントサイド）でこのような重いドキュメント生成処理を行うことは、本来は推奨されない方法であるという点だ。ウェブサーバー側（サーバーサイド）で処理を行う方が、パフォーマンスや安定性の面で安全な選択肢とされている。しかし、このプロジェクトでは既にクライアントサイドでの実装が進んでいたため、その方式で解決策を見つける必要があった。

開発チームは、まずサーバーサイドでのドキュメント生成への移行を検討した。具体的には、ウェブサイトの自動操作ツールであるPuppeteerとテンプレートを組み合わせて導入を試みた。しかし、これは単純な構成のドキュメントには有効であったものの、プロジェクトで必要とされる複雑なレイアウトや多数のデータを扱うドキュメントでは、期待通りの結果を得ることができず、この方法は断念せざるを得なかった。次に開発者が取った行動は、問題解決の糸口を探るために、関連するライブラリのGitHubリポジトリ（ソフトウェアのソースコードが公開され、開発者が共同で開発を進めるプラットフォーム）の「Issue」（バグ報告や機能改善の要望、議論などが記録される場所）を徹底的に調査することだった。同じような問題に直面している開発者がいないか、あるいは既に解決策を見つけて公開している人がいないかを根気強く探し続けた結果、html2canvasの代替として利用できるSnapdomという、非常に有用なライブラリを発見した。

この発見を基に、開発者は自らhtml2pdf.jsのソースコードを入手し、詳細な調査と修正作業に取り掛かった。何時間もの分析を経て、html2canvasが実際にパフォーマンスのボトルネックとなっている特定の関数を突き止めた。ここが今回の解決における最も重要な部分である。開発者は特定した関数内でhtml2canvasが呼び出されている箇所を、新しく見つけたSnapdomに置き換える修正を直接ソースコードに加えたのだ。さらに、Snapdomが既存のシステムで正しく動作するように、関数の引数（処理に渡す値）を微調整した。この修正されたhtml2pdf.jsのコードを、元々のプロジェクト（このケースではAngularというウェブアプリケーションフレームワークが使用されていた）に組み込み直したところ、問題は劇的に解決した。

結果として、既存のプロジェクトコードに対してはほとんど変更を加えることなく、ドキュメントの生成とダウンロード時間は再び数秒に短縮された。この一連の修正作業には、集中して取り組んだ結果、約一日を要したが、以前試行錯誤していたヘッドレスブラウザ（画面を持たないブラウザ）を使った無駄な探索に比べれば、はるかに短期間で、かつ効果的な解決策だったと言える。このような、既存のライブラリ（パッケージ）の内部コードを直接修正し、プロジェクトの課題を解決する行為は、「依存関係のパッチ適用」と呼ばれる。これは、公式なアップデートを待つ時間がない場合や、特定のプロジェクトの要件に合わせてカスタマイズが必要な場合に用いられる、システムエンジニアにとって重要な問題解決手法の一つである。

今回の経験からは、いくつかの重要な教訓が得られた。まず一つ目は、Node.jsのパッケージマネージャーであるNPMが発する「警告」に常に注意を払うことの重要性だ。これらの警告を無視することは、将来的に発生する可能性のある問題から目を背ける行為に等しい。二つ目は、コードの修正に取り掛かる前に、入念な「調査」を行うことの価値である。インターネット上には、同じような問題に直面し、既に解決策を見つけて公開している先人たちが多く存在する。彼らの知見を最大限に活用することで、開発時間を大幅に短縮できる可能性が高まる。三つ目は、今回のような「一時的な解決策」も、時には非常に有効であるという点だ。完璧な長期的な解決策を探すのに時間がかかる場合でも、一時的な修正で喫緊の問題を乗り越えることで、プロジェクトの進行を止めずに、より良い恒久的な解決策をじっくりと検討する時間を稼ぐことができる。最終的に、全てをゼロから書き直すという大がかりな作業を行うのではなく、問題の核心となっている特定の箇所をピンポイントで修正することが、最も早く前進するための道である場合がある、ということをこの経験は示している。