設計の選択肢が優れている理由を説明するにはどうすればよいですか？[閉まっている]

私がより良い開発者になったので、私の設計スキルの多くは、機械的分析よりも直感から来ていることがわかります。これは素晴らしい。これにより、コードを読んで、すばやく感じられるようになります。これにより、言語と抽象化の間でデザインをはるかに簡単に翻訳できます。そして、それは私がより速く物事を成し遂げることを可能にします。

欠点は、特定の設計が有利な理由をチームメイト（さらに悪いことに、経営陣）に説明するのが難しいことです。特に、ベストプラクティスの時代遅れのチームメイト。「この設計はテスト可能です！」または「継承よりも合成を優先する必要があります。」彼らの頭を真っ直ぐに行き、最後の10年のソフトウェアエンジニアリングの進歩に誰もが手がかりを与えようとする私のうさぎの穴に導かれます。

もちろん、練習すれば良くなりますが、その間に多くの無駄な時間や悪い設計が必要になります（後で修正するために無駄な時間がかかることになります）。利点が視聴者に完全に明らかではない場合、特定のデザインが優れている理由をよりよく説明するにはどうすればよいですか？

これはあなたの質問に直接答えないかもしれませんが、興味深い方向にあなたを導くかもしれません。

あなたがする必要があるのは、彼らにそれを説明するよりも、アイデアでそれらを売ることに関係していると思います。セールスとは、顧客の問題が何であるかを理解し、製品（または開発方法）が顧客にどのように役立つかを示すことです。各人には異なるニーズがあるため、ある人に利益をもたらし、興奮させるものは、別の人を冷たくする可能性があります。

CEOにとっては市場投入までの時間が重要であり、マネージャーにとってはより予測可能なスケジュールであり、プログラミング同僚にとってはコーディングの高速化（またはテスト/文書化/デバッグ/その他）が容易な場合があります。かもしれない...？

販売は自動的に行われるわけではありません。相手の視点を理解し、アイデアをHappy Place™にマッピングする方法を理解するために協力する必要があります。彼らがこの新しいものから個人的にどのように利益を得るかを知ったら、彼らはしばしば「どれくらいの費用がかかり、どれくらい早くそれを行うことができるのか？」と尋ねます。これらの魔法の言葉を聞くと、あなたはあなたの販売の仕事をうまくやったことがわかります。

私はあなたの質問に対する解決策を実際に持っていませんが、しばらく前に私はまったく同じジレンマに直面し、まったく同じ質問に答えようとしていました。

私は議論の片側に自分を見つけ、反対側に他の誰かを見つけるでしょう。私の体のすべての繊維が正しいデザインをXだと言っても、言葉を使ってそれを支持することはできませんでした。

さらに悪いことは、時々私はその点を認めて、他の人に自分のやり方で自分のデザインを私の顔に吹き飛ばすようにさせることです。そして、「うん、これは私が望んでいない理由の完璧な例そのようにそれをするために。もし私がこのコードを彼らに示すことができたなら、その時。」

まあ、私は本当に答えを見つけませんでしたが、数日前にリーンソフトウェア開発：アジャイルツールキットをめくっていました、私は答えが実際には存在しないことを示唆するかもしれない興味深い何かに出会いました。この本のあるセクションでは、他の分野、特に緊急時対応部門のリーダーと、それらのリーダーがどのように決定を下したかについて話していました。火事があったとき、または誰かがあなたを撃っているとき、それらのリーダーは座ってチームメイトと賛否両論することはありません。代わりに、意思決定を支援するためにトレーニングと経験を通じて開発された直感を使用します。私たちの職業にも同じことが当てはまります。ソフトウェア開発で非常に一般的な大量の未知数や変動に直面したときに、どうやって完全に論理的な決定を下すことができますか？著者は、すべての決定を正当化しようとするのではなく、開発者が本能を訓練して改善し、最終的に何をすべきかを「ただ知っている」ように奨励する必要があると主張します。

これらの議論を乗り越えるために私が見つけた唯一の方法は、私の仕事の証明された実績を築くことです。私のコードで行った設計上の決定が、保守、拡張、および信頼性がより高いコードになることを、チームの管理者や他の人に示すために。これを繰り返し行うと、人々はあなたに気付くでしょう。その時点で、あなたの意見は、あなたの本能にのみ基づいているかもしれませんが、今日よりもはるかに高い重みを持ちます。この戦略は、上司を含む私のチームの90％以上で機能しました。残念ながら、あなたは完全に頑固で、あなたの方法を見るのを拒否する1人か2人の人を見つけるかもしれません。その時点では、いくつかのオプションがあります。

