とりあえずやってみればいいじゃん

読者です 読者をやめる 読者になる 読者になる

とりあえずやってみればいいじゃん

エンジニア関連のことについてつらつら書くブログ

3/3 きちんと型付けされたメッセージ #tryswiftconf

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

資料

内容

概要、背景

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

「複雑性」について

  • コードを書くことは複雑性をコントロールすること
  • 複雑性には内在的なものと偶発的なものがある
    • 前者は改善の余地はない
    • 後者は可読性の高いコードを書くことによってコントロールできる

可読性の高いコードを書くために

World 1: API Design

  • email文字列をユーザ名とドメインに分けたい
  • 内部では文字列を@マーク前後で分けている
  • 外から見るとどうやってemailを分割するのかという疑問が湧く

  • Level 1-1:コメント

    • まだ完全ではない
    • 開発者次第のところがある
    • 自然言語なので誤解、ニュアンスの違いが発生する
  • Level 1-2:シンボル

    • シンボルが何を意味するのかを考えなければならない
    • 一度しか使わない型を導入するメリットはあまりない
    • 標準ライブラリの方は認識コストが低い
    • なぜ返り値の型がoptionalなのかはこれではわからない
  • Level 1-3:ラッパー

    • 有効、無効を値として取るenumを作成
    • 可読性は上がったのかどうかは微妙
    • 初期コストは高くなる
  • Level 1-4:コンセプト

    • 1つの値を2つの値に変換するというプロセスを表現
    • プロトコル依存
    • Benjamin Enczのコードはぜひ見ていただきたい
    • コメントには使用する値を全て含める
    • コードの可読性は高まったのか→どちらとも言えない
    • 複雑さを正当化していやしないだろうか
    • 2つめの世界に行く必要

World2:delegate

  • weakのデリゲートを保持

  • Level2-1:initializer injection

    • 外から直接delegateをいじれないようになった
    • 通知するオブジェクトの実装を読まなければいけない
  • Level2-2:weak closure

    • デリゲートがどんな状態なのかわからない
    • initのクロージャがどうなっているかわからない
  • Level2-3:weak function

    • 何を渡しているかを明確化した
    • 根拠ははっきり示されていない
  • Level2-4:weak wrapper

    • World1でもやった方法なのでラッパーでうまくいくことはない
  • そもそもdelegateが介在して可読性が向上するのか?

  • 共通背景を活用していない
  • 可読性をあげるには視野を広げる必要がある
  • 究極の答えを出してくれるものはない
  • 複雑制、慣習、モデリングコスト、他の要因のバランスを取るには?
  • “神モード"とも言うべき共感モードを使う
    • 読み手が何を考えているかを想像する
    • 自分が書いたコードが妥当なトレードオフを有しているかは他人の立場に立って考える
    • 落とし所をどこに見つけるか
    • 読み手なしに可読性はあり得ない

総評

  • 可読性ゲームの必勝法
    • 自分のコミュニティを知ること(メンバースキル等)
    • 人の立場に立って考える
    • ただ一つの正しいものは存在しない

その他このトークに関する情報源

togetter

A Neatly Typed Message #tryswiftconf - Togetterまとめ