ライブラリのコードをレビューするときに考えていること

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。

こんにちは。 モバイルエンジニアの臼井(@usuiat)です。

私はサイボウズで主にGaroonモバイルのAndroidアプリの開発をしていますが、最近は社内向けライブラリの開発にもレビュアーとして参加しています。 この記事では、ライブラリのコードをレビューするときに私が考えていることを言語化してみたいと思います。

開発に参加しているライブラリ

レビュアーとして開発に参加しているライブラリは、DroidKaigi 2025で同僚の@mr_mkeeda「そのAPI、誰のため? Androidライブラリ設計における利用者目線の実践テクニック」と題した発表の中で紹介していたライブラリです。 サイボウズのサービスにアクセスするときに必要な認証を行うAndroid用ライブラリで、さまざまな方式の認証処理と、それを実現するUIをセットで提供するライブラリです。 ライブラリの開発では、私はコードはほとんど書かず、レビュアーとして参加しています。

ライブラリ利用者側の視点に立つ

ライブラリのコードをレビューするときに私が考えていること、まず1つめは、ライブラリの利用者側の視点でレビューするということです。

mr_mkeedaの発表でも言及されていたように、ライブラリ開発では利用者の視点が大切です。 もちろん実装するときも利用者の視点を意識しているはずですが、そうは言っても、実装に集中しながら開発者と利用者の両方の視点でコードを見るのは大変だと思います。

そこで、実装担当者以外のレビューが有効になると考えています。 自分がこのライブラリを利用してアプリを開発することを想像したときに、APIが使いやすい形で公開されているか、APIの使い方に困ることはないか、といった視点でレビューするようにしています。 実装者から抜け落ちやすい視点を補うことが、レビュアーの大事な役割だと思います。

使い始めの体験を重視する

ライブラリ利用者の視点に立つことにも関連しますが、ライブラリを使い始める際のハードルをなるべく低くすることが重要だと考えています。 そうすることでライブラリを導入しやすくなり、ライブラリが普及するからです。

認証ライブラリの例を紹介します。

サイボウズの製品は複数の認証方式をサポートしていて、プロダクトとしてモバイルアプリを提供する場合は基本的に全て対応する必要があります。 認証ライブラリもその前提で作られていて、当初は各種認証方式で必要な設定値をすべてAPIの引数に指定する仕様になっていました。

しかし、アプリの試作を素早く行いたい場合などは、パスワード認証だけ動けば十分な場合もあります。 そのような場合に、最小限のパラメータ指定で「このAPIだけ呼べばとりあえず使える」という身軽さは大切です。

そこで、基本的な動作はデフォルト値でサポートしつつ、オプションのパラメータを指定することで想定されるすべてのケースに対応可能にしておくことを提案しました。 こうしておけば、使い始めのハードルを下げつつ、プロダクトレベルに対応できるライブラリになります。

使い始めのハードルを下げる提案
使い始めのハードルを下げる提案

コードの可視性を意識してコメントする

ライブラリのコードは、ライブラリのユーザーが見る部分とそれ以外とで、レビューの観点を変えるようにしています。

ライブラリのユーザーが見るコードは、publicなAPIの定義やドキュメント、サンプルアプリなどです。 これらは、初見で理解できるわかりやすいコードになっているか?という観点でレビューしています。 ライブラリの内部構造など、開発者しか知らない知識が前提になっているコードがあったら、コードを修正するか、ドキュメントやコメントで説明することを提案します。

一方、ライブラリの内部実装コードは、publicなAPIに比べるとコードのわかりやすさは重視していません。 とはいえ難解なコードでも問題ないというわけではなく、自分が開発を引き継ぐことになったときにコードの意図を理解できるか?という観点でレビューするようにしています。

指摘のスタンスを示す

これはライブラリに限った話ではありませんが、別チームの開発にレビューだけかかわる場合に気をつけていることです。

私は普段は別チームで開発しているので、ライブラリの開発者とのコミュニケーションはGitHubのコメントが中心になります。 そのため、コメントの意図や重要性が間違って伝わらないように、コメントに対する自分のスタンスを言葉で残すようにしています。 具体的には、「提案」「質問です」「反映するかはおまかせ」「スルーしてもOK」などです。 「IMO」などの略語も使いますが、ニュアンスが正しく伝わるようになるべく言葉で示すようにしています。

スタンスの表明
スタンスの表明

おわりに

この記事では、社内ライブラリのコードレビューで私が考えていることをお伝えしました。 コードをほとんど書かないレビュアーとして開発にかかわるのは私自身初めての経験だったのですが、コードを書かないからこそ提供できる客観的な視点でレビューすることを意識すると、これまでは気にならなかった部分が気になるようになってきて、私としても学びがありました。 今後も引き続き、利用者にとって使いやすいライブラリを作ることを考えて開発していきたいと思います。