1. あなたはランクを引き出そうとすることができます（私はこれらの行き止まりの議論にとても疲れていたので、私は私のボスに行き、ランクを要求することになりました）
2. 大半のチームがあなたをサポートするためにロビー活動を試みることができます。
3. プロジェクトに余裕がある場合（つまり、生産性の損失が大きすぎない場合）、悪い判断はあなたの意見では、他の人が議論に勝つようにします。次の2つのいずれかが発生します。
   • 場合によっては（できれば非常に小さな部分）、直感が間違っていて、何かを学ぶことになります。よかったね。
   • ほとんどの場合（再び...うまくいけば）、あなたと「悪い」デザインを提唱していた人は、なぜそれが悪いのかを正確に理解するでしょう。後知恵は常に20/20です。うまくいけば、これはその人への教訓になり、おそらくあなたはあなたが話していることを知っており、次回は彼らが彼らの主張を二度議論すると思うでしょう

さて、この答えはあなたが思うほどプログラミングに固有のものではありません。あなたは彼らが理解している事柄にそれを持ち帰らなければなりません。

継承を介した構成のようなものであれば、おそらくおそらく現在開発者の90％がベストプラクティスを検討していると言う必要があります（開発者の100％がほとんど何も同意しないという事実に部分的に基づいて）同意し、理由を喜んで説明します。

物議をかもしているもの、そして私に賛同する開発者の割合について、できる限り正直にしようとしています。

これは一般に、開発者よりも管理者の方がうまく機能します。開発者はおそらく、優れたデザインを本当に支持しているのか、どうやってそれを知っているのかを説明するうさぎの穴を掘り下げるでしょう。これには称賛に値するものがありますが、それはあなたが多くの時間を費やさなければならないことを意味します。良い面では、彼らはあなたが間違っていることをあなたに納得させるかもしれません。

設計がよりテスト可能であるようなものについて、よりテスト可能であることに同意しない場合、それは最初の例とほとんど同じです。よりテストしやすいことが望ましいと彼らが同意しない場合、あなたは彼らが理解するものにそれを持ち帰らなければなりません。これは管理である可能性が高く、長期的な開発コストの削減、QAの削減、プロセスの予測可能性の向上（繰り返しQAサイクルの長さを予測するのが難しいため）などについて話すことができます。

問題の一部は、たとえあなたが正解であったとしても（そしてもちろんそうではないかもしれませんが）物議をかもす何かについてチームに同意してもらうことがどれほど難しいかを過小評価していることだと思います。プログラミングは部分的に社会学的な演習であり、実際にそれらのウサギの穴のいくつかを実際に下る時間をスケジュールする必要がある場合があります。そのため、その時間を無駄に考えないでください。プロジェクトの成功に必要な時間だと考えてください。どうにかそれをスキップすることができれば、それは非常に簡単になりますが。

変化の唯一の声であることは決して簡単なことではありません。最初の課題は、通常、他の人をあなたと一緒に迎え入れることです（うまくいけば、あなたの会社には他の人よりも心を開いている人がいます）。他の数人の上級開発者/マネージャーの注目を集めて十字軍に加わることができれば、それらを組み合わせた声は無視するのが難しくなります。

人々に説明する良い方法は、彼らが積極的に関与しているプロジェクトで過去に犯した間違いの具体例を提供することです。修理する.."）。さらに良いことに、それらの「新しい」デザインのアイデアと原則を小規模/試行プロジェクトに適用し、最後にどれだけ成功したかを見せることができます。

社内の他の人の態度によっては、変化はすぐに起こるかもしれません。一部のマネージャーは、目の前に確固たる統計/証拠がない限り、完全に不動です。他のマネージャーは、最新の考え方に追いつくことに非常に熱心です。

誰に対処するかによって、異なる戦術を試す必要があるかもしれません。お金/時間/労力が節約され、品質が改善される可能性があることを提案することは、技術者ではない管理者の注意を引く良い方法です。また、簡単な自動テストの約束は、同じテストスプレッドシートを繰り返し実行するのに何日も費やすことができない多くの開発者にとって魅力的です。

観客次第！開発者として、良いコードと悪いコードの直観を開発し、「コードのにおい」、「ugいコード」、「美しいソリューション」などの漠然とした感情的な用語を使用します。これは、同じ考え方を持つ他の開発者と通信する場合にのみ機能します。技術者でないCEOに、コードをより美しくするためにx工数を費やすべきだと説明してみてください。

与えられた設計の改善は、いずれかのケースで行うことができる必要があります

• 会社のためにお金を節約する
• 会社のためにお金を稼ぐ

たとえば、単一責任の原則を遵守する場合はどうなりますか？各クラスに単一の責任がある場合、バグの特定と修正がはるかに簡単になり、機能と改善の追加が簡単になります。バグを修正して機能を追加する時間を節約=節約できます。