ルールズ・オブ・プログラミング ―より良いコードを書くための21のルールを読んだ。
Ghost of Tsushimaを作ったSucker Punch Productionsの共同創設者であるChris Zimmermanという人が書いた。Sucker Punch Productionsで用いている21のルールを紹介している。ゲームという文脈ではあるが、別に業界以外の人でも活かすことができる。
コード例もそこそこあってC++で書かれているし、付録でPython・JavaScriptプログラマー向けのコード読解法がある。僕はコード例をあまり読まなかったけど。。。
まえがきにも書いてあったが、最初から読む必要はなく興味あるルールから読むことができる。興味あるルールだけ読んで、今は興味がないルールは放置とかでも良いと思う。この手の本はそういう読み方ができるから好きだ。実際僕も、冒頭を読んで今はいいやってなったルールは飛ばした。
気になるルールをピックアップしてみる。
ルール1 できるだけ単純であるべきだが、単純化してはいけない
どこからでも読めると書いたが、このルールをまず読むことがオススメみたい。
僕自身も可能な限り平易なコードを書きたいと思っているので、このルールは納得。解法が単純にならない場合は、問題を単純化するっていう手もあると。
ちなみに単純化してはいけないがいまいち理解しきれていないのだが、一般化し過ぎるなってことなのかな？
ルール4 一般化には3つの例が必要
これは僕が提唱している39ルールですね。所謂同じことが3回出てきたら抽象化・共通化を考えるってやーつ。
ユースケースに基づいて実装するのが重要。わからない未来のために、過度に一般化するのはNG。一般化はどんな文脈でも使える部品を目指すことになりがちだけど、1つのユースケースだけで成立する文脈のために実装する方が遥かに簡単ですね。
なぜってところで、一度抽象化すると他の選択肢を見つけるのが難しくなったり、一般化により特化が扱いにくくなると。自分で可能性を狭めるな、ってことだと思う。
ルール6 コードレビューが役に立つ3つの理由
ここ面白かった。
実はジュニアレビュアーxシニアレビュイーという組み合わせが知識の共有には有用である、と述べている。シニアのソースコードをジュニアがレビューすることで、ジュニアは色々な知識を自分で発見していく。ソースコードの大局的な構造構築を理解するのにも、このアプローチは良い気がする。
わからないところはシニアに質問すれば良いし、回答することでシニア自身も理解が洗練されていきそう。
ちなみに、ジュニアレビュアーxジュニアレビュイーの組み合わせは危険らしい。
ルール9 集約可能なコードを書け
これはプログラマー脳の話。
短期記憶に入る情報数には上限があるから、抽象化を使って情報をまとめてい短期記憶を有効に活用しようって話かな。ここはSLAPを意識している人にはわかりみが深いと思う。
ルール10 複雑性を局所化せよ
普通に局所化の話なんだけど、やっぱり局所化の考え方って大事だよね。
ルール14 コードには種類が4つある
プログラマーを3つに分類している。
- やさしい問題を複雑に書く人は平凡
- やさしい問題を単純に書く人は優秀
- 難しい問題を単純に書く人は偉大
自分どれかな〜とか考えると悲しくなってくるが。。。
まとめ
こんな感じでピックアップしてみたが、環境・文脈によって他のルールも参考にできそう。チームのルールを策定する時に使えそう。
