Clean Code アジャイルソフトウェア達人の技
Amazon で購入 : https://amzn.to/3iPIbAZ
著者 : Robert C. Martin
購入 : 2020-09-13
読了 : 2020-09-22
前書き (by James O. Coplien)
この本は、地味な関心事を扱うが、それらの価値は決して小さなものではない
神は細部に宿る : 建築家のルートヴィッヒ・ミース・ファン・デル・ローエの名言
この言葉は、現代のソフトウェア開発、それも特にアジャイル界においてアーキテクチャが果たす役割に対する議論を思い起こさせる
ソフトウェア産業においては、80 % 以上の作業が修正作業であり、これは奇妙なことに 「保守」 という言葉で呼ばれる
よいソフトウェアの構築を指向する、典型的な西洋風の考えを信奉するのではなく、我々はもっと建設業における、家の修理工や、自動車業界における車整備工のように考えるべき
1951 年頃、TPM (Total Productive Maintenance) と呼ばれる、品質向上の取り組みが日本に現われた
TPM は製造よりも保守に焦点をあてる
TPM を支える主な柱はいわゆる 5S 原則
5S は規律 (啓蒙の意味で 「規律」 という言葉を使用)
5S の原則はリーンの基礎となっている
TPM の考えで機械を整備する上では、「故障を修理する」 というのは例外である
水準を 1 つ上げて、故障する前に修復する
コードで考えるなら、妥協を許さずにリファクタリングを実施する
これにより水準をさらに 1 段階改善
TPM の動きは、50 年以上前に革新を起こした : そもそも整備しやすい機械を作り出した
コードを読みやすくするということは、動くようにすることと同じくらい重要
> 細部には強い力があり、さらにこうした人生への取り組みには、何かしら地味でありながら重要なものが存在し、それが日本人の根源的なものを滲ませるのであれば、我々は固定観念的に、その取り組みに期待を持つ
日本人に対する固定観念みたいなものがあるｗ 
> 日本人の世界観では、日々の作業担当者の産み出す重要な価値を大事にします。 さらにいえば、それは単純な、日々の作業者の行動に立脚している開発体系です。 品質というのは、天から降ってきた高尚な手法からではなく、幾多の無私無欲の行動から得られるのです
品質に対する日本的な考えと欧米の考え方の違い、みたいなのは面白い
組織レベルのソフトウェア品質マネジメント#5ec2e98d9020510000f71b11 あたりでも、日本流と欧米流の違いみたいなのが述べられている
序論
WTFs/m が、コードの品質を測定するのに有効な唯一の指標
ネタっぽいけど確かに良さそう
職人技の習得は知識と作業とに分けられる
職人が身につけるべき知識 : 原則、パターン、実践、そして経験則といったもの
作業 : 一所懸命に作業し、実践することで、こうした知識を咀嚼して自分自身の指、目、そして腑へと落とし込む必要
本書では綺麗な理論だけを伝えるのではなく、自分自身で実践し、失敗することも求める
自転車に乗ってこけずに走ることができる古典数学の理論を伝えても、実際に自転車に乗れるようにはならない
実際に実践し、失敗し、学ぶことで、初めて自転車に乗れるようになる
本書の 3 パート
クリーンコードを書くための原則、パターン、実践
いくつかのケーススタディ : 実際に手を動かして学ぶ必要
経験則とにおいのリスト : 上のパートで実際に学ぶことで、このリストも価値あるものになる
1 章 : クリーンコード
納期を守るためには、コードを常に、きれいな状態に保つしかない
クリーンコードとは
2 章 意味のある名前
問題領域と解決領域の概念を分離すること
問題領域の概念を扱うのであれば、問題領域の言葉を使うべき
3 章 関数
関数はとにかく小さくすべし
1 つのことのみ行うように
関数が複数の抽象レベルを扱わないこと
関数は抽象レベルの順番に並んでいる必要 (逓減規則)
関数の引数は少ないほど良い
3 はできれば避けるべきで、4 以上は基本的に避けるべき
フラグ引数は汚いので止めるべき (フラグで処理を分けるということは関数が複数のことをしている)
依存性磁石を避ける
例えばエラーコードの代わりに例外を使用するなど → 既存コンポーネントのリコンパイルや配備しなおしが不要 (開放閉鎖原則)
4 章 コメント
コメントは、コードでうまく表現することに失敗したときに意図を説明するために使用するもの
5 章 書式化
垂直方向の書式化
下の方に詳細が書かれているべき
深い関連のある概念を複数のファイルに分散すべきではない
インスタンス変数はよく知られた場所に置くべき
Java ではクラスの最初
関数が別の関数を呼び出すのであれば、それらは垂直方向に近く、呼び出し側を呼ばれる側の上に置くべき
水平方向の書式化
昔の 80 文字ルールは独断が過ぎる → 100 や 120 文字でも良い (が、それを超えると不注意)
位置合わせはしない : 位置合わせしたくなるなら、それはリストが長いことが問題
6 章 オブジェクトとデータ構造