この記事は、
Steve Yeggeの記事をきっかけに作成されました
。 n00bの肖像 （
habraの翻訳付き ）。 私にとって、この記事の主なメッセージは次のとおりでした-コメント、クラス、メソッド、コードの数を減らしてください。 コードをよりタイトにし、モデリングをやりすぎないでください。 私はこの世界のビジョンを判断することは困難であり、実際、コメント自体の問題はより推測的なものです。 しかし、私に鋼針を刺したのは、そのような厳しいコードをテストする問題でした。
問題の概要を説明するために、小さな例を見てみましょう。 サーバーがあり、外部からコマンドを受信するとします。 これらのコマンドの処理ロジックを記述する必要があります。 この問題を次のようにシミュレートします。
なぜそんなにそうなのか：まず、
インターフェイスと
コードの原則を順守します。これにより、たとえば、サーバーをテストしてコマンドハンドラーを偽装（モック）することができます。 次に、各チームのロジックを個別のクラスに分離することで、このロジックを簡単にテストできます。
Handlerクラスを1つだけ作成し、各チームにパブリックメソッドを追加してこれらのメソッドをテストしないのはなぜかと思うかもしれません。 しかし、私の意見では、問題は、この場合のクラスの機能がクラスによって「広がっている」ように見えることです。ある意味で、彼にとって不要なハンドラーの実装の詳細を外部に公開します。 結局のところ、サーバーが知る必要があるのは、このクラスがコマンドを処理できることだけであり、コマンド1、コマンド2、およびコマンド3を処理できることではありません。
ここで、この問題を「タイトなコード」として実装する方法について考えてみましょう。 もちろん、20〜25年の経験を持つ著者である著者について話すことや考えることはできません。 おそらく彼は何か他のものを意味します。 しかし、この文脈では、コードの圧縮は、たとえば、すべてのハンドラーを1つのクラスにはんだ付けすることです。 さらに良いことに、1つの方法で：
パブリッククラスHandler {
public Result handle（コマンドコマンド）{
if（command == COMMAND1）{
//ロジック1を実行します
} else if（command == COMMAND2）{
//ロジック2を実行します
}
//。 。 。 。
その他{
log.error（ "コマンドの処理方法がわからない" +コマンド）;
}
結果を返す;
}
}
または、コマンド処理を別のクラスに含める必要はないでしょうか？ それらをサーバーに配置するだけですか？
パブリッククラスサーバー{
public void converse（ソケットクライアント）{
intコマンド;
while（（command = client.getInputStream（）。read（））！= -1）{
if（command == COMMAND1）{
//ロジック1を実行します
} else if（command == COMMAND2）{
//ロジック2を実行します
}
//。 。 。 。
その他{
log.error（ "コマンドの処理方法がわからない" +コマンド）;
}
}
}
}
これをどのよう
にテスト
しますか？ ここでは、統合テストのみがロシア民主主義の父をどうにかして救うことができます。 おそらく著者は、まったく異なるものを念頭に置いていたのでしょうか？ ハブラグルがこのテーマについて私と他の「ティーンエイジャー」を啓発してくれたら嬉しいです。
LispやPythonのようなマルチパラダイム言語では、状況は多少異なります。 それらの関数は、複数レベルのmap-filter-reduceレイヤーになる傾向があります。
ここでは、各マップを分離したり、フィルター処理したり、操作を個別の機能に分けたりすることはほとんど意味がありません。 乱れたラムダの代わりに十分にテストされた述語を使用し、map-filter-reduceの最も重要なレイヤーについてコメントし、最終的な関数を十分にテストするだけで十分です。
PS並べ替えのようないくつかのアルゴリズムの命令型言語での高密度実装を完全に認めることを予約します。 ジャグラーなどのアルゴリズム-1つのボールでジャグリングすることは意味がありません。つまり、同時に多くのボール（オブジェクト、変数など）をジャグリングするときにのみ表示されます。 ここでも、オプションがあるように思えます。