『クリーンコードの道』読書ノート

1. What?
Jack Reecvesが発表した「ソースコードは設計です」のように、ソースコードは最高のソフトウェア設計ドキュメントであり、他の非コード的なドキュメントはソースコードの補助にすぎません.本稿では,プログラミングとソフトウェア設計の関係を議論するためではなく,ソースコードの重要性を説明したい.
簡単に言えば、コードの行雲流水をきれいにするのは美しい文を読むのと同じで、コードはできるだけ自分で解釈することができます.具体的には、クリーンコードは次の特性を備えています.

変数、関数、クラス、パッケージ、モジュールの命名は合理的で意味がある

コード構造(フォーマット)明瞭

必要な合理的な注釈情報:コードが自己解釈できるのは理想的で、この注釈の場所はやはり

を免れられない.

合理的な異常処理メカニズム

有効なログ情報

オブジェクト向け設計の原則

に従う.
2. How?
私たちが文章を書くのはまず考えてから書くのですが、普通は一気に書くことはできません.初稿を出してから調整し、美しい言葉を使ってゆっくり磨く.コードを書くことは、文章を書くのと同じように、修飾を絶えず調整するプロセスでもあります(名前の変更、関数の分解、重複の解消などの操作が繰り返されます).きれいなコードを書く初心さえあれば.
2.1.有意義なネーミング

名実ともに、必ず誤解を免れます:変数、関数などに適当な名前をつけるのは実は時間がかかることで、既存の変数などに対して、もっと適当な名前を思いついたらすぐに変えて、他の開発者を誤解しないでください.

は、符号化仕様の命名関連部分を遵守する.

2.2.明確なコード構造

問題分解、モジュール職責区分

符号化前に最も基本的な設計構想が必要であり、どのような設計粒度(システム、モジュール、クラス)にかかわらず、そのコアスケルトン、流れは胸に竹を立てなければならない.

関数はできるだけ簡略化され、簡略化された関数は行数が少ないことを意味しない.一つの関数が一つのことしかできないことを保証すれば、ここの「一つのこと」は抽象的で、異なる人は異なる解読を持っている.私の区分原則は:関数の多重化と読書に有利である.

関数パラメータが少なければ少ないほど、多くのテスト例を省くことができる;パラメータはできるだけ入力にのみ用いられ、戻り値によって関数結果出力を行い、パラメータはできるだけ入力と出力情報(マルチスレッド開発時を除く)

を同時に負荷しない.

関数はクエリー操作をするか、設定操作をするか、同時にしないでください.

2.3.コメント
2.3.1.合理的な注釈

注釈は、コードがプログラムの意図を表現する力がない場合の有効な補完を補うためである.

コード自己表現できるのはコードを引っ張る最高の境地ですが、現実はいつも残酷で、コードを書く必要があることに気づいたとき、コードが下手で説明できないかどうかを反省する必要があります.注釈は悪いコードを美化することはできません.

注釈はメンテナンスコストがあることを理解する必要があり、タイムリーに更新しないと混乱を引き起こしやすい

.

外部サービスインタフェース/APIはいずれも必要な注釈情報を提供する必要があり、一定のメンテナンスコストがあるが、必ず節約できない.

潜在的なピットは、他の開発者に警告するために注釈も必要です.最も一般的なのは、FIXME、スレッドの不安全な問題を解決するためのコードロジック(経験のない同僚がむやみに変更する可能性があることをはっきり書かないためにBUGを導入することです.SimpleDateFormatなど)

です.
2.3.2.悪い注釈

個人でJavaBeanのGetter/Setterメソッドは注釈不要の

だと思います

コードの修正にはログ式の注釈を書く必要はなく、くだらない注釈を書かない

関数名または変数名で自己解釈できるものは、できるだけ注釈

を書かない.

制御文の括弧の末尾に、} // while

のような文の終わりを表す注釈を付ける必要はありません.

も大きな注釈を書く必要はありません.もしこのような状況が発生したら、機能関数の分解が合理的ではないに違いありません.

2.4.フォーマット

行符号化仕様のフォーマット部

に従う.

空行

を合理的に使用する.

連絡の緊密なコードはできるだけ一緒にいます

同じフォーマット・ルールを使用するチーム

2.5.対象とデータ構造

抽象に真剣に対処して、簡単なインタフェースを書くのではありませんて、いくつかの方法をプラスして抽象

ですとしても

対の像はデータを隠し、操作を暴露する;データ構造はデータを暴露し、操作関数

を提供しない.

DTO、DDDの充血モデル、類JavaBeanの失血モデル、個人プロジェクトでは充血モデルを使う傾向があるので、本の中のいわゆる混在はあまり同意しません.

2.6.エラー処理

オブジェクト向け設計では、エラーコードを返すのではなく、異常を食べるべきではない高速放出異常原則を厳格に実行する.

Checkedタイプの異常を極力投げ出さないという説に対し、個人的には保留態度

外部の複雑な異常階層に対して、重複コード

を低減するために必要なカプセル化が可能である.

はnullを戻り値やパラメータなどとして使用することはできるだけ避ける.nullは曖昧さ

を引き起こす可能性があるからである.
2.7.1サードパーティ製ライブラリの処理方法

サードパーティインタフェースを包装することを提案し、後続の複数の提供者

を容易にする.

チームワークでは、依存する他のサブシステムのインタフェースが定義されていない場合、当方のニーズを明確にしました.インタフェースを定義し、Mockクラスを提供することで、モジュールの安定性とテスト性を保証できます.

依存サードパーティインタフェースが本システムで多く使用する場合、外部インタフェースの変化

に適応するために、統一的に再包装することも提案する.

包装の目的は、外部不確実性を遮蔽し、ロバスト性

を増加させることである.
2.8.クラスとシステムの設計

オブジェクト向け設計の原則

に従う.
転載は出典を明記してください:cloudnoter.com