私がきれいなコードシリーズから始めたとき、意図は、主題についての知識を修正するだけでなく、私が得た知識を通過することでした.
このシリーズはまた、本への迅速なガイドとして機能します.私はいくつかのトピックを覚えておく必要があるとき、私は私が探しているものを見つけることができます.
名前、機能、コメントについて話しました.
フォーマット、オブジェクト、データ構造、エラーの扱い方などについてお話しました.
この最後のポストでは、サードパーティ製のコードをどのように扱うかについて話します.
これらの9つのトピックに加えて、クリーンコードブックは、システム、いくつかのトピックについては、Javaについての対処について、それはまた、いくつかのコードのにおいを識別する方法をカバーしています.
私はこれらのトピックをカバーしないように私はシリーズをより一般的でフレンドリーなすべての言語にしたいと思います.また、私はゼロからビルシステムについての非常に実用的な知識を持っていないので、また、リファクタリングの排他的なシリーズは、きれいなコードブックでは、テーマは少し表面的なので、コードの匂いに対処することができると信じています.
つまり、今日のポストの話題から始めることができます

サードパーティ製コードを扱う

我々はほとんど100 %だけコードを作る.私たちは通常、私たちを助けるためにいくつかのlibを使用し、ほとんどの場合、一部の同僚は、コードに貢献する
コード境界を扱う方法を学ぶことが重要です.そして、我々のコードが終わるところと他のコードが始まるのを確認します.
サードパーティ製のコードを使用する際の問題の1つは、通常、私たちが必要とするより多くの特徴を持っており、これが私たちのコードを奇妙に振舞うことができるということです.

カプセル化ライブラリ！

この問題を解決する最善の方法は、クラスで使用するライブラリをカプセル化し、必要なメソッドだけをプルすることです.
サードパーティライブラリを独自のクラスにカプセル化するもう一つの利点は、そうすることで、libのバージョンを変更したり、ライブラリ自体をスワップすることも簡単にできます.
支払いサービスに接続する私たちのコードに図書館があるとしましょう.サービスを変更したい場合は、この変更を作成したクラスでのみ行うことができます.我々は、古いライブラリから新しいものまですべての参照を変えるためにコード全体を見る必要なしで、我々の方法を適応させることができます.

サードパーティーコードの調査

我々のコードに新しいライブラリを追加するとき、我々はそれがどのように動作するかを理解する必要があります.我々が生産において理解しないコードを使うことは、若干の問題を引き起こすことがありえます.
我々が加えたい図書館の動作を見つける最良の方法は、我々がライブラリを解決して、彼らを通過させたい状況のためにテストを書くことです.この方法では、コードがどのように動作するかを把握できませんが、これらのテストは、任意のバージョンまたはライブラリの変更に便利です.
バージョンを変更してテストを実行すると、どの動作が動作しなくなったかを確認します.
あなたのコードでサードパーティライブラリの使用をいくつかのトピックで要約することができます.

サードパーティのコードとあなたの明確な分離を維持します.

サードパーティ製のlibがコードに対して意味のある方法を振る舞うかどうかを確認するには良いテストを書きます.ライブラリではなく、コードをテストしていることに注意することが重要です.

コードが第三者コードと接触しないことを確認してください.あなたがコントロールしない何かよりあなたがコントロールする何かに頼るほうがよいです.

我々のコードが可能な限りそれを参照するように、アダプターをカプセル化して、作成してください、そして、どんな問題の場合でも、我々は図書館を交換することができます.

テストの整理

テストを書くときの最大の関心事は読みやすさです.
テストコードでは、読みやすさは生産コードよりさらに重要かもしれません.
テストを書くとき、我々は将来的にこのテストを直す(再)する必要がある人が不必要なコードを理解する必要なしで起こっていることを知っているためにそれの一部でない詳細を書くのを避けるべきです.

テストごとに1つのassertを使用する

