悪いコードをクライアントに示しますか？

クライアントから、別のコンサルタントが開発したASP.NET WebformsアプリケーションであるWebサイトの再設計を依頼されました。比較的簡単な仕事のように見えましたが、コードを見てみると、そうではないことは明らかです。

このアプリケーションはうまく書かれていません。まったく。SQLインジェクション攻撃に対して非常に脆弱であり、ビジネスロジックがアプリケーション全体に広がっており、多くの重複があり、デッドコードは何もしません。その上、それは窒息させられている例外をスローし続けるので、サイトはスムーズに実行されるように見えます。

私の仕事は単純にHTMLとCSSを更新することですが、HTMLの多くはビジネスロジックで生成されており、整理するのは悪夢です。再設計に関する私の見積もりは、クライアントが目指していたよりも長くなっています。彼らはなぜそんなに長いのか尋ねています。

このコードがどれほど悪いかをクライアントに説明するにはどうすればよいですか？彼らの頭の中では、アプリケーションは素晴らしい動きを見せており、再設計は一回限りのものにすべきです。前のコンサルタントに対する私の言葉です。非技術系クライアントが理解できる簡単で具体的な例を挙げるにはどうすればよいですか？

更新

すべての回答をありがとう。SQLインジェクション攻撃のデモは理にかなっており、これをテスト環境でデモします。これは、このアプリケーションの多くの問題のほんの一部です。私は、htmlとcssの更新を行うために、他の部分（データレイヤーで生成されるhtmlなど）をより良いプラクティスに置き換える必要がある理由を説明する方法を探していました。ここには多くの良い提案がありますが、クライアントと話をするときに一緒にまとめます。

非技術者はバカではありません（ほとんどの場合）。技術的な議論を十分に高レベルに保つと、彼らはそれを理解できます。シンプルにすべきだと思ったタスクを選び、そうではない理由を説明します。

この変更は、1つのファイルに1つの単語になると予想していました。変更する可能性が最も高い場所はここにあるように見えましたが、そこで変更すると、1つの場所でしか機能せず、他の7つの場所を壊しました。1つを修正すると、さらに2つの場所が壊れてドミノ効果が発生したため、10分かかっていたはずの変更が2時間かかることになりました。それはほんの一例です。そこにはさらに多くの予期しない2時間のタスクがあります。

コードの構造、スタイル、技術的負債は、少なくとも最初は、クライアントがあなたを信頼するまで、あなたが一緒に暮らす必要があることの1つです。

セキュリティの脆弱性は別の問題です。

個人的には、既存の構造とスタイルを使用して必要な作業に基づいて見積もりを行い、コードベースに重大な問題があることを明確にします。セキュリティへの影響を個別に提起します。データベースのハッキングのデモを行い、ミーティング中にポイントを家に持ち帰ります。

「私の」カードに£5000を入れて、彼のレジでカードをチェックしてもらうと、ロイヤルティギフトカードシステムを使用して以前のクライアントでこれを行うことができて、とても嬉しかったです。

これをクライアントに伝え、伝える方法についてのいくつかの素晴らしい提案。うまくいけば、彼らはあなたのために報います。

ここで大きな赤い旗！

クライアントが、同意したもの（HTMLおよびCSS）以外の変更を行わないように要求した場合、このプロジェクトを引き継ぎ、入札を取り消します。

すべての欠陥とセキュリティの問題について書かれた、よく伝えられた概要でさえ、潜在的な責任は私にとって満足するには大きすぎます。クライアントがハッキングや違反の後、法的措置を講じたり修正を要求したことがない場合でも、あなたの名前と評判はまだ作品に添付されています！

あなたが得るよりもはるかに多くを失う可能性があります。

欠陥を説明し、場合によっては実証して
ください。それが彼に対するあなたの言葉である場合、あなたが言うことはすべて、彼らが関係している限り、ただ熱風である可能性があります。SQLインジェクションを介してアプリがどのように悪用される可能性があるかを示すと、突然あなたは信頼される人になります。再交渉するには信頼性が必要になります。そして、これはあなたにそれを与えるのに十分なゲームチェンジャーです。

あなたの前任者に対して慈善的であること
それは間違いがそこにないふりを意味するわけではありませんが、あなたが見下すことに出くわすなら、あなたは信頼を失います。おそらく彼に疑いの利益を与えることを除いて、プログラマーについて言葉を言わないでください。コーダーではなくコードに注目してください。彼らをあなたが「良い人」だと感じさせることで、交渉の余裕が広がります。そして、「善良な人」は決して意地悪なことを言っていません。既存のセキュリティの誤り（SQLインジェクションの脆弱性など）をクライアントに説明するとき、私は次のようなことを言いたいです。

