というわけで大ボリュームのこの本、一週間かかってしまったけど読み終えたので書評です。
「Swift4本」というより「現場のための本」
タイトルから受ける印象としては「Swift初心者はSwiftという言語について理解できる・Swift中級者は言語のバージョンが3→4にアップデートされたけどどうなったのかキャッチアップできる本」みたいな感じだったのですが、中身はもっと広範囲に及ぶ、挑戦的な本でした。主にフォーカスされているのは開発工程全体。それゆえ、本の袖には👈こんなふうに書かれています。
なお、この本で言う「開発」の対象はiOSアプリです。そういう意味でも、「Swift4」というタイトルは少しミスリーディングかもしれませんね。
対象読者層
広い領域をカバーしているだけあって、多様な読者層を対象に書かれている本のように感じました。以下に挙げる属性の読者であれば、どこかしら刺さる本になっていると思います。
読者層1: エンジニアに限らず、アプリ開発のフローを掴みたい人
タイトルから想像していなかったけれど、本書が一番力を入れているのはここです。以下のような領域の知見が得られることでしょう。
- プロジェクト管理
メンバーとの協業について、工数見積のポイント - 企画・要件定義
「アプリを作ること」は手段の一つであり目的ではないという話や、類似アプリの分析について、ヒアリング、ロードマップの策定といった工程が概観できます。 - 運用
アプリのリリースだけでなく、リリース前のTestFlight配信、リリース後のアップデートやレビュー対応についても触れられています。
読者層2: iOS開発に入門したい人
以下のような知見が得られます。
- ライブラリ管理（CocoaPods, Carthage）の方法
- Xcodeの使い方、Tips
- Swiftの言語的特徴や記法
- AutoLayoutについて
- 総合演習
この演習だけでも、200ページ以上。それだけで一冊になるボリュームです。デバイスの機能（カメラ）を利用するアプリと、ネットワーク通信を行うアプリの2種類の作り方を丁寧に解説しています。
その際、コードだけでなく、企画や見積についても触れているのが独自の切り口ですね。ここで効いてくるのが、本の序盤100ページを費やした開発フローの章というわけです。
読者層3: 既にSwiftを活用して現場で活躍しているエンジニア
この本には、まさに「Swift4」本としての側面もあります。
- Swift4.0の改良点
- Swift4.1の改良点
これらの情報が、20ページほどの紙幅を費やして書かれています。入門者向けではないけれど、よく纏まっている章でした。
気になったところ
ところどころに、議論が分かれそうな記述や、もっと触れてほしかった！と物足りなくなる部分がありました。
画面遷移について
P67に以下のような記述があります。
目的を達成するまでに画面遷移が多い場合、時間と手間がかかります。基本的には目的が達成されるまでは短い方が良いとされています。もし、画面遷移の数が多い場合、複雑な手順は避けた方がいいです。単純な作業で簡単に画面を遷移できるように設計しましょう。
目的達成までの手数にだけ注目しすぎると、ファーストビューに要素を詰め込みすぎたUIが出来かねません。情報の粒度に気をつけて、適切な画面の分割を試みるほうがよいかなと思います。
モーダルについて
P71の記述です。
前の画面と次の画面には、基本的には関連性が低く、新しい画面として表示したい場合に用いられます
間違ってはいないのですが、安易なモーダルの使用に傾きかねない説明になっています。
AppleのHuman Interface Guidelineでは、モーダルについて「最小限の使用に留め」、そのコンテキストは「シンプルで短く、狭くフォーカスする」ことを求めています。この点については強調しておいたほうが良かったのではと思いました。
データモデル設計
P75のコードです。
class BookModel: NSObject {
var name: String = "" // 書籍名
var author: String = "" // 著者名
… データ構造をclassで作り、NSObjectを継承することは、現場の様々な条件下で確かに起こりうることではあります。
ただ、Swift初心者に向けた本であれば、このような単純なデータ構造の型としては、classよりstructにしておいたほうがよかったのではと感じました。SwiftのLanguage Guideにも以下のように書かれています。
As a general guideline, consider creating a structure when one or more of these conditions apply:
- The structure’s primary purpose is to encapsulate a few relatively simple data values.
- It is reasonable to expect that the encapsulated values will be copied rather than referenced when you assign or pass around an instance of that structure.
- Any properties stored by the structure are themselves value types, which would also be expected to be copied rather than referenced.
- The structure does not need to inherit properties or behavior from another existing type.
また、細かいところですがModelという命名も個人的には気になりました。 お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える — Qiita という記事を書いた身ですので。
開発支援ツールの導入
P92にて、プロジェクトの時短や作業工程統一化のために開発支援ツールが必要という文脈で紹介されているのが CocoaPods/Carthageなのですが、「開発支援ツール」と言われると、「GitHubを使った開発フローやCI/CDの話をするんじゃないのか…」と意外に思いました。モダンな開発環境では必須のものですので、言及があってもよかったなと思いました。
nilについて
P137に、以下のような記述があります。
let str: String = nilそもそも、nilは「存在しない」という意味があります。コンパイラは存在しないものを操作しようとすると、どうしていいかわかりません。そのため、コンパイラのレベルでnilの操作を行うとエラーが発生します。ここで押さえておくべきことは「nilに対する操作はクラッシュする」ということであり、…
「nilの操作」が何を指すのか不明ですが、少なくともクラッシュすることはありません。`Optional<String>` と `String` が型レベルで区別されていて…のような説明の切り口だと初心者向けには難しい、という判断かもしれませんが、少なくとも、ビルドエラーとランタイムエラーを区別して説明したほうがよいのではと感じました。
ちなみにnilを型として表現できることの嬉しさについては、以前にnull安全はいいぞ。だって、型安全はいいぞ。 — Qiitaという記事で書いたことがあります。
継承について
P238のコードです。
class BaseViewController: UIViewController { … }この “BaseViewController” を継承したクラスであれば、前の画面のタイトルが表示される箇所がすべて「戻る」になります。クラスを作る度に、この一行を追加するのは非常に面倒で、書き忘れてしまうのを防ぐためにも、継承を活用した方が便利です。…そして、UITableViewでは「セルの区切り線のマージンを全てなくす」デザイン仕様であれば、継承を使用した方が便利です。クラス内で共通化できるものは親クラスを作成して、それを継承する方がベストということです。ソースコードの削減も見込めます。
継承という仕組み自体の解説としては間違っていないのですが、BaseViewControllerという設計にはデメリットが多いという議論もされています。私もBaseViewControllerは使うべきではないと思っています。なぜなら、こういった処理の共通化のための継承は、例外的なサブクラスの存在を許さず、変更に極端に弱いコードになってしまいます。また責務が不明確なため、容易に肥大化の道を辿り手がつけられなくなります。
古くから「継承より委譲」という考え方があり、またSwiftでは継承よりもProtocol-Oriented Programmingの考え方が推奨されています。詳しくは公式のビデオをご参照ください。
Protocol-Oriented Programming in Swift — WWDC 2015 — Videos — Apple Developer
特にこのような教科書本においては、継承の適用範囲については慎重に記述したほうが良かったかもしれません。
テストについて
開発工程には、書いたコードの妥当性を検査するための、ユニットテストやUIテストというフェーズがあります。開発工程全体を概観する目的であれば、触れておいたほうが良い分野だったかなと思います。
とはいえ
発売以降の指摘に対して、著者さんとしても積極的なフォローアップをされているようです。今回気になった点も、きっと何らかの形で改善されるのではないでしょうか。
(20180530追記)やはりフォローアップしていただけるとのことです！ 素晴らしい！
まとめ
気になる記述は多少あるものの、ここまで広く開発工程領域をカバーしている本はなかなかありません。開発のイロハを学びたい読者にとって価値ある一冊であることは間違いないでしょう。
また、200ページある「総合演習」の章は、題材の選定も納得感が高く、iOS開発初学者のための良きサンプルとなっています。
これだけの内容を詰め込んで、価格は2980円。とても良心的な価格設定です。願わくば、この本がさらにヒットして増刷され、ブラッシュアップされた内容とともに、多くの読者の元に届きますように。