理想的には、テストごとに1つのアサートしかないので、テストのどの部分が壊れてしまったのか疑問がありません.
この規則は多くの繰り返しテストをもたらすかもしれません.これを解決するためにbefore を繰り返します.
繰り返しすぎると、テストごとに1つ以上のアサートを使用することもできますが、アサート数を小さく保つことは非常に慎重です.
または、私の意見を与える-叔父ボブ-あなたはあまりにも多くの以来、この問題を解決することはできませんDRY は、コードの読みやすさを損なうことができ、読みやすさは、テストになるときは常にあなたの優先度であるべきです.
おそらく、より良いルールは、各テストは1つの概念をテストする必要があります.
それは非常に重要なので、一度に1つ以上のテストが簡潔に保つためには、何が起こっているのを追跡することができます.
アンクルボブは、クリーンなテストのルールを思い出すのを助けるために頭字語を使用しています.

京大化研

高速:テストする必要が高速です.彼らがあまりに長いならば、我々はテストを走らせたくありません.

独立テスト:テストは実行するために別の依存する必要があります.すべてのテストをランダムに破壊せずに実行することが可能です.

繰り返し可能:テストは、それがQA、生産、またはあなたの家のコンピュータのいずれかの環境で実行する必要があります.

self - validating :テスト結果は常にbooleanでなければなりません.

タイムリー:それらは生産コードの前に書かれるべき正しい時間を持っています.あなたが後でそれを残すならば、あなたはテストを書くのが難しくて、テストしないことを見つけるかもしれません.

クラスの整理

Javaでは、クラスを構成する順序は以下の通りです.

変数リスト.

パブリック静的定数.

プライベート静的変数.

インスタンスプライベート変数.

パブリック関数.

パブリック関数で呼ばれるプライベート関数は、呼び出し元のパブリック関数のすぐ下にある必要があります.

Rubyや他の言語では、すべてのプライベートメソッドをグループ化し、すべてのパブリックコードの後に記述する必要があります.理想的には、彼らはパブリックメソッドによって呼び出された順序に従ってください.

クラスは小さいはずです。

関数が小さくなければならないと言うとき、私たちはそれがいくつかの線を持たなければならないと言います.
我々がクラスが小さいに違いないと言うとき、我々はそれが一つの責任の原則に従わなければならないと言います.

しかし、クラスがあまりに多くの責任を持つならば、我々はどのように知っていますか？

クラスがあまりに多くの責任を持っている最初の徴候はその名前です.
クラスは、彼らが何をするかを理解できるように、説明的な方法で名前をつけられるべきです.“と”、“または”、“if”と“しかし”が必要な場合、彼らはすでに1つ以上のことをやっている.
以下の例では、SuperDashboard クラスは、最後にフォーカスされたコンポーネントを探し、ビルドバージョンを変更します.

public class SuperDashboard {
  public Component getLastFocusedComponent();
  public int getMajorVersionNumber();
  public int getMinorVersionNumber();
  public int getBuildNumber();
}

この問題を解決する一つの方法は、各責任のためのクラスを作成することです.
一部の人々は、我々が多くのクラスがあるとき、我々が欲しいものを見つけるのが難しいと不平を言います.
しかし、我々が我々が多くのものでクラスを持っているならば、我々が我々が探しているものを見つけるのに苦労すると思うのを止めるとき.私たちに多くのクラスがあるとき、それは我々がいくつかの引き出しが彼らの内容でラベルをつけられるかのようです.しかし、私たちにはほんの少しのクラスがあるとき、私たちはほとんど引き出しを詰めません.

粘着力について少し

理想的な世界では、クラス内の関数は、そのクラスで作成された変数だけで話をする必要がありますが、これが不可能であるので、我々はクラスを必要とします.

リファクタリングの結果としての新しいクラス

コードをリファクタリングするときに、流れの存在を観察することができます.

いくつかの小さな関数に大きな関数を破ると、変数を共有する必要があります.

関数がパラメータを必要としないようにクラスインスタンス変数を作成しますが、関数の少数が使用するインスタンス変数を作成するのはなぜですか?それはあまり面白くありません.

これは新しいクラスを作成することはできません.ディー

変更のクラスを編成する

私たちは、クラスが「開いている」原則に従う必要があります.
時々、我々のクラスは、常に変化しているサードパーティーライブラリをカプセル化します.これが起こると、親クラスでこれを解決してライブラリに接続し、新しいライブラリの実装で複数の子クラスを作成することができます.
からのポストイメージSarah Dorweiler