「ルールズ・オブ・プログラミング より良いコードを書くための21のルール」を読んだ
すごく良かった。リーダブルコードや良いコード/悪いコードで学ぶ設計入門などの既存の書籍とはまた別の切り口が新鮮で、随所で自分の経験や知識と重なる部分があって参考になった。ゲームプログラミングで得られたプラクティスという謳い文句が変に間口を狭くしていないか心配。
「一般化には3つの例が必要」の章なんかは、関数を汎用化したほうが良いという一般論と、汎用化しすぎて何をする関数なのかわからないことがあるという経験とで揺れていた自分の価値観に一つわかりやすい指標ができて、一つ悩みが減った気がする。他にもハッとさせられるようなアイディアが紹介されていて、自分のコーディングスタイルに新しい規約のようなものが追加され、今後悩む部分が減ったという実感がある。
ただし、この本はリーダブルコードのようにルールとなる点を作るのではなく、自分の経験の中に眠っている点と点を繋げるような性質のものが多い気がする。そもそも元となる点が無いと何を言っているのかわからないし共感できないと思う。Amazonのレビューにポツポツついている低評価はそれが原因じゃないだろうか。
正直良いプログラムの書き方的な悩みがほとんど解決した感覚すらあり、いい本に出会えてよかった。そのぐらい個人的にはおすすめな本。
- ルールが浸透するには覚えるのが簡単なのと、適用される状況の認識が簡単の2つが重要
- 後者は自分の中から出てこない発想だった。自分が作ったルールがワークしなかったケースの殆どの原因がそれかもしれない
- 関数を一般化させないといけないという要件は無い。例がない状態で想像のユースケースで一般化しても、その想像が的中するとは限らない。
- 一般化していない関数はシンプルなので、3つの例が集まったときに一般化させやすい。逆に不要な要件を持ってしまった関数と別の例で一般化するのは難しい。
- 最適化するな、の話は解釈の仕方で感想が分かれそう。自分は納得できた。シンプルなコードであれば、パフォーマンスが問題になったときの改善も容易である。だから早まった最適化はせずにひたすらシンプルなコードを目指そう。
- 次の章に書かれている筆者の同僚とのディスカッションも興味深かった。一般的にはパフォーマンスが問題になるプログラムはごく一部だが、パフォーマンス改善をしている人が関わるプログラムは100%パフォーマンスが悪い、だから過剰に反応している、という。
- 実際のところ、シンプルなコードから劇的にパフォーマンス改善できてもまだ足りなくて困る、という状況はあるだろうから、本当に人によるかも
- コードレビューはレビュアーに見せるコードを書くというマインドセット、レビュアーに説明するというプロセスが重要であって、レビュアーがどうレビューをするか?という点はさほど問題ではなさそう
- レビュアーがバグを見つけるのを期待するようなレビュールールが現実的でないと思っていたので納得感があった。我が社の障害の振り返りでもレビューしっかりやるみたいなアイディアが多数あって心配していたが、そのモヤモヤが言語化できた
- 実行されないコードは動かない、壊れるという話がコメントにも適用されたのは面白かった。コメントで前提条件をごちゃごちゃ書くならアサートを仕込めとのこと
- ある課題を解決するために事前に計算して推測することで、うまくいかないアイディアをフィルタリングすることができる。うまくいくアイディアかどうかは実際に試さないとわからない。
