Rachel Bobbins
Stitch FixでiOSのリードエンジニアをしています。以前はPivotal Labsで働いていました。ユーザ・開発者の両方にとって素晴らしい経験を作り出すことを大切にしています。
D.A.ノーマン著「誰のためのデザイン？（原題: \"The Design of Everyday Things\"）」はデザイン哲学に焦点をあてたデザインの書です。そこで紹介されている多くの原則はSwiftのような物理的ではない言語についても当てはまります。このような原則を通して、読みやすく効果的なコードの書き方を探ります。
6年前に読んだ本を読み返しました。
心理学や認知科学から考えて製品を設計するというものです。
この本で紹介されている内容とコードの関係を考えてしまいます。どうやってコードの設計にこれを適用するか。
ひょっとすると危ない未知を歩んでいる、関係の名利用粋なのではないか。でももっと考えると素晴らしい考えなのではないか、さまざまな概念を違う分野に適用できるのではないか。
Swiftエンジニアとしてユーザーフレンドリーなアプリを設計する。デザイン思考、クリエイティブにどのようにコードを書くか、クリーンにテスタブルにするか。
ユーザーとは何なのか？この本は人気でUserFocuedDesignと言われていますが、ユーザーを特定する必要があります。そしてユーザー中心デザイン、そして最後にチャレンジについてお話します。
ユーザー
AppStoreからダウンロードする人、Enterpriseなら、実際には首になった人かもしれません。このプレゼンでは、そういったひとは総定義しません。同時に、コードを扱う人間、同僚などです。将来のチームメイトでもあります。Storeからダウンロードしている他にもコードベースをやり取りするひともユーザーと考えます。
そうすると全く違う目標が有ります。
心理学のレッスンを紹介します。プログラミングのレッスンと似ています。
目標はこのような画面を作ることです。Autolayoutを使わずにやってみます。ローカリゼーションもしてみたいです。
どうやってこのスクリーンを作成しますか？
非常に短いコードですね。
なにかおかしいようです。確認します。
Warningが出ています。新しい目標を決めてやっていきましょう
これをfalseにする必要があります。
7つの行動段階を経ました。
実際にはそごく早く、潜在意識の中でやってしまいます。デベロッパは今まで何千回と、気づかずやっていたわけです。
できるだけ将来のデベロッパに対してこれらが楽になるようにしたいわけです。
7つのステージに対応する7つの原則です
相互排他ではなくてお互いに関係しています。バラバラに見るのではなくお互いに相互作用していることを感じていただきたいと思います。
本では、これを物理的なもの、ドア、スイッチなどを例にしていますが、わたしたちはiOSデバイスになると思います。
これは明度を表示するものでどのようなアクションをするかすぐに分かりますね。
どうしたら何が出来るか発見できる。Discovarabilityですね。
コードの場合は
どんな機能、コードベースのプロパティがあるかをデベロッパが発見しやすくする。
Publicなどで見つけるべきもの、見つけないものを示す。テストで振る舞いや期待値などを見ていくことを可能にする。深く読み込んでプロパティを探す、自動補完しやすい名前をつける。
DataSoruceは30以上のメソッドを持つのにTableViewを名前に持つものは2つしかない、これはわかりにくい。見つけにくい。
コメントやドキュメンテーションも良い。ワークアラウンドをStackOverflowにリンクしておくとか。コードに直接繋がっていないが重要。
言語設定を変えてみるとアラートが出てきます。間違ってiPhoneを日本語にしないことは大事。
コードベースでなるべく多くのフィードバックを返すこと。将来のひとにタイムマシンで間違っていると言いに行けないので自動化されたフィードバックが重要。コンパイルエラーやWarningなどが最も有用。Redフラグが立てばおかしいことがすぐに分かる。
テストも重要。失敗したら修正が必要なことを伝えられる。ランタイムクラッシュはどんな段階でステップで起きたのか分からないので良いフィードバックではない。特定のステップを通らないとフィードバックが発生しないという点でもよくない。
バグレポートやAppStoreレビューではその場でフィードバックを取得できません。
概念モデル
スマホは当時そんなに使われていませんでしたが、新しいスマホが出たと行ったら、なんだそれといったかもしれません。
Jobsは、人々が知っているモノをベースにした。電話、iPod、インターネット通信デバイス。これが３つで１つだと繰り返した。
人々が既に理解できる言葉で伝えた。デベロッパはコードを論理的にしか考えないようになりがち
概念モデルは楽観、悲観、過去の経験、、様々な要因で影響を受ける。正しい概念モデルがわかりやすくなるように情報提供をすべき。
先の例では、AutoLayoutの制約は一つ作ればうまく動くと思っていたがその概念モデルは間違っていたということです。
Affordances
ドンノーマンの本でも強調されましたが、2013年の改訂版ではあまり強調されていませんでした。物理的オブジェクトよりはAffordanceは少なめだが、重要だと思う。
Signifiers
改訂でさらに強調されたのはSignifiers。
値を入れなくても操作できることが分かる。
Swiftが良いのはいろいろなSignifierが入っている
データ構造：enum や struct など。enumならだいたい同じで種類があるとか、structならコピーしても問題ないとか、classなら参照が重要であるとか。コード一行一行、何らかのシグナルをデベロッパに送ることになります。
Mapping
コントロールとアクションで時間的関係性を示す
次は右側の矢印、これは西洋文化的な要素です。レイアウトではマッピングが何を表すかを意識する必要がある。
制約
ハサミの持ち方使い方は1種類。
型システムは最高の制約。
型システムと離れたことをするとコンパイルエラーが出る。Objective-Cであったミスがなくなる。
まとめ
デザインに興味を持って頂ければ幸いです。
デザイン思考を導入することでクリエイティブに出来るかもしれません。
みなさんは何に興味があるでしょうか、なんでも、情熱をエンジニアリングに反映できると思います。
コーディング規約を作る時のコンセプトとして良いな。このセッションを参考に見直してみよう。 #tryswiftconf
— Motoki Narita (@mo_to_44) 2016年3月3日
ユーザだけでなく、developer に対するデザインのお話。すごく良かった！ #tryswiftconf
— ezura (@eduraaa) 2016年3月3日
わかる。Swiftに限らずReadmeの次はフォルダ構成を見ます。#tryswiftconf
— ohkawa (@ohkawa_m) 2016年3月3日
1年前の自分のコード読んだ時に、Objective-C→🤔 Swift→😄となるので、Swiftは Signifiers を伝えやすい言語仕様だなと感じる #tryswiftconf
— ほんとは超いそがし松 (@himara2) 2016年3月3日
Objective-Cを書くときもSwift(@objcあり)でデザインしてから書き直したほうが楽に感じる。 #tryswiftconf (個人の意見です)
— nori (@nolili) 2016年3月3日
「読みやすく効果的なコードの書き方とは Swiftにおける”誰のためのデザイン？” #tryswiftconf」をトゥギャりました。 https://t.co/Xd5crzBAfB
— トゥギャッター開発まとめ (@tg__dev) 2016年3月3日
気に入った記事は はてなブックマーク
はてなブックマークアプリiOS開発チームから来ました！ はてなブックマークにはSwift特集があります！ 良い記事を見逃さないように、ご利用ください！ http://b.hatena.ne.jp/hotentry/it/Swift
そして良いまとめ記事があったらはてなブックマークでブックマークしましょう！ try! Swift の記事で盛り上がると嬉しいです！
