「ベタープログラマ」を読んだ

原著が出てたときから割と気になっていた「ベタープログラマ」を読んだ。

全体的な感想

第Ⅰ部はコードスタイルや、不要なコードの存在、テストコードを書く話など、非常に実践的な内容が多かった。

第Ⅱ部は割と考え方というか、思想的な話になっていって、第Ⅰ部をきちんと読んで危機感を持って行動を変えられる人であれば自然とそこに到達するのでは？と思った。

まずは第Ⅰ部をしっかり読んで、自分の置かれた環境との差異や、これから行動することを書き出す、みたいな読み方をすると良い。

第Ⅲ部以降は、もう完全に生き方というか、エンジニアとしての振るまいや、哲学の話になってくるので、一気に通読する、というより少し間を置いて拾い読みしながら読み進めて行くと良いかも。

流し読みしても全然役に立たないタイプの内容なので、読書メモは必ず書いた方がいいと思うし、書かれていることが万人にとって正解、といった類いのものでもないので、その辺はあまり感化されすぎず、「考えるきっかけ」くらいに捉えた方がいい。

第Ⅰ部「you.write(code)」について

冒頭にも書いた通り、第Ⅰ部は実践的な内容が多い。

中でも冒頭の4つの章はお勧め。

2章　見かけのよい状態を維持する
3章　少ないコードを書く
4章　取り除くことでコードを改善する
5章　コードベースの過去の幽霊

2章はコードスタイルの話、ここは1つ1つについて根拠が示されているので、分かりやすい。また、コードスタイルが趣味の話ではなく、コミュニケーションの話であることが明示されていて良い。コードは書く以上に読むもの。

最近はどの言語でもフォーマッタが用意されているので、とにかくフォーマッタを通して一貫性を保つことが良いプラクティスとして広まっているので、どんどん使っていきましょう。個人個人で悩むところではないですね。

3章と、4章はなかなか自然とその考えに至るのは難しい内容、特に3章は分かりづらい、冗長なコードを書いてしまう話なのだけど、実際のコードでは単独のコードだけを見ても分かりづらい話だし、たいていは将来の機能追加に向けた保守性の低下という観点なので、なかなか本質的に理解するのが難しいところ。本の中で言及されているコード例は、かなり分かりやすい事例なので、実際のコードを書くときに、果たしてどこまで意識できるか？というのは難しいかもしれない。

誰も分かりづらく、余計なコードを書こうと思って書く訳では無いので、そこには必ず認知の差が有るわけで、その差をどうやって埋めるか？という話までは当然書かれていないので、そこから先はもう教育の話となってくる。

これは悪いコード例と、良いコード例を比較し続けるしかないし、ひょっとしたらIDEがもっと賢くなって等価でもっとシンプルなコードにリファクタリングしてくれる方に期待した方がいいのかもしれない。

4章はコードを削除する話。ソフトウェアの機能追加は新しい価値を提供するために行われるため、既存の機能を消すということはなかなか無いけど、それはコードの保守性を低下させ、迅速な機能のリリースを妨げる存在であるため、削除した方が良いということが書かれてる。

5章はイデオムについて触れられている。どんな言語やフレームワークでもイデオムは有って、それを身につけないと「らしくない」書き方となってしまい、保守性を低下させる。

おわりに

誰だって悪いコードをわざわざ書きたい人はいなくて、そこには認知の差異や、組織としての方針（投資の優先順位）が有るだけなので、この本に書かれているような悪い事例が目の前に有ったからといって、一方的に批判するのは良くないし、なぜそんな状況が（無知以外の理由で）存在するのか？と考えることが大事なんじゃなかと思いました。

とはいえ、2章から5章あたりは「言われないと分からない」レベルの話ばかりなので、まずはこの辺をしっかり読むことをお勧めします。

後半はどんどん抽象的な話になってきますが、考えるきっかけとしては良い本だと思います。

思ったよりコード例が出てくる量が少なくて、「あれ？」と思ったけど、原著のタイトルである「Becoming a Better Programmer」を考えると、割とそうね、という感じでした。