Robert C. Martin先生のCleanCode第1章を読んだメモ。

CleanCode(第1章)の概要

CleanCode(第1章)の概要は以下でした。

  • この本を読む必要性
    • プログラマだから
    • より良いコードが書きたいと思っているから
  • この本を読んだ後できるようになること
    • 良いコードと悪いコードの判別
    • 良いコードの書き方の理解
  • コードの書き方に関する必要性
    • 「仕様を元にコードが自動生成される時代が来るからコードの書き方はどうでもいい」とか馬鹿馬鹿しい。
      • それができたら、その自動生成される元の仕様がそもそもコードみたいに形式化されてるから、それはもうそれ自体がコード。
  • 粗悪なコードの事例
    • 粗悪なコードによりメンテ不可能になって、会社を廃業に追いやった事例もある。
      • 粗悪なコードによる深刻な障害をwading(ウェーディング)という。
    • 後で修正しようはやらない。(レブランの法則)
    • 粗悪なコード環境で生産性はどんどん0に近づいていき、管理者も人的リソースを増やして解決しようとし負のスパイラルが生まれる。
    • それらを解決するためのチームを作り、リファクタリングに10年続いた例をみたことがある。
    • つまり、コードを洗練することは、コスト効率だけではなく生き残っていくのに必要。
  • 粗悪なコードの原因
    • マネージャでも客でも、マーケティングタイプでもなく、我々自身。
    • PMはスケジュールを守るため、作業を手伝うべく我々をみている。
    • PMも粗悪なコードを望んでいるわけではない。
    • PMの仕事はスケジュールと要件を守ること。
    • PMの熱意に負けないぐらい熱意を持ってコードを書こう。
    • 混乱を招くリスクを理解していない管理者に負けるならプロのプログラマじゃない。
  • 綺麗なコードを書くためには
    • 良いコードと悪いコードの判別ができれば書けるわけではない。
    • 骨身を惜しまずに獲得したコードのセンスが必要
    • 無数の小さな手法が必要
    • 規律を守ることが必要
  • 綺麗なコードとは(定義がエンジニアの数だけあるので、著名なエンジニアの意見を紹介)
    • ビャーネ・ストラウストラップ(C++の生みの親)
      • 1つのことをうまくやる(SRP)
      • 壊れた窓の誘惑に惑わされない
      • エラー処理が完全でなければならない。
    • グラディ・ブーチ
      • 設計者の意図をないがしろにしない。
      • 明快な抽象化がされている。(ISP)
      • まっすぐな境界が引かれている。
    • デイブ・トーマス
      • 原作者以外の人にも読むことができる。
        • 文芸的
        • 依存性が最低限
        • 明朗で最低限なAPIのみ提供している。
      • 変更が容易なコードではなく、拡張が容易。(OCP)
      • 単体テストと受け入れテストがある。
        • テストがないコードが洗練されているとは言えない。
    • マイケル・フェザース
      • コードが単純
      • 秩序が保たれている。
      • 細部に対して気配りがされている。
    • ロン・ジェフェリー
      • 全てのテストを実行する
      • 重複がない
      • システムのあらゆる設計知識が表現されている
      • クラス、メソッド、関数といったものの数が最小限
    • ワード・カンニズム
      • 自分の予想を上回っているコード
        • 読んでいて驚きがない。
        • 読むのに努力が必要ないため。
    • Robert C. Martin
      • どれも絶対的に正しいように説明はするが、絶対的に正しいわけではない。
      • この本以外にも専門家技術について主張を行う人はいるのでそれらの意見も必要。
      • ただ、我々の考える専門職としてふさわしい綺麗なコードを紹介はするから、目を背けず関心を持って欲しい。
  • コードを満足に書くには
    • 読みやすくしなさい。
      • 読むと書くの比率は10:1以上
      • 読みやすくする = 書きやすくするである。
    • コードを何度も洗練しなければいけない。
      • ボーイスカウトルールを採用する

感じたこと

粗悪なコードの原因については、胸が痛い。
ただ、個人的にも粗悪なコードのリスクを説得できる手法が必要だなと思った。
個人的に以下を試してみたことはあるが、あまり理解が得られなかった。

  • メトリクスの計測(メンテナンス性が世間一般から見てこれだけ低いなどの説明)
  • 現在の実装により、現在このような機能が開発できないなどの説明。

そのため、本書にもあるようにコスト効率を計測するのが数字で示せて一番てっとり早いかもしれない。
コスト効率の計測のためには、現在の実装の修正に関する既存のコードの調査、修正時間を計測する必要があり、修正の着手に漕ぎ着けるまでには結構な根気が必要になる場面もありそうだなと思った。

綺麗なコードの定義については概ね同意できるが、「重複がない」については若干、懐疑的。
重複については、偶然の一致(Robert C. Martin氏のCleanArchitecture参照)もあるので重複が必ずしも悪であるというわけではないというのが、自論としてある。
ここについては、彼の言う重複の意図の詳細を知る必要がありそう。