プロダクトコードからライブラリの境界を見つける

Embed

Start on current slide

Slide 1

Slide 1 text

プロダクトコードからライブラリの境界を見つける「ほかでも使えそう」を、公開できるSwift Packageへ再設計するまで elmetal Cybozu, Inc. iOSDC Japan 2026 2026-09-12 #iosdc #c 1

Slide 2

Slide 2 text

About me @el̲metal̲ iOS App Developer 複数チームの技術支援 #iosdc #c 2 競馬対戦ゲーム育児

Slide 3

Slide 3 text

サイボウズについて #iosdc #c 3

Slide 4

Slide 4 text

チームワークあふれる社会を創る #iosdc #c #チームワークあふれる社会を創る 4

Slide 5

Slide 5 text

サイボウズについて iOSアプリ kintone サイボウズ O ce Garoon サイボウズでは複数のプロダクトを開発しています #iosdc #c ffi 5

Slide 6

Slide 6 text

Intro #iosdc #c

Slide 7

Slide 7 text

🤔このコード他でも使えそう #iosdc #c 7

Slide 8

Slide 8 text

🤔ライブラリにできないか #iosdc #c 8

Slide 9

Slide 9 text

サイボウズでは色々ライブラリ作りました WebUI LicenseList #iosdc #c 9 認証（社内ライブラリ）

Slide 10

Slide 10 text

新規アプリの基盤構築を 4~5ヶ月から約2週間へ短縮 #iosdc #c 10

Slide 11

Slide 11 text

サイボウズではどのようにライブラリに再設計しているかお話しします #iosdc #c 11

Slide 12

Slide 12 text

ライブラリの境界を見つける #iosdc #c 12

Slide 13

Slide 13 text

「ほかでも使えそう」から始める • ライブラリの境界：ライブラリ側の責任と利用側の責任の線引き • 共通部分っぽいところを見つけて抜き出してみる • 基盤でも共通アルゴリズムでも、なんでもok • 共通部分を大きく取ろうとしない • 大きく取れるところは取ろうとしなくても自然と大きく取れる #iosdc #c 13

Slide 14

Slide 14 text

ライブラリ、リポジトリの名前を決める • 責務を表現する命名を試みる • 一言で表現するくらいの粒度で • 細部はまだ決めない • APIを作る時に自然と境界が決まっていく • 被りがないかGitHubで検索しておく #iosdc #c 14

Slide 15

Slide 15 text

ライブラリのための再設計をする #iosdc #c

Slide 16

Slide 16 text

責務を分析して境界を再設計する • コードを別のモジュールに移動してpublicにするだけでは機能するライブラリにならない • 元のコードのスメルが残りがち • 移動元にあった固有の型に依存している • 特定の状態管理や画面構成が前提になっている • 内部実装の都合が反映された呼び出しになっている #iosdc #c 16

Slide 17

Slide 17 text

責務を分析して境界を再設計する • 疑似コードを使って複数の呼び出し案を考える • 実装が全くない状態で議論している • これらの選択肢を使って議論した上でADRに記録を残す #iosdc #c 17

Slide 18

Slide 18 text

責務を分析して境界を再設計する擬似コードの例 WebUIで検討していた時の疑似コード struct ContentView: View { var body: some View { WebViewReader { proxy in VStack { Button("Go back") { proxy.goBack() } WebView(url: URL(...)) } } } } #iosdc #c 18

Slide 19

Slide 19 text

ライブラリが担う責務を決める • プログラム上の責務 • ライブラリ側と利用者側の責任分解点の線引き • 先に全部決めるのは難しい • 存在を認識した上で決めるのを後でやる部分があっても良い #iosdc #c 19

Slide 20

Slide 20 text

プロダクト固有の依存を探し出すコードレベル • プロダクト独自の型 • ViewModel/Store 基盤暗黙の前提 • Navigation • デザインシステム • ログ・分析基盤 • 認証基盤 #iosdc #c 20 • 状態管理 • 画面構成

Slide 21

Slide 21 text