Webアプリケーションのセキュリティは急速に進化している分野です。今日でも人々が学ぶ開発ツールと技術の多くは、これらのエクスプロイトの大部分が十分に理解される前に進化しました。セキュリティ開発の一歩先を行くためには、この分野に非常に密接に従う必要があり、場合によっては開発スタイル全体を変更する必要さえあります。ほとんどのプログラマーはこれを行いません。

いくよ 開発者について話された悪の言葉ではありません。彼はただの「ほとんどのプログラマー」です。つまり、彼はかなり良い会社にいます。そして今、あなたはあなたがあなたにもう少しの信頼性とおそらく彼らがあなたにもっとお金を払う理由を与える「ほとんどのプログラマー」ではないことを実証しました。

新しい取り決めの交渉
クライアントは、自分のアプリが一般の人々に悪用される可能性があることを理解したら、その修正を希望します。あなたはおそらく彼がそれを修正するように頼む人です。あなたはその仕事を望むかもしれないし、望まないかもしれないので、彼らと話す前に注意深く考え直してください。

少なくとも、彼らがあなたに与えた仕事を終えるためにより多くの時間が欲しい。脆弱性に関する十分な警戒を怠ったので、おそらく元の推定値を守れないでしょう。しかし、クライアントがあなたが何であるかを知っており、この取り決めの一部として修正するつもりはないことを確認してください。

通常、開発者（あなた）はすべてをゼロからやり直すことを好みます。そして、このような場合には、それもオプションかもしれません。しかし、それでもクライアントは、新しいアプリが構築されるまでビジネスを継続できるものを望んでいます。これは、あなたがオーバー開始しているにもかかわらず、あなたはおそらくしていることを意味し、まだ古いアプリを少し更新しているつもり。

これはコメントとして始めました。最初は脇にあると思ったからですが、おそらくそうではないでしょう。

私は、あなたが再設計されるべきであると感じるすべてのもの、そしてその理由（彼らが変更を行わない場合に何が起こるか）、および問題の修正に関する推定を完全に文書化します。セキュリティリスクとみなされるものには特に細心の注意を払っています。

私は触れる前に、これを行うと任意のコードを、そして好ましくは、タイムスタンプのいくつかの種類で、あなたのクライアントは、この報告書のコピーを持っていることを確認してください。少し時間がかかるかもしれませんが、これらのセキュリティリスクのいずれかが実現した場合にも対応できます。文書を受け取ったという署名が付いていればさらにいいです。

もちろん、継承された元のコードのソース管理が発生した場合は、そのソース管理をポイントできますが、このドキュメントをポイントして、「プロフェッショナルですか？」

このドキュメントは、さらなる議論の出発点となる可能性があり、クライアントが変更の一部またはすべてを行う権限を「適切な人」に与えるために使用されることもあります。

そうは言っても、クライアントがリスクを理解したら、とにかく仕事をする、または立ち去るということを言ったら、にやにやしてそれを負担します。

クライアントは、アプリケーションのメンテナンスを支援するためにあなたに行くことを忘れないでください。アプリケーションで発見した問題を指摘するのは、プロフェッショナルとしてのあなたの仕事です。クライアントはこれらの問題が存在することを知らない可能性が高いため、それらを認識させる必要があります。これらの問題を理解できる方法で説明し、どのように進めたいかを決定できるようにします。

車の故障や修理が必要な洗濯機など、これらの問題を実例で示してください。ポイントすることは、彼らがすでによく知っている例を使用することです。SQLインジェクションを説明するために、それが何であり、なぜそれが問題なのかを簡単に示します。

最後に、作業を依頼されているアプリケーションの成功に関心があることを伝えたいと思います。

クライアントが関係できる類推を使用するのが好きです。私が仕事に勝つために前もって費やす仕事の量は、クライアントが使うつもりであったお金の量に依存するでしょう（100ドルは20,000ドルとは大きく異なります）。「意図」と言ったことに注意してください。求めているものが得られない場合、関与する価値の個人的な見積もりはあまり意味がありません。

あなたの状況では-お金にもよるが-両側から1本の線が出ているボックスを描いて、クライアントにこう言うかもしれない。きれいでシンプルに見えます」。「これは、ソフトウェアが内部でどのように見えると思うかです」そして、ボックス内の2本の線を接続する3本目の線を引きます。

