Effective Swiftという本をリリースしてました

BOOTHで販売しています。サンプル版もあるのでそちらを事前に読んでいただければ幸いです。

https://swift.booth.pm/items/3755447

なぜ書いたか

これまでの書籍から

今までにRxSwift研究読本、VIPER研究読本、Combine Frameworkガイドブックなどを書いてきて、ありがたい感想を多くもらってきました。

他にたまにある感想として「Swiftのことをもっと知ってから読みたい/読み直したい」のようなものもありました。

おそらくこれは書籍のコードでは、Swiftの言語仕様を活かしたOSSの実践的なコードが多く、それについては説明をしていないからではないかと感じています。

これについては、研究読本シリーズはそのOSSを研究するために読む本だからまあそうだろなという感じなんですが、たまに「社内のチームで参考にした」という反応をいただくこともありました。

そういう感想をいただくたび、もしかしてSwiftの経験が浅い人にもわかりやすくかければもっとよかったかも、と思うようになりました。チームで参考にする際に、できるだけチーム内の知識の抜けの部分を補える書籍があっても良いのかもなと。

私の出している書籍の特徴は、

平日なんか知らんが同じタイミングで同じ本が続けて売れる
- どっかの会社のSlackで誰かが買おうと呼びかけてる？
なんか知らんがシリーズで買ってくれる人がいる
- 誰が書いたとかそういうこと関係なく知識を吸収しようとしてくれる人がいる
- これについては想像の範囲を超えていて考察しづらい

というのがあります。
私の書籍的に抜けているピースがあるなら、それを補うのはありかもな、と思った次第です。

仕事でSwiftを書いてきてわかることから

日頃Swiftを使うことも多い中で、レビューをしていたり過去のコードを見ているとSwift公式のAPI Guidelinesを読んで書かれたコードなのか、ということはすぐにわかります。メソッド名やプロトコル名とか変数名とか。

むかしはデザイナへ「HIGを読んでよ」ってのがあったと思いますが、現在ではプログラマーもAPI Guidelinesを読んでいません。誰かに対して、Web上の何かを読んでくれっていうのは結構面倒だし、英語だしということで、Effective Swiftでは命名に関してはチャート式にして読みやすくしたらどうかなという思いがありました。

それ以外でも、クロージャのキャプチャの話やメモリ管理などについても他人がどういう理解なのかっていうのはわからないこともあるので、Effective Swiftでは基礎として抑えるようにしています。

書く前に

本を書くのは結構時間と労力がかかるため、事前に本当に需要があるかを調べるためにランディングページを作って興味がある人にemailアドレスを登録してもらうようにしました。

https://effective-swift-book.web.app/

これはFirebase Hostingを使っていて1ページをつくっています。Firebase HostingではGitHub Actionsでmainにマージされたら、デプロイをするようになっています。PRを作るとステージング環境も用意してくれるので便利です。

そして興味がある人にはemailアドレスを登録してもらうようにし、Firestoreで永続化するようにしていました。
220人くらいに登録してもらっていましたが、
これ振り返るとFirestoreじゃなくてGoogle Formで良かったなとは思います。

登録してもらったemailアドレスにはベータ版ユーザとして参加してもらうため、GitHubリポジトリへの招待を送るようにしました。GitHubリポジトリはOrgnizationを作成しており、そのOrgnizationの1リポジトリとしてベータ版の本文をmarkdownとしていました。
振り返ると、Orgnizationを作るメリットはなかったですね。普通にリポジトリ作るだけで良かった。

数字としては、招待したうちの100人ほど（つまり全体の50%）がリポジトリへの招待を受け入れてくれ、ありがたいことにPRを出してくれたのが5〜7人くらい、Discuttionsでコメントをくれたのも5〜8人くらいだったはずです。

PRでtypoとかは直接修正したものを送ってくれるのが楽で、issuesを作らずDiscuttionsで気になったことを書いてもらうようにしてもらいました。Discuttionsはcloseがないのが気にはなりますね。

Effective Swiftにさらに追記もしくは2に書きたいこと

書こうと思ったが量が多すぎて大変なので書けなかった課題がいくつかあります

variableとimmutableの違い（Sendableにつながる）
fatalErrorやassertionFailerなど
型によってパラメータに制約を課すこと
良くないextensionの使い方

variableとimmutableの違いは、単に違いだけを理解することが必要ってのはもちろんあります。しかし、大体のレガシーコードはミュータブルなデータを持ち回すというバッドなやり方が一番の課題でしょう。おそらくこれはWebプログラミングでは表面化しづらい話で、HTTPリクエストに対してレスポンスを返すだけではライフサイクルが短く、mutableなデータを持ち回すことがバッドプラクティスであるということが気が付きづらいためiOSアプリでも同じ用にやってしまうからじゃないでしょうか。PC/モバイルアプリケーションのライフサイクルはアプリを使っている間（最長キルされるまで）なため、このミュータブルデータの持ち回しのバッドプラクティスが大きく響きます。なんとなく話が長くなってしまうので今回は見送りました。

fatalError/assertionFailerなどはケースバイケースなので例を出して説明するのが簡単じゃない気がして見送りました。チームでの決めの話も絡んでくるとは思います。

型によってパラメータに制約を課すことは、基礎ですが初歩ではないテクニックだと思います。これも例を出すのが難しいので今回は見送っていましたが、一日頑張ればなんとか例をひねり出せそうな気がします。

良くないextensionの使い方とは、extensionで追加されたメソッドがその型が知るべきではない別の型について知っていて、呼び出し時のコードだけを見た場合に動作が想像もできない場合のことです。

以上です。書籍に関しての要望などは下記ページで受け付けていますので、気になることがあったらそちらでお願いします！

https://github.com/CSBooks/EffectiveSwiftBookSamples/discussions