毎年読み直したいCleanCode

タイトルの通り、Clean Codeを読みました。
就職してそこそこの年数が経っているのですが、やっと読みました。

良いコードは何か分からないと思っている人や新人の人には一読するのをおススメします。

Clean Code アジャイルソフトウェア達人の技

目次

• 第1章　クリーンコード
• 第2章　意味のある名前
• 第3章　関数
• 第4章　コメント
• 第5章　書式化
• 第6章　オブジェクトとデータ構造
• 第7章　エラー処理
• 第8章　境界
• 第9章　単体テスト
• 第10章　クラス
• 第11章　システム
• 第12章　創発
• 第13章　同時並行性
• 第14章　継続的改良
• 第15章　JUnitの内部
• 第16章　SerialDateのリファクタリング
• 第17章　においと経験則

感想

そこそこの年数が経っていますが、設計時から可読性や保守性などなどは意識してやっているつもりですが、自分の考えが間違っていないのか確認することができたり、新たに意識しなければいけないと気づくことができたと思います。
自分が重要だと感じた箇所をピックアップしたいと思います。
（これを自分の振り返りにも使おうと思います）

第1章

読みやすくすることは書きやすくすることを意味する

読みやすいコードだと、処理を理解するのに時間もかからず読み人もストレスを感じにくいです。また、バグ修正や改造する際に責務をまとめて書くことができたりモジュール分割が容易になるのでコードが書きやすくなる。
複雑なコードは理解するのに苦労するし、改造するにも複雑なので色々なところに手を入れないといけないケースが良くある。

第2章

気取らない

適切な名前を付けるのは、今でも難しい作業と感じています。
それは、英語力がないのもあるかもしれないですが、いかに意図した言葉を付けるのかが重要です。

第3章

関数内のインデントレベルは1つか2つ

インデントが深いことのメリットは何もない。
インデントが深くないだけで、コードの読みやすさが違うのは言うまでもなく構造化プログラミングでも意識しないとダメだと思う。

第4章

第5章

今回はスキップしました。
関数が小さいと全然コメントを書きません。

第6章

オブジェクトが保持するデータを最善の方法で表現するには、真剣に熟考する必要がある。
軽い気持ちでゲッタとセッタを用意するのは最悪。

オブジェクト指向は奥が深く、難しく感じだした今日この頃。
適切なクラス分けがいかに重要であり、難しいんです。

第7章

呼び出しているAPIをラップして共通の例外型を返す。
サードパーティーAPIをラップするのはベストプラクティスの1つ。

サードパーティAPIの置き換えが発生した場合に影響を最小限にするには、ラップしておく。
プリミティブ型やコレクションクラスもラップしておけば、型が変更になっても影響が少なくて済む。

第8章

スキップ。

第9章

何が洗練されたテストを作り上げるのか？
3つの要素がある。それは、読みやすさ、読みやすさ、そして、読みやすさ

テストコードがぐちゃぐちゃだとどれがどのテストか分からずに重複したテストが生まれたり、テストコードが実行されなくなる。

第10章

インスタンス変数とメソッドを2つあるいはそれ以上のクラスに分離する。

クラス分けする際の指標の１つ。
インスタンス変数を使わないメソッドは、責務が正しいか疑った方がいいと思う。

第11章

スキップ。

第12章

自分が書いた関数とクラスに、あとちょっとだけ時間を割きましょう。

1晩すると良いアイディアが浮かぶように、自分が書いたコードも時間をおいて考え見直すことで、より良いコードに近づけることができる。
その場でコーディングの誤りに気づくなんてできないことが多い。書いた直後はそれが正しいと思っているから。

第13章以降

より具体的な話なので、ここでは割愛。

最後に

始めにも書いてましたが、再確認できるものやあらためて気づくことができたものがあり、得るものが多いです。
これが2009年初版とは、良い概念はずっと通用するものなのだと思う。
また、来年必ず読もう。