不要な依存を取り除く • そもそもライブラリ内に依存が必要かを考える • 積極的に利用側へ戻す • アプリごとに異なるものは利用側の責務とする • プロダクトの状態管理やデザインシステムとの接続はプロダクト側のAdapter が行う #iosdc #c 21

Slide 22

Slide 22 text

API設計 • 利用側の呼び出しを決める • API Documentを書く • この型が何か, メソッドの返り値が何か • この時点での実装可能性は考慮しない #iosdc #c 22

Slide 23

Slide 23 text

利用者のためのAPIを設計する • よくある用途が自然に書けるか • 高度な機能が段階的に使えるか • 内部の概念が漏洩していないか • 不正な組み合わせを型レベルで防げるか • Swift/SwiftUIの語彙に馴染んでいるか #iosdc #c 23

Slide 24

Slide 24 text

API設計Tips インターフェースに標準の型を使う • Swift標準ライブラリの型 • swift-lang・appleのライブラリの型 • 利用側に安定したインターフェースを提供できる #iosdc #c 24

Slide 25

Slide 25 text

API設計Tips ポリシーに従って決める • 何でも差し替え可能にしない • 提供するスコープを超えた拡張を考慮しない • 責務を超える要求を受け入れない #iosdc #c 25

Slide 26

Slide 26 text

呼び出し側から設計を精査する #iosdc #c

Slide 27

Slide 27 text

利用例で評価する • 抽象度が適切かどうか利用例を使って評価する • ドキュメント • テスト • サンプルアプリ • API設計の精度を高めていく • 線形のプロセスでなくてよい #iosdc #c

Slide 28

Slide 28 text

DocC • APIリファレンスはAPI設計時に書く • API Design Guidelines | swift.org • 設計がおかしいとドキュメントがうまく書けないので設計へのフィードバックになる • API以外にもライブラリのOverviewや基本概念、重要な制約について書く • Apple Developer Documentationのスタイルを踏襲する #iosdc #c 28

Slide 29

Slide 29 text

テスト • テストは最初の利用者 • コードレベルでAPIがおかしくないかフィードバックする • 公開APIの振る舞いを検証する • 入出力の契約 • エラーの挙動 • プラットフォーム差異 #iosdc #c 29

Slide 30

Slide 30 text

サンプルアプリ • サンプルアプリで統合する • 機能レベルだけでなくコードレベルでもうまく統合されているか確認する • アプリの利用例として機能させる • 実行可能なドキュメントとして扱う #iosdc #c 30

Slide 31

Slide 31 text

運用の設計 #iosdc #c

Slide 32

Slide 32 text

CIを動かす • ビルド・テスト • 複数プラットフォームでのビルド • サンプルアプリでのビルド • DocCのドキュメント生成とGitHub Pagesへのデプロイ #iosdc #c 32

Slide 33

Slide 33 text

公開後の運用ポイント • Issueはライブラリの責務範囲内か • どこまでをライブラリ側API追加で、どこまでを利用側で解決すると線引きするか • 破壊的変更を行う価値があるか • APIやサポート対象の廃止 • Deprecatedによる移行期間設定 • セマンティックバージョニング #iosdc #c 33

Slide 34

Slide 34 text

最近のサイボウズでは • 最近はいきなり別リポジトリを立てることが多い • 設計や責務のスコープを決めるのに慣れてきた • プロダクトコードの中で価値が出そうなところは大体やり切ってしまった • リポジトリ作成時点でOSSを射程に入れている • 社内ライブラリで開発開始しつつOSSにできそうか見てみる • 社内ライブラリのままでもOKのスタンス #iosdc #c 34

Slide 35

Slide 35 text

まとめ • 共通の責務を見つけ、抽象度を上げて、機能するライブラリに再設計する • APIドキュメント、テスト、サンプルアプリ、実アプリと段階の異なる利用者でAPI設計を精査する • 公開するとライブラリの境界をメンテナンスすることになる #iosdc #c 35

Slide 36

Slide 36 text

ありがとうございました #iosdc #c