悪いコードをクライアントにデモンストレーションしますか？
クライアントから、別のコンサルタントが開発したASP.NET WebformsアプリケーションであるWebサイトの再設計を依頼されました。比較的単純な仕事のように見えましたが、コードを見ると、そうではないことは明らかです。
このアプリケーションはうまく書かれていませんでした。全然。 SQLインジェクション攻撃に対して非常に脆弱であり、ビジネスロジックがアプリケーション全体に広がっており、多くの重複があり、何もしないデッドエンドコードがあります。その上、窒息している例外をスローし続けるので、サイトはスムーズに動作しているように見えます。
私の仕事は単にHTMLとCSSを更新することですが、HTMLの多くはビジネスロジックで生成されており、整理するのは悪夢になります。再設計に関する私の見積もりは、クライアントが目指していたよりも長くなっています。彼らはなぜそんなに長いのか尋ねています。
このコードがどれほど悪いかをクライアントにどのように説明できますか？彼らの考えでは、アプリケーションは非常によく動作しており、再設計は迅速な1回限りのはずです。それは前のコンサルタントに対する私の言葉です。技術者ではないクライアントが理解できる単純で具体的な例をどのように提示できますか？
更新
すべての回答をありがとう。 SQLインジェクション攻撃のデモンストレーションは理にかなっており、これをテスト環境でデモします。これは、このアプリケーションの多くの問題の一部にすぎません。 htmlとcssの更新を行うために、他の部分（データレイヤーで生成されているhtmlなど）をより適切な方法で置き換える必要がある理由を説明する方法を探していました。クライアントと話すときにまとめる良い提案がたくさんあります。
非技術者はばかではありません（ほとんどの場合）。あなたはそれを十分に高いレベルに保てば、彼らは技術的な議論を理解することができます。シンプルであると思われるタスクを選び、そうでない理由を説明します。
この変更は、1つのファイルで1つのWordになると予想していました。変更する可能性が最も高いのはここにあるようですが、変更したところ、1か所しか機能せず、他の7か所を壊しました。 1つ修正するとさらに2か所壊れてドミノ効果が出たので、10分かかったはずの変更が2時間かかってしまいました。それはほんの一例です。そこには予想外の2時間のタスクがもっとたくさんあります。
コードの構造、スタイル、技術的な負債は、少なくとも最初は、クライアントがあなたを信頼するまで、一緒に暮らす必要があることです。
セキュリティの脆弱性は別の問題です。
個人的には、コードベースに重大な問題があることを明確にしながら、既存の構造とスタイルを使用して必要な作業に基づいて見積もりを行います。私はセキュリティへの影響を個別に挙げます。会議中に要点を理解するために、データベースをハックするデモを行います。
私が「私の」カードに5000ポンドを置いて、彼に彼のカードをチェックするように言ったとき、私はポイントカードシステムを持つ以前のクライアントとこれを行うことをとても喜びました。
これをクライアントに伝えて伝える方法に関するいくつかの素晴らしい提案。うまくいけば、彼らはあなたのために報います。
ここに主要な赤旗！
クライアントから、同意したもの（HTMLおよびCSS）以外の変更を行わないように求められた場合、私はこのプロジェクトを引き渡して入札を取り下げます。
すべての欠陥とセキュリティ問題の概要が書面でよく伝えられていても、潜在的な責任は私には納得できないほど大きいです。クライアントがハッキングや違反の後に法的措置を講じたり修正を要求したりしなかったとしても;あなたの名前と評判はまだ作品に付いています！
あなたが得るために立つよりもはるかに多く失うかもしれません。
説明し、おそらくdemonstrate欠陥
彼に対するあなたの言葉である場合、あなたが言うすべては、彼らに関する限り、熱風である可能性があります。 SQLインジェクションを介してアプリがどのように悪用されるかを彼らに示すと、突然あなたは信頼される人物になります。再交渉するためには信頼性が必要になります。そして、これはあなたにそれを与えるのに十分なゲームチェンジャーです。
前任者に対して慈善活動を行う
それは間違いがそこにないふりをすることを意味するのではありませんが、もしあなたが見下すことに遭遇すると、あなたは信頼性を失います。おそらく彼に疑いの利益を与えることを除いて、プログラマーについて一言は言わないでください。コーダーではなく、コードに集中してください。あなたが「善良な人」であるように彼らに感じさせることは、あなたに交渉のより多くの余裕を与えるでしょう。そして、「善良な人」は決して物事を意味するとは言いません。既存のセキュリティの誤り（SQLインジェクションの脆弱性など）をクライアントに説明するとき、次のようなことを言いたいと思います。
Webアプリケーションのセキュリティは急速に進化している分野です。今日でも人々が学ぶ多くの開発ツールとテクニックは、これらのエクスプロイトのほとんどが理解される前に進化しました。セキュリティ開発の先を行くためには、フィールドに非常に注意深く従い、場合によっては開発スタイル全体を変更する必要があります。ほとんどのプログラマはこれを行いません。
行きます。開発者について悪の言葉は話されていません。彼は単なる「ほとんどのプログラマー」であり、かなり良い会社にいることを意味します。そして、あなたはあなたがではない「ほとんどのプログラマー」であることを証明しました。お金。
新しい取り決めを交渉する
クライアントが自分のアプリが一般に悪用される可能性があることを理解したら、修正することを望みます。あなたはおそらく彼がそれを修正するように頼むつもりの人です。あなたはその仕事をしたいかもしれないし、そうでないかもしれないので、彼らと話す前に注意深く考えてください。
少なくとも、あなたは彼らがすでにあなたに与えた仕事を終えるためにより多くの時間を望んでいます。あなたは彼らがおそらくあなたの元の見積もりにあなたを保持しないであろう脆弱性のもので十分に油断してそれらを設定しました。しかし、クライアントがあなたが何であるかを知っていて、この取り決めの一部として修正するつもりがないことを確認してください。
通常、開発者（あなた）は最初からすべてをやり直すことを好みます。そして、このようなケースでは、それはオプションかもしれません。しかしそれでも、クライアントは新しいアプリが構築されるまでビジネスを継続できる何かを望んでいます。つまり、最初からやり直しても、おそらくまだ古いアプリを少し更新する必要があります。
最初は余談だと思ったので、コメントとしてこれを開始しましたが、実際にはそうではありません。
再設計する必要があると思われるすべてのこと、およびその理由（それらが変更しない変更するとどうなるか）、および問題の修正に関する見積もりを完全に文書化します。私はあなたがセキュリティリスクとして認識するものには特に細心の注意を払います。
anyコードに触れる前にこれを行い、クライアントにこのレポートのコピーがあることを確認します。しばらく時間がかかる場合がありますが、これらのセキュリティリスクの1つが実現した場合にも対処できます。文書を受け取ったという署名のあるものを入手できればさらに良いでしょう。
もちろん、継承された元のコードのソース管理を指定することはできますが、このドキュメントを指定して、より専門的な方法で「参照してください」と言った方がはるかに簡単です。
このドキュメントは、今後のディスカッションの出発点になる可能性があります。また、クライアントは、「適切な人」に一部またはすべての変更を行う許可を与えるために使用することもできます。
そうは言っても、クライアントがリスクを理解できたら、とにかく仕事をしたり、立ち去ったりするように言った場合は、ニヤリと耐えます。
クライアントがあなたのアプリケーションのメンテナンスを手伝ってくれることを忘れないでください。アプリケーションで見つけた問題を指摘するのは、専門家としてのあなたの仕事です。クライアントはおそらくこれらの問題が存在することを知らないので、彼らはそれらを認識させる必要があります。これらの問題を理解できる方法で説明し、どのように進めたいかを決めさせます。
実際の例を使用して、車の故障や修理が必要な洗濯機などの問題を説明します。ポイントは、彼らがすでに精通している例を使用することです。 SQLインジェクションを説明するために、私はそれが何であり、なぜそれが問題であるのかを単に示します。
最後に、取り組むよう求められているアプリケーションの成功を気にかけていることを伝えたいと思います。
私はクライアントが関連できる類推を使用するのが好きです。私が仕事に勝つために前もって置いた仕事の量は、クライアントが費やすつもりだった金額に依存します（100ドルは20,000ドルとはかなり異なります）。 「意図する」と言ったことに注意してください。求める価値が得られない場合でも、関係する価値の個人的な見積もりはあまり意味がありません。
あなたの状況では-お金にもよりますが-両側から1本の線が出る箱を描き、クライアントに次のように言います。見た目もきれいでシンプル」 「これは、ソフトウェアが内部でどのように見えるかを考えたもの」であり、ボックス内の2本の線を結ぶ3本目の線を描きます。
次に、最初と同じように、入力ラインと出力ラインを外側にして別のボックスを描きます。そして、今回は2本の線を接続するために、無作為にスパゲッティの乱雑な山を描きます。
最後に、「今、あなたに私に求めているのはこれです...」と言い、最初のボックス内に単純な形を描き、線に触れる小さな半円を描き、「それを行うには、私はdこれを行う必要があります...」と線の周りに竜巻のような渦巻き形状を描き、「これをすべて回避するには...」と続け、他のボックスのスパゲッティをポイントします。
私はそれがポイントを約2分の時間で帰宅させると思います。とにかく彼らがあなたにそれをやると主張するなら、他の人が上で述べたようにそれを文書化してください。
このコードがいかに悪いかをクライアントにどのように説明できますか？
おそらく、家の配管のようなアナロジーを使用して、時間の経過とともに、修正や改造が非常に気まぐれになり、1つのものを修正すると、修正が必要な他の何かに影響を及ぼし、壊れる可能性があり、知る方法がありません。これが発生するすべての場所。
これは前のコンサルタントに対する私の言葉です。技術者ではないクライアントが理解できる簡単で具体的な例を実際にどのように提示できますか？
その通りです、それは前のコンサルタントが彼らの頭の中で作成したどんなビジュアルに対してもWordです。私の提案は、あなたが求めていることを実行し、簡単で具体的な例を示すことです。これは再設計であるため、コンパイルされたコードで定義されたHTMLフラグメントが残りのHTMLページとともにどのように表示されるか、およびそれがページの残りの部分に影響を与えるか反映しないかを示します。おそらく、同じコンパイルされたコードが、いくつかの「ビジネス」ルールを適用した後にマークアップをレンダリングします。違いを見せる。
これは困難で非常に一般的な問題です。頑張ってください。
正直で率直である。
しかし、最も重要なのは、あなたの期待に応えられない仕事を引き受けないことです。ほとんどの人は、請負業者がクライアントを解雇できることを理解していませんが、仕事が価値よりも厄介である場合は可能であり、そうすべきです。
ここで私が使用した類推を示します（有効性については保証しませんが）。彼らのWebサイトが、何らかの方法で入力を受け入れる機械式印刷機のような物理的なマシンであると想像してください。
彼らはおそらく、Xを実行するコンポーネントとYを実行する別のコンポーネントを搭載しているマシンと考えています。実際には、ほとんど同じようなマシンです。それらのいくつかはもはや何もしません、それらのすべては他の人がすでに行っている機能を実行しようとします、そして前のコンサルタント以外の誰もこれまでまったく同じようなものを見たことはありません。
「post変数を解析してから、このコンポーネントをif-elsesのウサギの穴に送るこのギズモを参照してください。これらの1つだけではなく、すべてのページ（または何でも）に1つあります。入力をサニタイズし、一部はしない（またはすべてしない）ので、全部を読まないと、どちらがいいのかわかりません。」
まだ実際に言及されていない1つの点は、この場合、クライアントが本当に望んでいることを上回っているだけかもしれないということです。過剰達成は素晴らしいことであり、あなたに多くの仕事の満足を与えることができます。しかし、クライアントが気にせず、現在のパフォーマンスが「十分」であると考え、わずかな更新が必要なだけの場合は、コードベースのオーバーホールに多大な投資をするようにクライアントを説得することは不可能かもしれません。
その時点で、原則に立脚し、恥ずかしいコードの混乱に自分の名前を付けることを強制するような仕事を辞退するか、それとも、鼻をかざして、乗り込んで、仕事を終わらせることができるかを決める必要があるでしょう。いくつかのダクトテープで、あなたの支払いで外に出る。
ただし、ダクトテープジョブを続行する場合は、文書化、文書化、文書化し、できるだけ透明性を確保してください。あなたが望む最後の事柄は、クライアントに警告したアプリケーションの欠陥の結果である将来に問題が発生したと非難されることですが、クライアントがその時点で対処するのに十分重要ではないと決定しました。
SQLインジェクションのリスクに関する限り、他の人が言ったように、実際に本番環境で何も破壊することなく、リスクを示す方法でその危険性を示すことができるはずです。しかし、繰り返しになりますが、彼らがそれを見て、それを修正するためにあなたにお金を払うのを十分に気にしないなら、あなたはこの場合あなたの誠実な勤勉をしました。
私はここで悪魔の擁護者を演じます（@khromeが言っていることの一部に沿って：「あなたはyour人生を楽にするためにクライアントにお金を払っていません） "）。あなたが提示したケースは、一般的な方法でケースを説明したので、一方的すぎると述べさえします。新しいプロジェクトのほとんどの着信コンサルタントは、以前のプロジェクトに悪い光を当てます...私はあなたがここでやっていることを言っているわけではありませんが、例が見られるまで、私はあなたの言葉を単純に理解することはできません。
そうは言っても、私はあなたに問題を少しずつ解決しようとするつもりです：
- SQLインジェクション。 OK、それでプログラマーはパラメーター化されたクエリやストアドプロシージャの代わりに文字列連結を使用していたと思います。これは特にADO.NETで修正するのは非常に簡単です...私は個人的にクライアントにそれを言及しますが、それから大したことはあまり行いません。
- HTMLはビジネスロジックで生成されており、整理するには悪夢になります。 OK、おい、これはあなたが私に詳細を与えるものの一つです。 MVCを使用していない限り、これは起こりがちな傾向ですが、必ずしも悪いことではありません...ほとんどのプログラマが「goto悪いです。決して使用しないでください。」 gotoを使用しましたが、意味のあるところです！では、たまたま、ビジネスコードDLLと同じ名前空間を共有しているヘルパークラスを使用していないのでしょうか。繰り返しますが、分離するのはそれほど難しくありません。
- ビジネスロジックはアプリケーション全体に広がっており、重複が多く、何もしないデッドエンドコードがあります。。そして？クライアントはHTML/CSSを変更するように要求しています。なぜこれらの問題をまったく気にするのですか？
- 窒息している例外をスローし続けるので、サイトはスムーズに実行されているように見えます。繰り返しますが、非常にあいまいです。例外はすべてのアプリケーションで正常です。そのため、コードにtry/catch句があります。それらがUIで浮き上がってユーザーエクスペリエンスを台無しにしない限り（HTTP 500を不必要に表示するなど）、これもあなたが気にする必要があるものだとは思わない。
要するに、私はあなたに高い道を行くことを勧めます。それはあなたの時間の価値がないと思い、あなたのクライアントの費用でそれを書き直したいなら、仕事から離れてください。真剣に、最後に、クライアントはすべてのものを最小限の$$$で機能させるためにあなたの時間を支払います。
この分野での長年の経験の中で、私が遭遇した最高のプログラマーは、最小限のコードを記述してシステムを安定させることができるプログラマーだといつも言っていますではなく、全体を書き直します。
編集：私の答えは最も人気のあるものではないことはすでにわかっています（これはすでに期待していました）が、私は自分の応答を待機しています。これを編集して、ぎくしゃくさせないようにしました。 ;-)
プロジェクトに参加して最初に書き直すことを提案し、変更の小さなサブセットを実行し、それらを使用して、どれほど単純で安価であるかを説明するのはcouldでした。次に、よりクリーンな開発のコストの増加が、わずかなフォントサイドコストを考えると、メンテナンスコストの削減と長期的な開発の高速化につながる理由について、実証可能なケースがあります。
基本的に、あなたは彼らにあなた自身の人生を楽にするためにあなたにお金を払うように求めていることを忘れないでください、彼らの心の中で、YのコストでXの機能を実行できる '人'を見つける必要があり、プロジェクトの複雑さを拡大するだけで機会がなくなるかもしれませんあなたのために。書き直しの1か月が経過し、元の開発者と面会して、アプリ全体が、行われたすべての妥協点を完全に理解した開発者によって非常に契約されたウィンドウで記述されていることに気付いた場合、それは困難な道です。アプリが内部的には恐ろしいように見えても、外部的にはうまく機能している場合、あなたが言うように、これは事実である可能性が非常に高いです。多くの場合、コードベース内の技術的負債は、コードが開発されたリソースの制約の結果であり、チームを構築しておらず、代わりに物事を請け負っている場合...おそらくメンテナンスについては深刻ではありません。
私はただ言っているだけです