onclick イベントの背後にコード (ビジネス ロジック) を記述することが悪い習慣であり、保守不能なコードにつながる理由を、非技術者にどのように説明しますか?
編集済み: リファクタリングが必要な理由と、一部のコードがコード レビューに合格していない理由を管理者に説明する必要があります。管理職の一部の人々にとって、これはより多くの資金を意味するだけです。私がこの例を思いついたのは、議論のある時点で誰かが言ったからです: ..コードをボタンの後ろに置いて、モデルビューコントローラーの誇大広告をすべて忘れてください。タスクをより速く完了できます。
これは私がそれを説明する方法です：
onlclick イベントの背後にあるコードを作成することと、階層化または階層化されたアプリケーションを作成することの違いは、中世の町と近代的な都市の違いのようなものです。
中世の町では、誰もが畑を耕し、衣服を縫い、家を建て、子供たちに自分の能力を最大限に発揮させるように教育します。仕事をうまくこなすことに本当に特化した人は誰もいません。生き残るために必要なすべての仕事をしなければなりません。 . onclick イベントの背後にあるコードを記述するとは、このようなものです。コードは、すべてを実行し、UI インタラクションを処理し、ビジネス検証を行い、データベース アクセスを処理する必要があり、これがすべてのイベントに対して繰り返されます。
近代的な都市で大規模に農業を営み、それを専門とする農家がいる。経験と専門性が高いため、誰にとってもより良い服を縫う仕立て屋がいる。建設業者がいる。学校で子供たちに教え、より良い仕事をすることができる教師がいる。彼らはそれをする時間がもっとあるからです。これは、階層化されたアプリケーションを作成する方法です。UI 層は、ユーザー リクエストの処理とユーザー インターフェイスの更新のみを担当します。したがって、余分なコードの負担がないため、変更、置換、または拡張がより簡単になります。ビジネス層は、ビジネス ロジックを担当します。すべてのロジックは一元化され、再利用可能であり、ビジネス ロジック コードはよりコンパクトでクリーンであり、データ アクセス層はデータベースの対話を処理し、複数の種類のデータベースと対話する可能性があることを専門としています。
onclick イベントの後ろにコードを書くことはプログラミングの初歩的なスタイルであり、最も効率的なスタイルではなく、長い目で見れば最良の結果が得られません。優れたコーディング プラクティスを採用した適切な階層型設計を使用することで、保守と拡張が容易になり、一貫性が向上します (UI、インタラクション、エラー レポート、ワークフローなどに関して)。
ドアベルをリリースブザーに直接接続しないためです。
技術者以外の人がこれを知る必要があるのはなぜですか？「コードスタイル」は実際には技術的な問題であるため、その背後にあるいくつかの技術を説明せずに説明することはできません。
おそらく私が考えることができる最も簡単な説明（しかし、これはそれが悪い実践であるというすべての理由を網羅しているわけではなく、私が信じていることが最も一般的な理由です）：
ソフトウェアを作成するときは、可能な限り保守しやすくするように努めます。これは、変化するユーザー/クライアント/管理要件に合わせてアプリケーションをすばやく調整できることを意味します。onClickイベントの背後にあるコードは、GUI要件が変更されるたびに変更され、ビジネスロジックコードは、ビジネス要件が変更されるたびに変更されます。一方を他方から独立させることにより、これらのいずれかが変更されたときに行う作業が少なくなります。さらに、ビジネスロジックを更新するときは、GUIとの関係を気にする必要はありません。また、GUIを更新するときは、ビジネスロジックが実際にどのように機能するかを気にする必要はありません。
もう1つの主な理由は、再利用性です。すべてのボタンを備えたGUIは、実際には、基になるデータ/そのデータへのインターフェイスの単なる「ビュー」です。同じ情報にアクセス/変更する方法はいくつかあるかもしれませんが、ビジネスロジックを複製するのは冗長です。これにより、ビジネスロジックが変更された場合にも、複数の場所で変更する必要があるため、複雑さが増します。
写真と物語で:)
あまりにも気難しいことではありませんが、ビジネス機能の単純な部分があるホワイトボード上にシナリオを構築します（ユーザーパスワードを変更します）。それがどのように見えるかをグラフィカルに示します。次に、2つのフォームでユーザーのパスワード（adminとuser）を変更する必要があるように展開します。ダブルコード！DRYについて説明します。パスワードの複雑さのルールを変更すると、二重の修正が必要になります。ボックスをリファクタリングして、コードを同じプロジェクトの共通領域に移動します。
次に、別のアプリが同じことを行う必要がある場合に、もう一度展開します。これで、クラスライブラリが改善されました。複雑さの増加と保守性および再利用について正直に話します。
すすぎ、沈むまで繰り返します。
経済
一般的なソフトウェアアプリケーションのライフサイクルコスト全体の3/4はメンテナンスです。前もって1/4の部分をすくい取ると、3/4がロードされます。
開発のスキムは十分で、3/4は19/20になります。それを適切に行うと、$100,000のプロジェクトの費用はその存続期間全体で$400,000になります。TLCを前もってスキップすると、今なら$ 20,000節約できますが、プロジェクトのコストはその存続期間全体で$200万になります。
CFOが会議に参加している場合は、次の行に沿ってコメントをドロップできます。
「しかし、心配しないでください。余分な150万ドルは他の誰かの予算から出てくるので、ボーナスに影響を与えることはありません。」
混乱を放置することのもう1つの隠れたコストは、ビットの腐敗によってアプリケーションの変更が大幅に遅くなり、月末の終わりの真っ只中にいるまで誰も気付かないバグが検出されないリスクが高まることです。
私は他の人と同じように尋ねなければなりません-なぜですか?
技術者ではない人にとって重要なのは、ボタンをクリックしたときに目的の動作が発生することです。彼らの観点からすると、あなたはクリックイベントにコーディングしています。
しかし、それが本当に問題である場合は、非技術者が関心を持っていることに注目してください - バグ。彼らは、コードをエレガントにしたり、素敵なデザイン パターンを持ったりすることには関心がありません。物事が機能するかどうかがすべてです。
次のように言います。
システムにプログラムする必要があるビジネス ルールは、レポート、ボタン、検索など、さまざまな場所で再利用する必要がある場合があります。ソフトウェアパッケージ。今はここでしか必要ないと思うかもしれませんが、経験上、ほとんどの場合、ビジネス ルールは複数の場所で使用する必要があることが証明されており、常に再利用されると想定するのが最善です。
ビジネス ルールをボタンの背後に直接置くと、そのロジックの再利用は、不可能ではないにしても困難になる可能性があります。次に、システムに同じロジックを複数回配置する必要があり、ミスが発生する可能性が高くなります。ロジックを 1 か所で修正できたとしても、別の場所でまだ壊れている可能性があります。
代わりに、ビジネス ルールを取得して中央の場所に配置し、必要な場所で再利用できるようにしています。次に、1 か所のバグ修正はすべての場所で修正されたバグであり、ソフトウェアの問題は少なくなります。
類推は、Web ページ上のリンクです。Web ページから別の Web ページにすべてのテキストをコピーする代わりに、リンクを作成するだけです。その後、常に最新の情報を入手できます。
ただ覚えておいてください - 非技術者は実用的です - 彼らがすぐに見たり使用したりできるものがすべてです.
マネージャーに技術的負債について教えてください(また、こちら)
リファクタリングや技術的負債の支払いがたまに必要であるという一般原則をマネージャーに納得させるべきだと思います。料理人がおいしい料理を作るために時々キッチンを掃除しなければならないのと同じように、新しい機能を実装する前に時々コードをクリーンアップする必要があります。
マネージャーがこの一般原則に同意しない場合、大きな問題になります。彼らが同意する場合、彼らはあなたを細かく管理するのではなく、どの種類のリファクタリングが最も優先されるかについてあなたの技術的専門知識を信頼すべきだと思います.
ConcernedOfTunbridgeW は、経営陣が何を聞きたいかという観点から、それをうまく説明しています。要点は、現在問題がある場合、それはおそらくコード ロジックの冗長性が原因であるということです。あなたがやりたいリファクタリングはそれを排除します。長期的にはもう少し費用がかかりますが、長期的なメンテナンスでお金を節約できます.
少なくともそれらの用語では、技術者以外の人にこれを説明することに成功することはありません。それはポイントの技術的すぎます。
あなたが少し一般化して、おそらく懸念の分離のようなものを説明しようとすると（それらの用語ではない）、あなたはもう少し運が良いかもしれません
これは、実際には、ビジネス層（物事の処理方法）とプレゼンテーション層（物事の表示方法）を分離することを意味します。
変更の割合と2つを変更する理由は、一般的に非常に異なります。（リグレッションの）リスクを軽減する方法で、ビジネスニーズの変化にできるだけ簡単に対応して、それらを変更するのに十分な柔軟性が必要です。
通常、onclick イベントの背後にコードを配置しない理由は、コードを複製することが多く、これらの種類の onclick イベントすべてで同じルーチンを呼び出したいからです。