次に、外側に入力線と出力線がある最初のボックスと同じように別のボックスを描画しますが、今回は「今、ボックス内でソフトウェアが実際にどのように見えるか」と言います。そして、今回は2本の線を接続するために、スパゲッティの乱雑なランダムな山を描きます。

最後に、「今、あなたが私に求めているのはこれです...」と言い、最初のボックスの中に、おそらく線に触れる小さな半円のような単純な形を描き、そして「しかしそれをするために、私は」 dこれを行う必要があります...」と、線の周りに竜巻のようなスパイラルの形を描いて続行します...「これをすべて回避するために...」と他のボックスのスパゲッティを指します。

私はそれが約2分後にポイントを家に追いやると思います。とにかくあなたがそれを行うと主張する場合は、他の人が上記で言及したようにそれを文書化します。

このコードがどれほど悪いかをクライアントに説明するにはどうすればよいですか？

おそらく、家で配管のようなアナロジーを使用して、時間の経過とともに、修正や改造の後、気まぐれで結合されて、あるものを修正すると、他の何かに影響を与え、場合によっては修正が必要なものに影響を与え、おそらくあなたが知る方法はありませんこれが発生するすべての場所。

前のコンサルタントに対する私の言葉ですが、非技術的なクライアントが理解できる簡単で具体的な例をどのように実際に与えることができますか？

あなたは正しい、それは前のコンサルタントが彼らの頭の中で作成した視覚的なものに対する言葉です。私の提案は、あなたが求めていることだけを行い、簡単で具体的な例を与えることです。これは再設計であるため、コンパイルされたコードで定義されたHTMLフラグメントがHTMLページの残りの部分とともにどのように表示されるか、および変更がページの残りの部分に影響するかどうかを示します。おそらく、同じコンパイル済みコードは、「ビジネス」ルールを適用した後にマークアップをレンダリングします。違いを示します。

これは難しく、非常に一般的な問題です。頑張ってください。

正直で、率直に。

しかし、最も重要なことは、あなたの期待に合わない仕事に就かないことです。ほとんどの人は、請負業者がクライアントを解雇できることに気付いていません。仕事が価値以上のトラブルである場合、彼らはそうすることができます。

ここに私が使った例えがあります（私はその有効性を保証しませんが）：彼らのウェブサイトが何らかの形で入力を受け入れる機械印刷機のような物理的なマシンであると想像してください。

彼らはおそらく、マシンがXを実行するコンポーネントとYを実行するコンポーネントを搭載していると考えています。実際には、ほぼ20台のマシンに類似しています。それらのいくつかはもはや何もしません。それらはすべて他の人がすでに行っている機能を実行しようとします。以前のコンサルタント以外は以前にそれらとまったく同じものを見たことはありません。

「ポスト変数を解析してこのコンポーネントをif-elsのうさぎの穴に送信するこのギズモを参照してください。これらの1つだけではなく、すべてのページ（または何でも）に1つあります。入力をサニタイズしますが、一部はしない（またはすべてしない）ので、すべてを読んでいないと、どれがわからないのかわかりません。」

まだまだ言及されていない点の1つは、この場合、クライアントが本当に望んでいることを単純に踏み越えている可能性があるということです。過剰達成は素晴らしいことであり、多くの仕事に満足を与えることができます。しかし、クライアントが単に気にせず、現在のパフォーマンスが「十分」であり、いくつかのマイナーな更新を望んでいるだけなら、コードベースをオーバーホールするためにあなたに大きな投資をするよう説得することは不可能かもしれません。

その時点で、恥ずかしいコードの混乱に自分の良い名前を付けざるを得ないような原則に基づいて仕事をすることを拒否するか、鼻を握って、仕事を終わらせるかを決める必要があるでしょう。ダクトテープを使って、支払いを済ませましょう。

ただし、ダクトテープジョブを続行する場合は、文書化、文書化、文書化を行い、可能な限り透明にするようにしてください。あなたが望む最後のことは、あなたがクライアントに警告したアプリケーションの欠陥の結果であるが、クライアントがその時に対処するのに十分重要ではないと決定した結果、将来何かが悪いと非難されることです。

SQLインジェクションのリスクに関しては、他の人が言っているように、実際に本番環境で破壊的なことをすることなく、リスクを示す方法でその危険性を示すことができるはずです。しかし、繰り返しますが、彼らがそれを見て、それを修正するためにあなたにお金を払うほど気にしないなら、あなたはこのケースであなたの誠実な勤勉をしました。

