Thinking about programming as writing may give us insights into how to write more readable code

2. Hi, I’m Brian!
• M3のCTO＆社内IT・
QA・コンシューマ事
業の担当役員
• ハワイ生まれ日系４世
アメリカ人
• USAで21年→日本も
21年住んでいます
• ビールが大好き

3. Software’s Two Goals
1. Make a computer do something
useful
2. Be easily read (and modified) by
other humans (programmers)
…この２つのゴールを同時に達成するこ
とは大変！

4. 2 Goals → 2 Metaphors
“Construction” Metaphor
1. Make computers do
useful things
2. Be readable by
humans

5. 2 Goals → 2 Metaphors
“Construction” Metaphor “Writing” Metaphor
1. Make computers do
useful things
2. Be readable by
humans

6. Construction
 大掛かり… 多くの人が
協力して製造する
 理系
 定量的・化学的
 一旦作ったらずっと残
る
 「構築」「設計」
「アーキテクチャ」
 エンジニアリングの側
面にフォーカス
vs. Writing
 一人で書く
 文系
 定性的
 初回に作ったものがド
ラフト、読みやすくす
るために書き換える
 「レビュー」「コメン
ト」「バージョン」
 人へのコミュニケー
ションにフォーカス

7. Constructionは昔より簡単
HWの処理能力の向上・OSSの普及・リリースサ
イクルの高速化により（もちろん新しいチャレ
ンジいろいろあるが）製造が安易になった

8.  最善なソフトウェアは正しく動くだけでなく、
読みやすい・拡張しやすいが理想
 読みやすいプログラム書ける人は市場価値が
より高い
 CodingをWritingとしての側面に焦点当
てると、より分かりやすい良いコード
を書くインスピレーションになるかも
知れない
Writingメタファを考えるメリット

9. Writingメタファからの学び

10. 1. 読み手を考える
 例えば、書いているコードの読み手は誰？
 日本人？外国人？
 日本人のプログラマーなら：
 コメントは日本語であるべき
 specも日本語が良いでしょう
 ローマ字化が妥当な時もある（できれば、使
う場合にはローマ字化のルールも決めてね）
 作文の世界では読み手が第一

11. 2. 作文のBest Practiceを応用
 「Write Like You Talk」
 「Omit needless words… Make every word
tell」
 Morning Pages… Write every day
 順序も意識する（メソッド、変数など）
 ソースコードの目次・章・用語集等

12. 3. レビューは必須（と楽しい！）
 読み手からのフィードバックがなければ、どうして
「読みやすい」といえる？
 最初に書いたコードはドラフトにすぎない
 エンジニアリング面はテストコードで担保できるが、
読みやすさの担保はレビューで
 新聞社の編集者は記事書かず読むだけの役割。読み
手から見た統一性・読みやすさはそれだけ大事にし
ている
 そう思って僕は楽しんでコードレビューする

13. 参考
 Write Like You Talk – Paul Graham
 http://paulgraham.com/talk.html
 The Elements of Style – William Strunk Jr.
 http://www.crockford.com/wrrrld/style.html