では素晴らしい提案をしよう。お前もライブラリを作らないか？
「〇〇、なぜお前が至高の領域に踏み入れないのか教えてやろう」
「経験不足だからだ、視野が狭いからだ、品質への意識が低いからだ」「ライブラリを作ろう、〇〇」
「そうすればプロダクションコードと独立したフィールドで経験を積める、強くなれる」「そして、俺とどこまでも高め合おう」
「その資格がお前にはある」
閑話休題
はじめに
本業でiOSアプリエンジニア、趣味でmacOSアプリ開発をしているKyomeと申します。
業務でも個人開発でも必要性に迫られてライブラリの開発をしてきました。
そこで最近、一歩踏み込んだ強いエンジニアになる近道として「ライブラリ開発」が最適なんじゃないかと思い至ったので、その魅力をざっくり紹介したいと思います。
1. プロダクションコードと独立した小さいスコープでの判断経験を積める
プロダクションコードは巨大かつ複雑であったり、特定のアーキテクチャ特性による制約があったりすると思います。そうすると自由かつ柔軟な意思決定がしづらいことも多いでしょう。しかし、ライブラリであれば特定のスコープに絞られており、プロダクションコードとも分離されているため自由度が高く着手しやすいです。
- 技術選定: 言語バージョン、フレームワーク、DI手段、CI方針、ドキュメント提供方法
- 機能追加: 機能の必要性、提供方法（インターフェース）、実装手段
- 破壊的変更: 後方互換性、マイグレーションコスト
上記のような項目で考えうる選択肢のトレードオフ分析を行うことで、判断経験を養うことができます。
ついでに、これらの判断をArchitectural Decision Record（ADR）形式[1]で行うのがおすすめです。
2. 責務の分離と境界面設計への理解が深まる
アプリケーション開発ではしばしば機能同士が密結合しているコードが生まれてしまいがちです。
明らかに良くなさそうだと気づいていても、動いているから目を瞑って良しと判断することもあるでしょう。しかし、ライブラリ開発では違います。「境界」を意識せざるを得ません。
- 何をするのか（責務）
- 何をしないのか（管轄外）
- どう使われるのか（インターフェース）
- 何を公開し何を隠蔽するのか（カプセル化）
これらを明確にする必要があります。これを考える過程で設計スキルが自然と磨かれます。
また、設計をどのように具体的な実装に落とし込むか考えていく上で言語スキルも向上します。
3. 質の高いコードへの意識が高まる
ライブラリは不特定多数の開発者やチームで利用されることを前提とするため、第三者の視点で考える訓練になります。この前提により、自然と以下の品質項目への意識が芽生えます。
- 使用性：一般的な仕様に準拠しているか、間違った使い方が誘発されないか
- 可読性：機能性が理解し易い命名か、コメントやドキュメントは十分か
- 拡張性：カスタマイズが可能か、組み合わせ易いか
- 保守性：将来の変更に強いか、デバッグし易いか、テストし易いか
- 信頼性：正しく動作することが保証されているか、クラッシュやメモリリークはないか
「使う人の立場」で考える力が養われるだけでなく、プロフェッショナルなプロダクト開発に必要な素養を鍛えられます。
4. テストコードを書き始める単位として最適
3の保守性や信頼性から派生した話になりますが、ライブラリはテストコード実装入門として非常に優秀です。「テストを書いた方がいいのは分かっているけれど、どこから始めればいいか分からない」というような初心者にこそおすすめです。
ライブラリはスコープが狭く機能要件がはっきりしているため、「ある入力に対して期待する出力がなされる」のようなテストケースが考え易いです。また、テストを書こうとすると自然とテスタブルな設計を目指すようになり、設計の変更も行い易いため、試行錯誤しながら実装容易性と試験容易性のバランスを取る訓練ができます。好みもあるとは思いますが、テスト駆動開発（TDD）[2]の練習にも活用できると思います。
5. 複数プラットフォーム・複数バージョン対応の知識が増す
一般にライブラリは複数の環境で動作することが期待されます。
例えば、Swift製ライブラリなら、
- iOS、iPadOS、macOS、watchOS、visionOS、tvOSのどのプラットフォーム上で動くか？
- 最低サポートOSバージョンをどうするか？
- ビルドに用いられるXcode、Swift等SDKのバージョンは何か？
などの考慮すべき項目があります。
これらの対応を通して、複数プラットフォーム対応のための条件付きコンパイル・型解決・プラットフォーム固有機能の出し分け方法が学べますし、言語バージョンによる記法使い分け・SDKバージョンによるAPIの差分吸収などの実装知識が身に付きます。
まずは小さく始めよう
プロダクト内でよく使っているボタンやモーダルなどの再利用できそうなコンポーネント、文字列や数値、色、画像などの変換を行っている便利関数群、頻出してるボイラーテンプレートやマクロなどをライブラリとして切り出してみましょう。用途が定まっているものから着手する方がインターフェースについても利用者についても想像し易いです。
最初からオープンソースにすることに抵抗があるなら、Privateで始めても良いと思います。
ただし、想定する利用者を自分だけに絞らず不特定多数とした方が学びが多いでしょう。
おわりに
ライブラリ開発はエンジニアとしての視野を広げるのに役立つ、プロダクト開発だけではなかなか得られない学びが凝縮されています。業務でも趣味でもぜひ作ってみてください。きっと新しい発見があるはずです。
Happy Coding! 🚀
Discussion