序文
業界では「コード整頓道」高い視認性を持って、多くの高齢者が新規参入を読むことをお勧めします。この本は、可能なプログラム設計（コードレベル）の多様性を実証する小さなプログラムの方法の段階的な転換です。あなたは、コードを設計する方法を教え、なぜこのデザイン、何この設計の利点はい。週読み取ることにより、以下の点をまとめました。
機能
すべてのプログラミング機能は非常に重要であり、HellWorldからこの小さな始めている機能を設計することを学びます
される関数短いです。ショートは、読んで維持し、設計するのは簡単でした。（誰もが恥ずかしが自分のコードを読み取ることができない経験しました）
機能だけ一つのことを。単一責任原則のデザイン機能に応じて。プロセス制御論理状態変数を変更し、操作、またはコール機能の複数の抽象化の次のレベルを実行する：関数とすることができます。
- 関数をに分解された抽象化レベルの複数の設計、だけハイレベルの機能は、次の層の機能、ツリー形式、パッケージの層を呼び出します。
関数は、識別パラメータを有していなければならない物品2つの原則に違反する実装の少なくとも二つの機能があることを意味し、（APIの関数として除きます）。しかし、明らかにそれは小さな関数を複数に分割します。
関数パラメータは、できるだけを有する包装される複数のパラメータ全体の着信にします。ない論理的に全体の場合は、機能は確かにその後、個別に呼び出すことが、複数の小さな機能に分割することができます。第4条識別パラメータを包装することができるパラメータの関数として直接ではなく、関数に渡されたバルクに
この関数は一つのことを行うには、本当に最高です簡単ではない一時的な便宜のために、数行のコードを追加します。ユーザー名とパスワードを検証する場合は、ログイン認証機能として、検証後にいくつかの他のものへのユーザーの初期化方法。この機能は、他の時点でユーザー情報を確認することはできません。原因。
基礎となる機能は、状態のパラメータを変更しないでくださいあなたは状態の特定の種類を変更したい場合は、クラスに参加して、関数を呼び出すようにする機能を入れました。例えば：x.addFooterに、状態XコールaddFooter（X）の機能を変化させるために（）。
関数は、エラーコードは戻りません。あなたが列挙型Iエラー・コードを持っていることを必要とし、オープンクローズドの原則（あなたが新しいエラーを拡張する新しいエラーコードを追加する必要がある）の違反は、直接、うまく投げ、。（例外は継承された彼の父によって拡張することができます）。しかし、異常よりも、実際にアプリケーションエラーコードが少なく、かつ異常な肥大化したコードにつながることができます。
関数名は、明確な役割の機能を説明する必要があり、短い機能が行うことは困難命名は、上記の原則に従って（関数は、あなたが多くのことを行うことができます）で、デザインの機能があるかどうかを考える必要があるかもしれませんであれば、それは、難しいことではありません、文書で頻繁に顔を避けるために、 。そして、名前の名前は、関数名を形成するために、他の簡単なと混同すべきではありません。例えば：計算が追加される手段、および挿入または追加する必要があり、コレクションを追加挿入を表すリストで使用されるべきではないに（）を追加します。それは概念が一つの単語に対応しており、一貫して単純です。
第二のフォーマット
誰もが自分のコーディングスタイルを持っている、本は勧告Javaや他の言語のいくつかをまとめたもの
良好な形式がなされるべきである小さな、微細なコード断片（機能）構成
パケットコード、パッケージコードガイド部材変数、関数の方法。空白行は、別々のコード・ブロックを形成する、離間しています
下順に上から機能を使用する前に宣言したトップクラス変数宣言プロセス変数に、と呼ばれ、彼ら
- コードの100行以下で、同一ラインは空間順に従って計算することができる、例えば：
100 * 732 /（3 + 2）*（5-1）
括弧内の操作のすべての密集、その他の操作スペースで区切られ、操作の順序を簡単に確認することができ - インデントは、包含関係を表しています。Javaは必須ではありませんが、Pythonのインデントが含まによって表されます。
ボスをどのような形式を使用するどのような形式の規定に：結論こと言って
三つのコメント
事実の後に書かれた注意事項は、あなた自身が最も見るために
- バック以前の内容に、小型かつ洗練された関数を書くために私たちを必要とする - 良いコードのみ、注釈の少量を必要とする、コードがあなたの意図を表現することができるようになります。（しかし、これは、あなたがコメントを書いていない理由ではありません）
- コメントは、この良いことがあります。以下のような：意思か（私はなぜこの機能をこのように実現される）遠大の抽象解釈;（コードが悪い書かれているので読みにくいものではなく、複雑なビジネスロジック）機能を読み長く困難な精緻化、警告キー重要な部分のいくつかは、（これらの部分は、一般に、データエンティティの一部を変更する関数されている）; TODOコメントを行うために思い出させると次のことを知らせるために、（いくつかの悪いコメントはありますが）JAVADOCパブリックAPIを書くことを学ぶ良いコメントです。
- 腐った解釈はよくあるケースです。以下のような：余分なコメント（簡単な関数強制的に、コメントを追加し、ソースコードを読んで、コメントよりも高速になります）。誤解を招くようなコメント（注釈が常に間違って、おそらくあなたの更新コードからのコメントを更新しませんでした - 発生する可能性があり、特に小さな機能をコードをコメントアウト（なぜあなたは、コードを削除しない）;？あまりにも多くのナンセンスノート（言語は体育の先生を教えている）;問題）。
四つのカテゴリー
実際には、設計クラスの設計と機能のための本は同様であり、したがって単一のコンパクトなクラスが機能する必要があり、結合小さく低い、そして最終的に外向きに合わせたようなAPIのファサードパターンを提供します
ファイブシステム
システムの全体的な構造を設計
- 全体的な構造やビジネスシステムが別々に使用します。順番に実行するプログラムは、構造に影響を与えてはいけない、建設、使用には影響を与えてはいけません。これはまた、Springアプリケーションの理由の広い範囲の一つであり、春のコアは、クラスの船です。
- ビジネスロジックのチェックおよびロギング方式で単離されたまたはそうでない場合は、絡み合ったコードを理解し、変更することは困難です。春AOPはまた、この問題を解決します。
シックス・テスト
テストはちょうど妹のことをテストされていません
- 試験関数（メソッド）短くすべきである（十分に小さい場合には、本来の機能テスト機能自然に小さいです）
- 最高のテストされている各カテゴリの下に、テスト時間は、将来のデバッグ時よりも少なくなります。位置決めした後すぐに、基本的な機能からデバッグまで少しの測定。
- テストクラスは、各テストの後に簡単な修正のために保存する必要があります