try!Swiftのセッションまとめシリーズです。Krzysztof Siejkowskiさんの「A Neatly Typed Message」についての記事になります。

資料

内容

コードの可読性についての話
コードを書く上で問題になっているもの（研究結果より）
- コードの背景にある根拠を理解すること
- これに時間の4割が使われる
  - とにかく読む / デバッガやprintを使う / 書いた人に説明を求める etc…
- その他にもチームメンバーからコードに関することに答えるのに時間が費やされた
聞く側、聞かれる側両方にいたことがある自分にとってこの研究はその通りだと思った
以上のことから可読性は最大の貢献要素として捉えることができる

email文字列をユーザ名とドメインに分けたい
内部では文字列を@マーク前後で分けている
外から見るとどうやってemailを分割するのかという疑問が湧く
Level 1-1：コメント
- まだ完全ではない
- 開発者次第のところがある
- 自然言語なので誤解、ニュアンスの違いが発生する
Level 1-2：シンボル
- シンボルが何を意味するのかを考えなければならない
- 一度しか使わない型を導入するメリットはあまりない
- 標準ライブラリの方は認識コストが低い
- なぜ返り値の型がoptionalなのかはこれではわからない
Level 1-3：ラッパー
- 有効、無効を値として取るenumを作成
- 可読性は上がったのかどうかは微妙
- 初期コストは高くなる
Level 1-4：コンセプト
- 1つの値を2つの値に変換するというプロセスを表現
- プロトコル依存
- Benjamin Enczのコードはぜひ見ていただきたい
- コメントには使用する値を全て含める
- コードの可読性は高まったのか→どちらとも言えない
- 複雑さを正当化していやしないだろうか
- 2つめの世界に行く必要

weakのデリゲートを保持
Level2-1：initializer injection
- 外から直接delegateをいじれないようになった
- 通知するオブジェクトの実装を読まなければいけない
Level2-2：weak closure
- デリゲートがどんな状態なのかわからない
- initのクロージャがどうなっているかわからない
Level2-3：weak function
- 何を渡しているかを明確化した
- 根拠ははっきり示されていない
Level2-4：weak wrapper
- World1でもやった方法なのでラッパーでうまくいくことはない
そもそもdelegateが介在して可読性が向上するのか？
共通背景を活用していない
可読性をあげるには視野を広げる必要がある
究極の答えを出してくれるものはない
複雑制、慣習、モデリングコスト、他の要因のバランスを取るには？
“神モード"とも言うべき共感モードを使う
- 読み手が何を考えているかを想像する
- 自分が書いたコードが妥当なトレードオフを有しているかは他人の立場に立って考える
- 落とし所をどこに見つけるか
- 読み手なしに可読性はあり得ない