ひどい設計上の決定に対処する方法
私はある会社のコンサルタントです。私より1歳年上で、私よりも3か月長く働いている別のコンサルタントと、フルタイムの開発者がいます。
フルタイムの開発者は素晴らしいです。私の懸念は、コンサルタントが絶対にひどい設計決定をしているのを見ていることです。たとえば、M：M関係は、結合テーブルを使用して関係を保持するのではなく、カンマ区切りの文字列としてデータベースに格納されます。
たとえば、CarとPropertyの2つのテーブルについて考えます。
車の記録：
- カムリ
- ボルボ
- メルセデス
プロパティレコード：
- スペアタイヤ
- 衛星ラジオ
- iPodサポート
- 標準
これを表すためにテーブルCarPropertiesを作成するのではなく、データが「1,3,7,13,19,25」のように見えるCarテーブルに「プロパティ」属性を作成しました。
この決定や他の人が私のコードの品質にどのように影響しているのか私は嫌いです。私はここに来てからこの2か月でこのデザインに3回頭をぶつけました。私の提案の方が優れている理由を尋ねられ、私たちのデータベースは、より高い正規形に変換することで冗長データを排除すると答えました。特にこの設計上の欠陥はエントリーレベルのカレッジプログラムで議論され推奨されていないことを説明しました。彼は私に一撃で応えて、これらのコンマ区切り値データベースプロパティはマスターを行うときに教えられると教えました（どちらも私たちにはありません）。 。言うまでもなく、彼は非常に動揺して、彼の仕事を批判したことをお詫び申し上げます。オフィスドラマを作成するコンサルタントになりたくないので、私はそうしました。
私たちのプロジェクトマネージャーは、できるだけ早く製品を提供することに焦点を当てており、非常に強い個性です-この時点で、彼がこれを行うために時間を費やすことを彼に示唆すると、彼は怒ります。
私たちの両方の契約が、次の2番目のプロジェクトに取り組むために延長される可能性が高いです。次のプロジェクトでそのようなひどい間違いが繰り返されないようにするために、システムとデータモデルの設計に支配的な影響を与えるにはどうすればよいですか？
ダイナミクスを垣間見る：
自分を測らなければ、私は強い個性になることができます。他のコンサルタントは強い性格ではなく、コミュニケーターが貧弱で、かなり頑固で、彼は他の誰よりも優れていると考えています。プロジェクトマネージャーは、明日の製品を昨日リリースすることに焦点を合わせた非常に強い性格です。フルタイムの開発者は非常にのんびりしていて、非常に効果的なコミュニケーターですが、ボートを揺さぶらないことを意味する場合、悪いデザインを受け入れる人です。
コードレビューなど、「時間」がかかるものは問題外です。PMがそのようなもので誰からも販売されることはありません。
私の経験から
私自身、20年以上、長い間請負業者であったとして、一般的に請負業者である場合、変更に影響を与えることはできません。座席に満ちて、言われたことをしている暖かい体があるはずです。マネージャーが明確に異なる何かを要求しない限り。
投資しないでください
hugeの間違いが見当たらない場合は、心配する必要はありません。 yourコードの貢献に、これがどのように悪いのかをコメントし、実際の時間でこれらの値に対する結合を実際にサポートするにはリファクタリングする必要があります。それを忘れてください。 thedailywtf.com になって、匿名であなたを有名にするかもしれません！
次の契約ポジションが現在のものよりもはるかに優れていることを確認する方法について考え始めてください！これで、次に面接するときに一緒に作業する人々の次のセットを評価し、将来これらのタイプの個性を検出するのに役立つ経験が得られました。
あなたは請負業者のネガティブな性格だけでなく、あなたのマネージャーのネガティブな性格も認識したいのです。彼をより美しく見せ、問題を回避しようとしている人に彼が「爆破」するつもりなら、あなたも彼らを避けることができるように将来彼のような人々を見つける方法を学ぶ必要があります。
謝罪してはいけません
今、他の請負業者は彼が正しいと彼の信念が正当であると感じるでしょう、彼は正しくない正しいです。
いずれかのbasicRelational Database Theoryの本は、この素朴な間違った解決策を2番目の章で、すぐにではなくても撃ち落とすでしょう。複数値フィールドは、誰か が何をしているかを理解していないという明確な兆候であり、論争する価値はありません。
気分を良くするために本当に何かしたい場合
この人との会話、それがなぜ間違っているのか、それが引き起こす問題と提案された解決策を文書化します。これをサラリーマンとあなたの上司に渡してください。期限がある場合は、今すぐ変更することを提案しないでください。ただし、規模が拡大することはなく、近い将来にマネージャーの見た目が悪くなることは間違いありません。そうすれば、次に進むと、少なくとも災害が発生するのを待っていることを彼らに通知したことを実感できます。
あなたの最善の策は、常勤の開発者で味方を開発することです。デザインの欠陥について彼に話し、彼が同意するかどうかを確認します。彼に現在のプロジェクトに固有の問題を見てもらうことができれば、次のプロジェクトのメソッドに進むように彼を説得できるかもしれません。
これは、付随的な大きな損害を与えることなく状況に影響を与える1つの方法です。
お役に立てれば！
まず、おそらく謝罪すべきではありません-それは彼に「より良い」と感じさせるだけです。批評は、（コーディングだけでなく）プロジェクトの本質的な部分です。次に、簡単なテストケースを作成して、テーブルを結合する適切な方法がどれだけ速いかを示し、コンマリストを使用して、iPodサポートに付属しているすべての車を選ぶ方法を尋ねます。
私がコンサルタントだったときの私のルールは、技術的な決定に同意しなかったとき、理由を（サポートする引数とともに）正確に伝えるONCE。彼らが私の提案を受け入れたくないのであれば、大したことはない、私はそれを維持しません。
これは私のうんざりです.....決定の正しさはさておき、あなたが嫌いな決定が行われました-私たち一人一人が私たちのキャリアでこれらの数百を扱います。あなたはそれを受け入れることを拒否し、人々の後ろを向いて、それを変えるために愚かなゲームをしているようです。この振る舞いは、自分と相手との間の仕事上の関係を損なうだけでなく、あなたが人々に勝てない戦争で味方するよう強制するとき、オフィス内の他のすべての関係を弱めます。あなたの行動は未熟で破壊的です。あなたの仕事（あなたがやることに対してあなたが支払うこと）は、プロジェクトの成功を確実にすることです。チームの関係を破壊すると、これは設計上の1つの誤った決定よりも1000倍速くなります。
では、成熟したコンサルタントはこれにどのように対処しますか。彼らはなぜ選ばれたデザインが劣っているのかについての議論を示し、より良い代替案を提案します。合理的な話し合いの後、最終決定が下され、全員に委ねられます。万が一に備えて、専門のコンサルタントは、彼らが働いているまさにその方法によって、これらすべての証拠を文書化します。
だからあなたの選択は何ですか：a）成長し、それについてプロになる、b）解雇される、またはc）辞任する。 a）を実行できない場合は、プロジェクトを破棄する前にc）を実行してください。
まず正解ですが、これは非常に貧弱な設計です。専門的な意見の相違について謝罪しないでください。専門家の意見の相違ではなく、あなたの側の悪い振る舞い（呼び出し名の叫びなど）についてのみ謝罪してください。彼は専門家の意見の違いを受け入れたくないという彼の振る舞いについて謝罪を負っています。
誰かが私にこれを言ったら、彼が最初に納得していなかったならば、彼は私に彼に私の議論を返す方法でした。 1つの列にIDがあり、別の列にコンマ区切りの番号付きリストがあり、番号がIDと説明に関連付けられている2番目のルックアップテーブルがある10,000,000レコードのクイックテストテーブルを実行します。次に、適切な正規化された構造を作成します。次に、正しいリレーショナルデザインで同じことを行います。適切なインデックスを作成することを忘れないでください。次に、不適切に設計された構造を使用して、test1の値（区切られたリストでは3に相当しますが、ルックアップテーブルへの結合を行う必要があります）を持つテーブル1のすべてのIDを見つけるコードを記述します。正規化された構造を使用してコードを記述します。コード、コードの記述にかかる時間、およびコードの実行にかかる時間を比較します。あなたと私はどちらも、どちらがより短くなり、書いてより良い時間をかけることができるかを知っています。 PM=に結果を示し、設計が悪いためにプロジェクトの開発が遅くなり、展開するとパフォーマンスが低下することを彼に証明します。それが彼を納得させない場合は、このプロジェクトは成功する可能性が0％であるため、できるだけ早くより良い契約を見つける必要があります。
考え-この状況が悪化した場合は、彼が間違っていると思うことをリストしたファイルをどこかに保管してください。あなたはおそらくそれを使う必要は決してないでしょうが、これがエスカレートするならばそれは重要になるかもしれません。
彼がそれを見つけられないことを確認してください！
岩と硬い場所の間に行き詰まっているようです。あなたは明らかに正しいことをしようとしていますが、同僚はあなたに同意していません。あなたが言ったことからの2つのオプションは、あなたがそれを正しくし、口を閉じたままにしたり、新しい仕事を探したりする方法を完全に記録することです。高い場所にいる人々は、時には対処しなければならない悪い決定をします。
設計が非常に悪く、両方がコンサルタントである場合、それを顧客の注意を引き、保守が高価なソフトウェアになる可能性があるという懸念を述べる必要があります。
その後、どこにお金を入れるかを決めるのは顧客次第です。彼らが悪いデザインで行くなら、まあ、少なくともあなたは彼らに言った、そしてそれから状況の下であなたができる最高の仕事をするのはプロとしてのあなたの義務です。
彼の解決策は明らかに悪い設計の選択です。データベースを操作したことがほとんどなかった私にとっても、それは明らかです。このソリューションによって課せられた制限をすぐに確認でき、付加価値を確認できません。
なぜ単純な証拠で彼を説得できないのか理解できません。私が言ったように、私はデータベースには興味がありませんが、データベースを設計しなければならなかった同僚と、最近あなたと同じような状況にありました。私は彼に両方の解決策の長所と短所を伝えることができ、私たちの状況では1つの解決策がより良いことを彼に納得させました。
これは本当にコミュニケーションの問題です。あなたは彼が攻撃されたと感じるような方法で彼と議論したか、または彼は非常に頑固で批判を受けることができません。
TBH彼のデザインは素晴らしいものではありませんが、それほど悪くはありません。すべてを正規化すると、追跡するのが困難になる大量のテーブルが作成される可能性があります。属性を文字列にシリアル化すると、オブジェクトの保存と読み込みが簡単になります。オブジェクトがxmlにシリアル化され、blob列に格納される同様のタイプのものが表示されます。
本当の問題は、あなたが違いにどう対処するかであり、それを乗り越える必要があります。あなたは彼が何かをした方法、不運を好きではありません。あなたはチームで最もジュニアな男のようですね。あなたが上司である10年間で、他の人がそれを気に入らなくても、ソリューションを押し通すことができます。
それまでは、あなたは最小の力と影響力しか持っていません。昇給や他の場所での仕事の取得方法など、もっと重要なことを心配して時間を費やしてください。
あなたは両方ともあなたが直接報告する誰かを持っている必要があります。それを彼にエスカレートし、彼/彼女がどのように進めたいかを見る時間です。開発者の才能に関する懸念を真剣に受け止める企業で働いていない場合は、他の場所に行ってください。