Swiftに足りなかったものを作る - スター数13,000超の「Kingfisher」を生み出したonevcatの着想術

画像を取り扱う軽量なSwiftライブラリ「Kingfisher」が獲得したスター数はなんと13,000以上。圧倒的な支持を集めるOSSを作り続けるonevcatさんに、発想の源を聞きました。

Swiftに足りなかったものを作る - スター数13,000超の「Kingfisher」を生み出したonevcatの着想術

初めて作成したリポジトリが獲得したスター数、8,500以上。 ひとつのリポジトリが獲得した最大のスター数、13,000以上。

この数字を叩き出したのが「1人のエンジニア」だと聞けば、多くの方は驚きの声をあげるでしょう。多くの人から支持されるOSSを作るのはもちろん簡単なことではなく、数千、数万というスターを獲得することは、ほとんど“偉業”ともいえる実績です。

この圧倒的な実績を生み出したのは、ドキュメンテーションコメントを簡単に書けるXcodeプラグインVVDocumenter-Xcodeや、画像を扱える軽量なSwiftライブラリKingfisherの作者である王巍(Wei Wang/ 1 @onevcatさん。王さんはLINE株式会社でオープンソースプロジェクトであるLINE SDK for iOS Swiftの開発にも携わっており、公私ともにOSSへのコントリビューションを続けています。

なぜ彼は、多くの人に支持されるリポジトリを生み出せるのでしょうか。そのストーリーの裏側には、コーディングを、そしてOSSを愛してやまない1人のエンジニアの素顔がありました。

デビュー作のリポジトリが、累計スター数8,500以上に

──王さんがGitHub上に最初にアップロードしたリポジトリは何でしたか?

 VVDocumenter-Xcodeというプラグインでした。これはXcode用のプラグインで、ソースコードを書いているときにスラッシュを3つ入力すると、ドキュメンテーションコメントを生成できるというものです。

2

▲VVDocumenter-Xcodeによるドキュメンテーションコメント生成

現在のXcodeにはデフォルトでドキュメンテーションコメント生成機能が搭載されていますが、かつてのXcodeにはこの機能がなくコメントを書くのが面倒でした。このプラグインがあれば、コメントを書くのがもっと楽になるだろうと考えたんです。

──デビュー作にもかかわらず、VVDocumenter-Xcodeは爆発的な人気を集めたそうですね。

 GitHub上にリポジトリを公開した後に、VVDocumenter-XcodeをiOS Dev Weeklyの週報に紹介してもらえたんです。それがきっかけとなって、すごい数のスターが付きました。最終的なスター数は8,500以上になっています。その後、Xcode本体にドキュメンテーションコメント機能が追加されたのでプラグインのサポートは終了しましたが、多くの人に使ってもらえるものを作れたのは本当に嬉しかったですね。

3

王巍さん:大学卒業後、中国のスタートアップに入社しキャリアをスタートさせる。面白法人カヤックでUnityチームのリーダーを務めた後、2014年より現職。ObjCCN groupの運営をリードするなど、オープンソースへのコミットメントは幅広い。

──8,500スター以上とは、鮮烈なデビューですね! 王さんはVVDocumenter-Xcodeの後にも、数多くのリポジトリを作成しています。どんなときにライブラリのアイデアを思いつくのですか?

 私は何かのライブラリを開発する際に「他のプログラミング言語やIDEなどには○○という便利な機能があるから、自分が普段使っているプログラミング言語やIDEでも同じ機能を使えないだろうか」というのが発想の起点になることが多いです。要するに、自分が使いたいものを作っているんです。

私が公開しているRainbowというライブラリもそうでした。Node.jsやRubyなどは、コンソールに標準出力やエラー出力を出す際、文字の色を簡単に変更できます。でも、Swiftではできなかったんです。そこで、Swiftでもコンソール出力に色をつけたいと考えたのが、開発のきっかけです。

4

▲Rainbowを使えば、このように色合い豊かなコンソール出力が実現できる。

──そうしたアイデアを思いつくということは、日常的にさまざまなプログラミング言語に触れているのでは?

 確かに、これまで多種多様なプログラミング言語に触れてきました。インターン時代はJavaScriptを書いていましたし、UnityでC#を書いていた時期もあります。iOS開発で用いられるCocoaPodsやfastlaneなどのツールではRubyが必要なので、Rubyも少しだけ書きます。それから、趣味でアプリを作るときには、サーバーサイドの言語はNode.jsを使うことが多いです。

──iOSエンジニアといっても、決してiOS関連のコードだけを書いているわけではないのですね。どんな方法で情報収集やインプットをしていますか?

 先ほども話したiOS Dev Weeklyで、質の高い記事を参考にすることが多いですね。それから、いま人気のリポジトリが確認できるGitHub Trendingもよく活用しています。Trendingに入っているリポジトリの情報が毎日メールで届くので、それをチェックするだけでも勉強になります。良さそうなリポジトリがあったら、「どうすれば同じような機能を実装できるだろうか」と考えることも多いですね。

自分が実現したい処理があるけれどどう書いたらいいかわからないときは、やはり他の人のコードを参考にするのが一番効率が良いです。世界中の優秀なプログラマーの方々が、誰もが閲覧できる場所にソースコードをアップしているわけですから。オープンソースというカルチャーがなければ、開発はたちゆかない時代だな、とよく思いますね。

大人気リポジトリKingfisherリファクタリングの裏側

──王さんの代表作といえるKingfisherは、スター数13,000を超えるリポジトリです。このライブラリのアイデアは、どうやって思いついたのですか?

 Kingfisherを開発し始めた当時はSwiftが登場したばかりの頃で、ライブラリがまだ充実していませんでした。ですから、Swiftを書いていると「こういうライブラリがあったらいいのになあ」と感じることが多かったんです。その「あったら嬉しいもの」のひとつが、画像を処理してくれるライブラリでした。

Objective-Cには、Web上から画像をダウンロードしてキャッシュするSDWebImageという有名なライブラリがあります。それと同等の機能を提供するライブラリを目指して、Kingfisherを作りました。Kingfisherはメモリキャッシュとディスクキャッシュの両方を扱えるようにし、画像をダウンロードするためのコードもシンプルに記述できるようにしました。

──実装において、大変だったことはありますか?

 初期の開発よりも、最近行ったKingfisherの大幅なリファクタリングがなかなか大変でした。

Kingfisherを作成した初期の頃は、私がSwiftにあまり詳しくなかったため、Objective-CのコードをそのままSwiftに翻訳したような実装をしていました。改めてそのコードを見ると、良くない書き方がたくさんあります。そこで、2018年9月からリファクタリングを始め、2018年12月8日に新しいバージョンをリリースしたんです。

5

▲2018年12月8日に「Reborn」と題したリリースが行われた。可読性や変更容易性を高めるための、大規模なリファクタリングが行われている。

ライブラリは定期的にメンテナンスをしなければ、コードのクオリティも徐々に悪くなってしまいますし、パフォーマンスも出なくなります。コントリビューターの方々の興味も薄れていってしまうでしょう。コードを良い状態に保ち続けるのは、プロジェクトを長生きさせる上でも重要なことだと思います。

──リファクタリングでは、どのような箇所を修正しましたか?

 例えば現在の実装では、メモリキャッシュのストレージを扱うMemoryStorageクラスと、ディスクキャッシュのストレージを扱うDiskStorageクラスがあります。でもかつては、両方のストレージを扱う処理を同一のクラスで賄っていました。

全ての処理がひとつのクラスに混在しているので、クラスが非常に肥大化していました。そこで、役割に応じた適切なクラス分割を行い、よりコードを修正しやすい設計にしたんです。修正する際の影響範囲も洗い出しやすくなるので、コントリビューターの方々もより作業がしやすくなると考えたんです。

もうひとつ、KingfisherをよりSwiftらしく書きなおした点として、コールバックの扱いを変更しました。Swiftのバージョン5では新しくResultという概念が導入されたので、Kingfisherでもその型を取り入れたんです。これにより、処理結果のハンドリングがより簡潔に書けるようになっています。

6

Kingfisherのwikiには上記の通り、「Result」に関する記述がある。

数多くのコントリビューターがリポジトリを進化させてくれる

──なぜKingfisherは、これほどの人気リポジトリになったのだと思いますか?

 理由はシンプルで、KingfisherがSwiftで画像を扱える最初期のライブラリだったからだと思います。Web上から画像をダウンロードする処理は、多くのアプリケーションで必要になります。その機能を実装する際にこのライブラリを使ってもらえるわけですから、必然的に利用者も多くなります。

それから実は、「私が中国人だから」という理由も大きかったと思うんです。中国は人口が多いので、その分エンジニアの人数も非常に多く、iOS開発者だけでも20~30万人くらいいるといわれています。その方々にスターを付けてもらえれば、数字も増えやすいです(笑)。VVDocumenter-Xcodeが支持されたたおかげで、続くKingfisherの公開時にも注目してもらえたんです。

7

──人気リポジトリになると、コントリビューターも増え、世界中からIssueやPull Requestが届くと思います。どのような基準で、取り込む・取り込まないを決めていくのでしょうか?

 「その機能を取り込んだ場合、今後のメンテナンスコストがどれほど増えるか」と「その機能によってどれだけ多くの方々が便利になるか」のバランスを考えた上で、メリットの方が大きければ取り込むことが多いです。

機能を追加するということは、便利になる反面、機能のメンテナンスコストが発生し続けるということでもあります。例えば、20人のうち1人くらいしか使わないような機能であれば、本当に入れるべきかどうかは慎重に考えなければならないです。機能が増えるとライブラリのファイルサイズも大きくなりますから、パフォーマンスにも影響が出るかもしれません。

──そのチェックを通過して取り込まれたPull Requestのなかで、印象に残っているものはありますか?

 作者にとってほとんどのPull Requestは嬉しいものなんですが、特に思い出に残っているものは2つあります。

1つ目は、KingfisherでGIFアニメーションを扱えるようにしてくれたPull Requestです。かつてのKingfisherは、JPEGやPNGなど静的な画像ファイルだけを扱っていました。より厳密にいうと、UIImageViewというクラスでGIF形式の画像をサポートしてはいたものの、全ての画像をメモリにロードしてから再生する仕組みになっていたため、パフォーマンスが悪かったんです。

その課題を解決するため、このPull Requestでは新たにAnimatedImageViewというクラスを追加してもらいました。このクラスはフレームごとにGIFの画像データを読み込んで再生するため、パフォーマンスが非常に優れています。大変な修正だったと思うんですが、Kingfisherをより良いものにするためにコントリビューションしてもらえたことが本当に嬉しかったです。

8

▲王さんの印象に残るPull Request「AnimatedImageView」の冒頭。

2つ目はPull Requestではないんですが、Kingfisherのプラグインを作ってもらえたことです。Kingfisherでは画像をRAWデータの状態で保存します。そして、ImageProcessorというクラスが、RAWデータを人間が閲覧できる形式の画像データに変換しています。

変換可能な画像形式として、デフォルトではJPEG、PNG、GIFをサポートしていますが、開発者がプラグインを作って拡張すれば、他の画像形式にも変換できるようになっているんです。そこで、ある開発者の方がWebPを扱うためのKingfisherWebPというプラグインを作ってくれました。これを知ったときも嬉しかったですね。Kingfisherが、多くの人に愛してもらえるライブラリになったことを感じました。

Don't be shy!

──王さんは現在、LINE株式会社でもオープンソースプロジェクトであるLINE SDKの開発に携わっています。LINEがOSSに注力していることはLINE DEVELOPER DAY 2018でも大きなトピックとして取り上げられていました。企業がこういった取り組みに力を入れるのは珍しいですよね。

 確かに日本だと珍しいかもしれません。でも、私の母国である中国では、大手企業がOSSを開発・運営するケースがよくあるんです。例えばアリババは数多くのリポジトリを公開しています。それに、昇進や転職の際のエンジニアの評価基準として「OSSにどれだけ貢献しているか」が重視されるケースもあります。

──では、LINEがOSSに注力する方針を打ち出したことにも、王さんは非常に共感を覚えたのでは?

 そうですね。LINEの良い文化であり、意義のあることだと思いました。だからこそ、LINEでオープンソースのプロジェクトに携われることは、大きなやりがいに繋がっています。

社外の人にもソースコードが公開されることは、「良いコードを書きたい」というモチベーションにもなります。オープンソースにするということは処理内容をすべて公開するということなので、LINEが提供しているサービス自体の信頼性も上がると考えています。

9

──この流れが、多くの日本企業にも広がっていくといいですね。OSSに携わるエンジニアには、どんなことを大切にしてほしいですか?

 エンジニアの方々に伝えたいことはシンプルで「Don't be shy!」です。ぜひ、恥ずかしがらずに色々なことに挑戦してください。OSSのコードをたくさん読んで、疑問に思ったことや修正したいものがあれば、積極的にIssueやPull Requestを起票すればいいと思います。

「作者は何かの考えがあってこういう書き方にしているのかも」と恐れる必要はありません。気軽に質問をしてください。何か見落としがあって、悪いコードを書いた可能性もありますから。ライブラリの作者からすると、どんな問い合わせでも本当にありがたいんです。Issueを起票して質問をするだけでも、立派なコントリビューションです。

──王さんがそういってくれると、勇気が湧いてきます! 最後に伺いたいのですが、なぜ王さんはプログラミングへの情熱を継続できるのでしょうか?

 プログラミングが趣味だからですね。純粋にコードを書くのが大好きなんです。もちろん、家でゴロゴロするのも楽しいんですけど、何かを作っているときはもっと楽しい。だからコードを書きます。それだけの理由なんです。

それに、良いプログラムを書けるようになるには、たくさんの練習が大事です。だからなるべく多くの時間を、コードを読んだり書いたりすることに使いたい。何回も練習をすることで「この場合はこう書いたらいいんだ」とわかってきますし、他のエンジニアが書いたコードから多くのことを学ぶことで、技術的な幅も広がっていくと考えています。

取材・執筆:中薗昴

若手ハイキャリアのスカウト転職