【書籍】CleanCode

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

スケジュールと要件を守ることに負けずにコードを守る
混乱を埋め込めば、たちまち生産性は低下し、結局納期など守れない

クリーンコードとは、他の人が拡張することが容易なコード
時間の経過とともにコードがよい方向に向かっていくこと

switch文に対する一般的な規則は、一度しか現れず、多態オブジェクトを生成し、
継承に裏に隠れていれば許す

内容をよく表す名前は、不可解な短い名前よりも優れている

引数が多いとテストが困難になる

入力変数に対して変換を行うより、戻り値で返すべき
関数は何らかの処理を行うか、何らかの応答を返すかのどちらかを行うべきで、両方を行ってはいけない

コマンド関数からはエラーを返すのではなく例外を使用する

tryとcatchブロックの中身は関数にして外に出す
中に処理をたくさん書いていると可読性が落ちるため

変更するたびに逐次テストして確認すること
後で一気にテストしない

コメントを使わずにコードで表現するのがベスト

複雑で見づらい条件文はやめて、チェック関数などに置き換えるべき

コード自体を上回る情報をコメントで提供してはいけない

全ての関数にjavadocをつける必要はない
publicと補足が必要なものだけでいい

1ファイル200〜500行程度がよい

ファイル名だけでそのモジュールが自分が見たいモジュールか分かるようにする

ある関数が別の関数を呼び出しているのであれば、
それらは呼び出される順番に垂直方向においてあげること
そうすると見やすい

優先度の高い計算はスペースを用いず、低いやつはスペースを入れる
a*a + b*b

メンバ変数が多いという事は、クラス分割すべきということ

安易にゲッターとセッターを用意しない。それは隠蔽できているうちに入らない。

サードパーティAPIはラップして使用することで依存度を最小限にすることができる
そのまま使わないほうがよい。別のライブラリへも乗り換えやすい

特定の領域のコードでは1つの例外を返すのが適切
→いろんな種類の例外を用意しなくても、スタックトレースの結果などで理由はわかるから

nullを返すのはだめ、例外を返すようにする
サードパーティのもNULLを返すならラップすること

サードパーティのコードを調査し、テストケースを作ったりソースのリファクタリングをしてみる

テストのコードも製品コードと同様に重要

1つのテスト関数で1つの概念をテストするようにする
→ごちゃまぜのテスト関数をつからないこと

クラスの規則の筆頭は、小さくすること

クラス、モジュールは変更の原因となるものが1つでなければならない

クラスは拡張にたいしては開かれて、変更に対しては閉じていなければならない

クラスは抽象層にのみ依存すべきで、詳細な具象層に依存すべきでない

構築に関するすべての局面をmainまたはmainと名づけられたモジュールへ移動し、
システム内の残りの部分は全てのオブジェクトが適切に生成され、関連付けられているという前提の下に設計する

決定は、それが手遅れとなる直前まで延期することが最善である

テストがあるということは、コードをきれいにすることで間違って壊してしまうかもしれない
という恐怖を取り除いてくれる

大きな再利用を実現するには小さな再利用を理解すること

同時並行性に関係するコードを他のコードから分離すこと

データ共有の問題を解決するためのよい方法は、そもそもデータの共有を避ける

同期化セクションは出来る限り小さくする

スレッドのテスト
・スレッド化されていないコードを先にテストしておく
・プロセッサの個数以上にスレッドを作る
・異なるプラットフォームで実行する
・強制的にエラーを発生させる

プログラミングは科学というよりも工芸である。クリーンコードを書くためには
まず汚いコードではじめ、それをきれいにしていくべき

ソースコード内に変更履歴は不要
→ソースコード管理ツールがやってくれるから

内部実装がわかってしまうようなクラス名はつけないこと

定数のみのクラスは作らず、enumを使用すること！

ベースクラス（親）が継承クラス（子）についての情報を持たないこと

コード中の不要なコメントはどんどん削除すべき
→テストを用意しておけば壊すのも怖くない

関数が何かの状態を変更するなら、呼び出しているオブジェクトの状態を変更すること
→引数が入力だけでなく出力の意味も含む関数はダメ（ぱっと見でわからないから）

boolean値を引数にとるような関数は、すなわり2種類のことをやっているわけなので、だめ
2つ用意するかすること

直感に頼らず、あらゆる境界条件を見つけ出してテストを書くこと

重複コードが存在するという事は、そこは抽象化できるということ

switch/caseやif/else文は多態におきかえるべし

ベースクラスと継承クラスを別のjarにし、ベースクラスが継承クラスの情報を持たないようにすれば
それぞれ独立したコンポーネントとして扱うことが出来る

別のクラスの変数、関数に関心を持つべきではない
（直接参照などはあまり好ましくない）

1つの関数に振る舞いを選択するコードを入れるより、
複数の関数に分けるほうが良い

staticメソッドよりも非staticメソッドを好むべき。迷ったら非static

計算過程を分けて、途中で適切な名前をつけた変数を用いることで
不透明な部分を見やすくする

条件をカプセル化する（条件文を関数に置き換えてしまう

定数を継承しない