脳に収まるコードの書き方~複雑さを避け持続可能にするための経験則とテクニック~ー FL#56
https://forkwell.connpass.com/event/320969
に参加してきたので、聴講メモ
「脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック」
タイトルが日本語だと「脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック」なってるが、
英文だと、「頭にはいるコード、ソフトウェアエンジニアの経験則」
というタイトル。
英文のほうのタイトルを意識したほうが本のイメージが湧くかもしれない。
経験則とは？
雑な言い方をすると、役にたつ認知バイアス。
必ずしもいいとか、裏づけがある訳ではない。
現代は、さまざまなソフトウェアアーキテクトが提訴されているが、
現実世界に一番多いのは、大きな泥団子。
理想と現実は大きく異なっていることが多い。
ギャップを埋めたくなる。
デザインパターン等も、デザインパターンを入れることが目的になってしまうと危ない。
日々エンジニアは経験則を溜めていっている。
経験則によって確立された解決策は、自動化されていく。
例えば、フレームワークのコマンドを打ったら、ある程度テンプレートのファイルをを用意してくれたりとか。
今回の本は、Mark（著者）の経験則をまとめたもの。
なので、人によっては合意できなかったり、絶対に良いというものでもない。
そこから、いろんな人がディスカッションとかできるといいかもですね。
目次
1部が加速がテーマ：スピードを持って最初に作るような場面
2部が持続性：既存のコードがある前提の話
1章 アートかサイエンスか
これまでソフトウェアをメタファーにしたものがあり
建築や庭があったが、どれも違った
プログラミングは基本的にアート
ソフトウェアエンジニアリングは、エンジニアリングの教育を受けてなくてもできるようになった。
パーソナルコンピューターによって、だれでもツールを手に入れられるようになった。
2章 チェックリスト
人間は、やらないといけないがたくさんあると、ミスが発生する。
ソフトウェア開発は多くのことが同時進行しており、とても難しい。
そこで、チェックリストが誕生。
チェックリストの良いところは、チェックリスト通りにやれば
スキルの向上なしに結果を改善させることができる。
が、形骸化しないようにどう扱うかを考えると良いかも。
3章 複雑さに対処する
人間は複雑なものを見ると、簡単な答えに飛びつこうとしてしまう。
規律を重視しすぎてしまうと、役に立つかどうかがおろそかになってしまう。
役に立つことだけを考えてしまうと、セキュリティや重要なことをおろそかにしてしまう。
機械は結論に飛びつきたい。
コードは書く回数よりも読む回数が多く、より読みやすくしなければならない。
機械が結論に飛びついたとしても、問題を起こさないようにしなければならない。
2週間後の自分でも分かるように。
4章 バーティカルスライス
チームに作る能力があるか、作ったものは役に立つか。
これを確かめるために縦にきればよい。
これで、一歩歩けるかどうかを確認する。
5章 カプセル化
オブジェクトの情報が外に漏れないようになるまでコードを改変してみると、この本を読んだ価値があるかも。
例えば、ゲッターセッターを一切用意しないとか。オブジェクトのプロパティを見て if 文を書かないとか。
6章 三角測量
良いコードというのは、三角測量のように、何度かトライしながら正解を探す
7章 分解
脳に収まるコードの要素は7つくらいまで。
8章 API設計
APIを使う側に、あまり考えさせない。
9章 チーム
Git でのコミュニケーション。
コミットログや、PRを小さくするなど
10 ~ 15章
10 ~ 15章は時間の関係で今回スキップ
おすすめの読み方
とりあえず全体を流し読み。
ここは合意できる、できないを考えてみると良いかも。
さらに、それをもとに実装してみる。
さらに、チームでやってみて、チームの経験則を考えてみる。
聴講しての感想
時間の都合で、講演部分だけ聞いてQ&Aの部分は聞けなかったが、講演部分だけの感想。
冒頭で説明もあったが、これを読んで何かをすぐに実践しようという内容というよりは、
先人はこういうところで困ったのでこうやって改善するようにした、
という体験談（まさに経験則）が詰まった本なのかもと思った。
もしかしたらソフトスキル的なものに近いのかもしれない。
一人で読むのも良いけど、輪読会とか読んだ感想会みたいなことをすると、より楽しかったりするのかもなと思った。（まだ読んでないけど）