はじめに
メーカーのコーポレート部門でテックリードをしているmongolyyです。
書店に立ち寄った時に気になって買った本を読みました。
気づきを書いていきます。
気づき
認知負荷を低くするための考え方
本書で、人間の思考モードが二つあるということを知りました。
何も意識しないと一つ目の思考モード（すぐに答えに結び付けようとしてしまう）が優先され、誤解したり、理解できないコードだと感じてしまうという話がすごく共感できました。
つまりぱっと見の「ん？」「あれ？」をいかに起こさないかというのが重要だと理解できました。
そう考えると、コメントには「判断の結果」よりも、「なぜそう判断したか」を書くというのは納得できる考え方だと思いました。
また、「7つ以上のことを入れない」というのも、ワーキングメモリーに基づき「ん？」「あれ？」を生まないためのキーワードだなと感じました。
今までは「同じようなif文であれば別にいいかな」と思っていましたが、安直にそうせず、高レベル、低レベルの実装に分割できないか考えるようにしたいと思います。
メソッドの設計について、「メソッド名を隠して、クラス名やシグニチャだけでそのメソッドが何をやっているかわかるか」という問いで、いい設計か判断するというのも興味深かったです。
メソッド名だけでなく、シグニチャに拘っていきたいし、シグニチャが微妙である場合はそのクラスであるべきか疑った方がいい兆候として考えていこうと思います。
コミットメッセージでさえも、チーム開発を意識する！
コミットメッセージやコードレビューでは、「書く、指摘する」ということではなく、「読み手とコミュニケーションする」というのが大事だということが理解できました。
コードレビューはまだしも、コミットメッセージもコミュニケーションを意識するというのは考えたことがなかったですが、確かにできるプログラマーはコミットメッセージも手を抜かないし、わかりやすいなと納得しました。
開発は一人だけでやっているわけではないので、いろんなポイントで人に伝えようとする、人の意見を引き出そうとするふるまいがいいプロダクトを作るんだなと思いました。
コミュニケーションを通して、暗黙知から形式知を生み出したり、複数の案を比較検討することでより良い解決策を見出すことができるんだもんな、と再認識できました。
「チーム開発の営みはどこまでもできる！それをきわめて、より良い設計を見出すべし」と学びになりました
おわりに
コードを書く技術だけでなく、ソフトウェア開発、チーム開発における哲学を考えさせられる一冊でした。
個人的には7~9章が激アツでした。
また、コードレビューに関する以下の観点もすごくいいなと思いました。
Things I think about during a code review:
— Cory House (@housecor) 2019年4月10日
Is the intent clear?
Is there needless duplication?
Could existing code have solved this?
Is this an atomic commit?
Could this be simpler?
Are there logic issues?
Does this follow our standards?
Are the tests comprehensive and clear?
本書に書いてあったことの受け売りですが、今後は「自分はこれのメンテナンスを問題なく行えるか？」という観点でレビューしていこうと思います。
