実際の作業を行うすべてのコード：計算の実行、データの変換、条件のチェックなど-これは「肉」です。 プログラムの筋肉。 構造化を担当するコードは「腱」です。 筋肉が骨に付着しているもの。 それが、個々の筋肉がそれぞれ独立したままであり、形のない詰め物で互いにくっつかない理由です。 そして、「骨」とは何ですか？ 骨-それをプログラムのアーキテクチャにしましょう。
たとえば、コードで大きなあいまいな部分を見つけて、それをリファクタリングし始めました。 そこで、あらゆる種類のメソッド抽出を行い、説明変数を追加し、デザインパターンをどこかに適用します。 コードは同じことを続けますが、異なって見えます。 コードの元の部分の一部は変更されていません（別の場所にクロールされました）が、古いコードの部分間に新しい追加の関係を作成する新しいコードが追加されました。 残されて追加されるものは何ですか？
説明のために、ボブおじさんのコードを彼の本から引用します-ta dam！ -「クリーンコード」。 リスト3.1の第3章の冒頭で、彼はtestableHtmlメソッドを提供しますが、このメソッドは理解できないため嫌いです。 この章の最後のリスト3.7で、Robertは、リファクタリングされたコードを提供します。これは、彼の観点からはるかに理解しやすいものです。 コードは同じことを行いますが、 18個のメソッドを持つクラス全体として既に配置されています 。
この新しいコードのわかりやすさについては、次回に説明しますが、今のところはどのような変更が発生したのかを調べます。
写真は、新しいリファクタリングされたコードを示しています。 それから、リファクタリングで生き残ったフラグメントを、変更されていないか、ほとんど変更されていない形で明らかにしました。 機能は同じままなので、「生き残った」コード（淡い）は、新しいコードでその仕事を続けている「肉」です。 ええ肉は見ません 何が追加されましたか？ 古い「肉」の流れを新しい方法で整理するコードが追加されました。 ここに一目でわかります：これらはメソッドの宣言と呼び出しであり、それによって古い作業コードがきちんと配布されています。
一方で、新しいコードは重複を取り除きました。 ある場所では、そのロジックがより簡単になりました。 古いコードでは 、pageData.hasAttribute（ "Test"）の条件がfalseの場合、行（ op ）が次々に実行されます：
buffer.append(pageData.getContent());
そして（ op ）：
pageData.setContent(buffer.toString());
不必要にpageData変数を独自の変更されていないコンテンツに割り当てます。 これは新しいコードにはありません。
一方、あいまいな名前が付いた多くのメソッドが追加されています。 コードの合計量が増加しました。 コードの実行シーケンスは、記述のシーケンスに対応しなくなりました（つまり、スパゲッティの兆候が現れました）。
それでも、私の意見では、これは正しい方向への一歩ですが、この特定のケースでは完全に成功しているわけではありません。 正しい方向は、両極端のどこかでのバランスのポイントだからです。 コードを構造化されていないひき肉に変えることはできませんが、判読できないスパゲッティが得られないように、構造でやり直すこともできません。 一部のイモムシは最大4,000の筋肉を持つことができ、人は約600の筋肉を持つことができると言います。 合理的なバランスを維持します。
プログラムはすべてライブであると思いますが、それらのすべてが単独で増殖できるわけではありません。 プログラムは、ある複雑なものを別の複雑なものに変換します。 彼らは人々と、そして互いに通信します。
時には、メスの代わりにキーボードを持ち、別々の部分から作曲することで息を吹き込み、次の創造を復活させる一種の医者フランケンシュタインであると自分自身を想像します。
今回は誰が生まれますか？ 次の3つのオプションのいずれかを選択します。
PS：筋肉-腱なしでは機能しません。 各筋肉に適切な量の腱を与えてください！