「ルールズ・オブ・プログラミング」を読みました

「ルールズ・オブ・プログラミング―より良いコードを書くための21のルール」を読みました。中でも印象に残っている章をピックアップして感想をまとめています。

Rule1: できるだけ単純であるべきだが、単純化してはいけない

  • プログラムの中心にあるのは、複雑性との戦い
  • 最終的に、プロジェクトを殺すのは複雑性である
  • 不可避な結末を遅らせることこそが、効果的なプログラミングの本質である
  • 問題の本当に解くべき部分に向けた単純な解放があるならそちらを目指すべき

コメント

  • シンプルさは、コードの可読性、保守性、そして最終的にはプロジェクトの長期的な成功に直結する要素
  • コードが短かれけばいいというものではなく、問題の本質を理解した上で、適切なコードを実装すること

Rule2: バグは伝染する

  • バグは伝染するものであると認識すること
  • バグの早期発見が大事。自動テストが有効手段になる

コメント

  • バグの早期発見と対処を通じて、ソフトウェアの品質と保守性を高めるための重要な指針として、チームのコードレビューを心がけていきたい

Rule4:一般化には3つの例が必要

  • 一般化を早まることで実行されるない処理が混入する可能性がある
  • 一般化することによって、変更しにくいような方向性が確立されてしまう
  • 一般的な解法を作ることはハンマーを用意するようなもの。釘の袋を手に入れるまではハンマーを配ってはいけない

コメント

  • 良かれと思ってコードを汎用化しているが、「本当に今、必要なのか?」、「汎用化した分のコストを回収できるのか?」を意識していきたいですね。
  • 生成AIによってコードが簡単に汎用化できてしまうが、後からコードを読むのは人間なので簡単に実装できるからといって、汎用化してしまうのは気をつけたいです。

Rule5:最適化に関する教訓その1は「最適化するな」

  • コードはできるだけ単純に。実行速度は気にしない。十分速くなるだろう。そして早くなかったら、速くするのは簡単だ
  • 満遍なく最適化されているとパフォーマンスチューニングするべき箇所を見つけられなくなってしまう。
  • パフォーマンスが重要である根拠がないままに、パフォーマンスのためという名目でコードに複雑性を混ぜ込んでいる
  • Rule1にもあったが、最適化するタイミングを可能な限り後回しにするのがGood!ポイントをまとめるなら、
    1. シンプルで明確なコードを書くことを最優先せよ。
    2. 本当に必要になるまで最適化を行わない。
    3. 最適化が必要になった時、シンプルなコードなら容易に最適化できる。
    4. 最適化は計測と分析に基づいて行うべきで、勘や推測に頼るべきではない。
    5. 目標を達成したら、それ以上の最適化は避ける。

コメント

  • 汎用化してスマートなコードを書いてその瞬間に悦に浸っていてはいけないですね。シンプルで理解してもらいやすくて、保守性の高いコードを書いていかないと。

Rule6:コードレビューが役立つ3つの理由

  • バグを見つけること
  • チームへの知識共有
  • 良いコードを書こう!という意識になる

コメント

  • 3つ目の理由はコード品質を高めることになります。コードを読むメンバーが納得するか意識すると自然とチーム内のルールに合わせるようになるし、シンプルになっていくので大事な理由ですね。

Rule11:2倍良くなるか?

  • 漸進的発展派VS反復的再発明派
    • 前者は、インクリメンタルに問題解決を試みる。既存の解法を起点に思考する
    • 後者は、問題と解法を一緒に考える。設計を新しくやり直すチャンスに飛びつく
  • どちらのやり方だけが正解とは限らない。ケースバイケースで判断が必要。
  • 「2倍良くなる」ことが保証されるなら、後者の設計から見直したらいい。そうでないならインクリメンタルに修正したほうがマシ

コメント

  • プロジェクト進行中は自分は前者タイプでプロジェクトの合間でリファクタリングする時は後者タイプになっています。時間があるから設計見直そう!という判断軸でしたが、これからは改めたいと思います。

Rule17:大きな問題ほど解決しやすいこともある

  • 一般的な解法がより単純な道になった事例の全てで、観点を大きく変えることが必要だった。新しい観点が解法を根本的に単純にすることができる。

コメント

  • 難しい仕様を目の前にした時にいかにして仕様を満たすのか考えてしまいますが、一歩引いて全体を見渡して問題の本質を捉え直して解法を再検討できるようにしたいですし、時にはチームの歩みを止める勇気も持ちたいです。

まとめ

「最終的に、プロジェクトを殺すのは複雑性である」このフレーズが印象に残っている。この書籍全体がシンプルであることを心がけることでプロジェクトをチームをいい方向に進めていけると伝えてくれていると印象を受けました。 この書籍で得られたルールをチームメンバーに発信して、自分のチームのためのルールに昇華していればと思います。