これは、プロジェクトに来て、書き換え最初のものを提案し、変更のいくつかの小さなサブセットを実行し、それがどのくらい単純で安価説明するために、それらを使用するようにnoobのタレだ可能性がありました。その後、クリーナー開発のコストの増加が、フォント側のコストがわずかであるにもかかわらず、メンテナンスコストの削減と長期的な開発の高速化につながる理由を実証できます。

基本的に、あなたが彼らにあなた自身の生活を楽にするためにあなたに支払うことを求めていることを忘れないでください、彼らの心の中で、YのコストでX機能し、プロジェクトの複雑さを拡大することができる「男」を見つける必要があるだけですあなたのために。書き直しを始めてから1か月が経ち、作成されたすべての妥協点を完全に理解している開発者がアプリ全体を非常に縮小されたウィンドウで記述したことを認識するためだけに元の開発者と会うのは難しい道です。あなたが言うように、アプリが内部的に恐ろしいように見えるが、外部的にはうまく機能している場合、これは事実である可能性が非常に高いです。多くの場合、コードベース内の技術的負債は、コードが開発されたリソースの制約の結果であり、チームを構築しておらず、代わりに契約を結んでいる場合...

私は言っているだけです

私はここで悪魔の擁護者を演じます（@khromeが言っていることの線に沿って：「あなたはあなたの人生を楽にするためにクライアントにお金を払っていない」）。あなたが一般的な方法でケースを説明したので、私はあなたが提示したケースがあまりにも一方的であると述べさえするまで行きます。新しいプロジェクトにやってくるコンサルタントのほとんどは、前のプロジェクトに悪い光を当てるでしょう...私はあなたがここでやっていることを言っているわけではありませんが、例を見るまで、私はあなたの言葉を単純に受け入れることはできません。

そうは言っても、私はあなたへの問題にポイントごとに対処しようとしています。

• SQLインジェクション。プログラマーはパラメーター化されたクエリやストアドプロシージャの代わりに文字列の連結を使用していたと思います。これは、特にADO.NETで修正するのは非常に簡単です...私は個人的にクライアントに言及しますが、大したことはしません。
• HTMLはビジネスロジックで生成されており、整理するのは悪夢です。わかりました、これはあなたが私に詳細を与えるそれらの1つです。MVCを使用しているのでなければ、これは起こる傾向です...しかし、それは必ずしも悪いことではありません...それは、ほとんどのプログラマーが「gotoは悪い、それを決して使用しない」と言うものの1つですが、あなたは何を知っていますか？私はgotoを意味のある場所で使用しました！だから、彼らはビジネスコードDLLと同じ名前空間を共有しているヘルパークラスを使用していないと確信していますか？繰り返しますが、分離するのはそれほど難しくありません。
• ビジネスロジックはアプリケーション全体に広がっており、多くの重複があり、何もしないデッドエンドコードがあります。。そして？クライアントは、HTML / CSSを変更するよう求めているだけです。なぜこれらの問題に関心があるのですか？
• 窒息している例外をスローし続けるため、サイトはスムーズに実行されているように見えます。繰り返しますが、非常にあいまいです。例外はどのアプリケーションでも正常です。そのため、コードにtry / catch句があります。UIでバブルアップしてユーザーエクスペリエンス（HTTP 500を不必要に表示するなど）を台無しにしない限り、これもあなたが気にするべきことだとは思いません。

要するに、私はあなたに高速道路を取ることをお勧めします。あなたの時間の価値がないと思い、あなたのクライアントを犠牲にしてそれを書き直したいなら、仕事から離れてください。真剣に、最後に、クライアントは、$$$の最小量で全体を動作させるためにあなたの時間を支払います。

この分野での長年の経験の中で、私が出会った最高のプログラマーは、全体を書き直すのではなく、最小限のコードを書くことでシステムを安定させることができるプログラマーだといつも言います。

編集：私はすでに私の答えが最も人気のあるものではないことを見てきました（私はすでにこれを期待していました）が、私は自分の回答を待っています。私はこれを編集して、音を抑えます。;-)

確かに、アプリケーションのSQLインジェクション攻撃やその他の機能上の欠陥が優先されましたが、悪いコードの品質とプラクティスを「実証」することもできます。コードメトリックツールを使用すると、コードがどれほど悪いかを明確に示し、将来の変更やバグ修正のためにどれだけのコストがかかるかを彼に示すことができます。私は.net環境に精通していませんが、いくつかの選択肢があります。