提案された設計は通常、同僚の設計よりも悪いです-どうすれば良くなりますか？[閉まっている]

私は数年プログラミングしており、問題の修正や中小規模のスクリプトの作成に関しては一般的には優れていますが、オブジェクト指向の方法で大規模なプログラムを設計することは一般的に得意ではありません。いくつかの質問

1. 最近、私と同じ年数の経験を持つ同僚と私は問題に取り組んでいた。私は彼よりも長い間問題に取り組んでいましたが、彼はより良い解決策を思いついたので、最終的には彼のデザインを使用します。これは本当に私に影響を与えました。私は彼のデザインが優れていると認めていますが、彼と同じくらい良いデザインを思いつきました。私も仕事を辞めることを考えています。理由は定かではありませんが、突然、プレッシャーを感じています。たとえば、後輩が私についてどう思うかなどです。普通ですか？それとも、これについて少し考えすぎていますか？

2. 私の仕事は、Pythonでのプログラミングです。ソースコードを読み込もうとしていますが、デザインスキルをどのように向上できると思いますか？勉強すべき良い本やソフトウェアはありますか？

教えてください あなたの助けに本当に感謝します。

これはあなたのスキルの非常に前向きなサインだと思います。チームで「より良い」デザインを思い付くのが難しい人にとって、他のデザインがより良い理由を完全に認識できないことは、はるかに一般的です。

あなたには2つの本当に素晴らしい（そして驚くほど珍しい）強みがあります：

• あなたは他の人に対してあなたのデザインを客観的に評価することができます
• あなたはあなたのデザインを最適にするための欲求と努力を持っています

あなたはまだ数年で、長い道のりを歩んでいますが、この態度であなたは間違いなくそこに着くでしょう、ただあきらめないでください。私たちは皆、このような精神的な後退に対処しています。頻繁に機会があれば、デザイン原則（デザインパターンとは異なります）をプラグインするのが好きで、これが便利な場所の完璧な例だと思います。それらを研究し、あなたのデザインにそれらを適用する練習をしてください。あなたはそれがこの点でさらに前進したことを知る前になります。

結局のところ、設計は難しいことを忘れないでください。私たちは毎日、複雑な高レベルの抽象化を扱っており、それらを薄い空気から作成し、うまく機能させ、同僚が簡単に使用できるようにすることは非常に難しい作業です。何年も練習が必要です。

2つのデザインを評価できず、実際に1つのデザインが他のデザインよりも好ましいと認識できない人が大勢いますが、良いデザインを作成する上でどれだけうまくいっていると思いますか？

編集：
「もう一つのヒント、原則を理解してそのアプリケーションを少し練習した後、ここで別の質問から別の宝石があり、さまざまな目的とルールを持つさまざまな言語を勉強することの価値について話していると思います：

理想的には、すべてのプログラマーが各クラスの言語を知っている必要があります。あなたは何を学ぶことができます：

1. 静的型付きOOPメインストリーム言語：Java、C＃（主にエンタープライズソフトウェアで使用）、C ++（システムプログラミングおよび複雑なデスクトップアプリケーション）
2. プロトタイプベースのOOP言語：Javascript（クライアント側のWebプログラミング）
3. 手続き型言語：C（組み込みソフトウェアおよびシステムプログラミング）
4. 関数型言語：Haskell、ML、またはLisp（関数型言語は高度に並列化されたソフトウェアに適しています）。

ロジックプログラミング言語（Prolog）は、おそらく業界ではそれほど有用ではなく、主にAIの研究に使用されています。

これは、ソリューションを設計しようとするときに思い浮かぶさまざまなアイデアを広げるのに役立ちます。

1. これは、複数の人が異なる品質のデザインを思い付くのは絶対に普通のことです。私は過去にソフトウェア設計の競争を判断するために招待されてきたので、私はこのことを直接目撃しました。
2. ソースコードの読み取りは低すぎて設計スキルの向上に役立ちません。コードは設計全体よりも低いレベルで複雑さに対処します。

ソフトウェアの設計を改善する最良の方法は、ソフトウェアを設計することです^*。それを行う1つの方法は、設計の競合を見ることです。TopCoderには、Javaおよび/またはC＃でのUML設計ドキュメントと実装を備えた100以上のコンポーネント設計のアーカイブがあります。好きな完成したコンポーネントを選択し、要件の仕様を読んで、要件を満たすために元の設計を考え出してください。問題について考えてクラス図をスケッチし、1、2時間過ごしてから、優勝したデザインを開いて、著者がしたことを読んでください。彼のデザインをあなたのものと比較し、違いを見つけて、あなたのデザインがより良いかどうか確かめてください。コンテストのスコアカードを確認して、審査員がデザインをどのように評価したかを確認してください。これにより、設計スキルを向上させる方法を決定するために必要なフィードバックが得られます。

仕事を辞めないでください。あなたよりも優れたスキルを持っている人と一緒に仕事をする方が良いでしょう。そうすれば、その人から学ぶことができます。

優れた設計を見て、なぜ優れているのかを判断してください。受け入れられた設計から学び、他の状況で同様の設計を適用できる方法について考えてください。設計よりも優れている理由がわかれば、次に設計を行うときにどのようなmistatkeを作らないかがわかります。他の開発者と話し、彼がどのように設計を思いついたのか尋ねてください。

設計スキルを向上させるための最善の方法は、設計を作成し、それを評価し、改善方法を決定する際に自分自身に冷酷になることです。次のような質問を自問してください：すべての側面で機能し、要件を満たしているか、保守可能であるか、これをどのようにテストできるか、パフォーマンスの問題を引き起こすか、要件をどの程度変更するか、設計はどれだけうまくいくか変化に対応できること。デザインパターンについて読んでから、デザインに適用してみてください。初期設計を思いついた後、容赦なくリファクタリングします。アプリケーションとともにデータベースを設計している場合、dbの正規化とパフォーマンスチューニングについて詳しく読んで、データベースを最も効果的かつ効率的に機能させる方法を学ぶと、データベース設計について多くを学ぶことができます。アプリケーションについては、設計を行う際にDRYおよびSOLIDの原則を考慮してください。アンチパターンについて読んで、回避すべきことを把握してください。

より良いデザインを認識することは重要な能力です。デザインを見ることに関する以前の提案のいくつかに従うとき、これを促進する必要があります。

他のデザインをどの基準でよりよく判断しましたか？シンプルでわかりやすかったですか？パフォーマンス上の利点はありましたか？それはより拡張可能でしたか？分解、抽象化、情報隠蔽、コンポーネントのモジュール性など、設計の判断に使用でき、すでに認識している多くの設計原則があります。

• 基準に名前を付け、理解し、拡張し、他のデザインを見るときにそれらを再利用するようにしてください。自分で物事を設計するときは、それらの基準を使用し、それに対して設計を意識的に測定するプロセスの一部にします。次に、設計が完全に修正されないか、設計が基準を満たさない場合は設計を破棄する準備をします。

次のソースのいくつかから、設計のさまざまな原則に関するアイデアを得ることができます。http : //www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdfウィキペディアのソフトウェア設計Google「ソフトウェア設計の原則」

• オブジェクト指向設計、機能設計、構造化分析設計など、ソフトウェア設計のさまざまなモデルを理解します。これらは、設計タスクにアプローチするためのまったく異なる考え方である場合があり、それぞれに優れた領域があります。これらをツールボックスのツールとして学びます。http://userpages.umbc.edu/~khoo/survey2.html

• 設計を実装から分離していることを確認し、適切な設計と思われるものを図式化して、言語と実装の詳細を高レベルの設計原則から分離してください。そして、「デザインの目」とコミュニケーション能力を開発します。

• 最後に、おそらく最も重要なことは、広く読むことは非常に優れたツールです-フラクタルからベイジアン分析、ファジーロジック、自然言語処理まで、興味深いアイデアがたくさんあります。Webを使用すると、娯楽や啓発のためだけにトピックを幅広く閲覧でき、有益になります。用語やアイデアに精通しているだけで、専門家になる必要はありません。

楽しんでください-少なくとも少し楽しんでいないなら、やらないでください！

さて、あなたはすでに最初の一歩を踏み出しました。学ぶべきことがあり、同僚の仕事が自分の仕事よりも優れていること、そして学び、改善したいことを認めます。

2番目のステップは分析です。彼の作品を見て、それが良いというだけではありません。なぜそれが良いのかを理解してください。彼がより良くした特定の詳細とポイントを探してください。

それを理解したら、その背後にある原則を抽出します。次のような質問をします。

• このデザインは私のデザインよりも優れていますか？
• この点はこの設計に固有のものですか、それとも将来他の設計に適用できる一般的な原則ですか？
• それが一般的な原則である場合、その制限は何ですか？とき、それは良いアイデアですないものをこの方法を行うには？（これは非常に重要です。不適切な場合でも、いくつかの有用なアイデアを黄金のハンマーとして扱うことができません。）

自分で結論を導き出す推論の連鎖を考え出すと、アイデアをよりよく内在化するだけでなく、同僚と話し合って物事を得ていることを確認できるので、自分で考えてみてください右。（結局、間違った推論をして間違った原則を内面化することはしたくないでしょう。）物事を理解できない場合は、同僚に助けを求めてください。プログラミングは謙虚さが尊重される傾向がある分野であり、多くのコーダーが誰かに何か新しいことを教える機会に飛びつくでしょう。これはおそらくStackOverflowがそんなに速くなった理由の大きな部分です。

また、（素晴らしい答えに加えて）「彼は私よりも優れたデザインを作成できる」以上のことがあると付け加えたいと思います。他の答えは、デザインでより良くなる方法に焦点を当てています。

私はあなたがあなたの同僚よりも良いことをできると信じています。放尿の試合や何かを作成するのではなく（Yの方が良いですか？

私の仕事には4人の開発者がいます。2人の主要な「プログラマー」が、私をほこりの中に残すものを作成できる場合があります。頭を回転させて、頭をそれらの作品に巻き付けようとします。

しかし、私はSQLとコマンドラインスクリプトの方が彼らよりもはるかに優れており、それらをほこりの中に残すものを自動化できます。

彼らは私よりも優れていますか？一部の地域では間違いなく。地獄、多くの地域で彼らはそうです-私は私の店のジュニア開発者であり、個々に彼らは私で長年の経験を持っています。これらの長年の経験にもかかわらず、私は彼らよりもいくつかの分野で優れています。

誰かがあなたよりもXの方が優れているという事実に集中するのはやめてください。その人は、それを試したり、考えたりすることなく、今後10年間練習した後でも、あなたをアウトデザインすることができるかもしれません。弱点の修正に取り組むべきではないということではありませんが、すべての強さには弱点があることを覚えておいてください。

あなたとあなたの同僚の両方の長所と短所に注目してください。

人生のあらゆる面で、特に「ほんの数年」の経験の後、あなたほど良くない人とあなたよりも優れた人を見つけるでしょう。

みんなから学ぶ必要があります。

気分を悪くしないでください。たぶんあなたの同僚は自然です。あなたは彼を心から祝福し、彼からできる限り学ぶべきです。

専門家があなたと学べる機会をjeしみなく取得しないでください。

1. 数年はそれほど多くありません。そして、より良いまたは最悪の高レベルのデザインビューを持つ人々がいるよりも。たとえば、私は一瞬のうちに低レベルのプログラム用の複雑なアルゴリズムを書くことができるが、より高いレベルの設計や凝集や依存関係などの概念を理解できない人々を知っています。ただし、これは事実上の状態ではありません。両方とも、より高いレベルの設計で良くなることができます（数冊の本を読んだり、家でいくつかのトリックを試してみてください）。また、プログラミングの他の分野であなたの仲間のプログラマがあまり良くないことを発見するかもしれません。また、経験と技術的知識の両方が同じレベルだと思う場合、これはBeanにランダムな状況があった可能性があります。次回は、より良いデザインのアイデアがあるかもしれません。また、仕事を辞める代わりに、この機会に同僚から学びましょう。次回は、一緒に設計を行い、彼の秘密、彼の考えをキャッチしてみてください。プログラミングは技術のようなもので、他の人がそれをやるのを見たり見たりすることで学べます。

2. デザインスキルは、ほとんどの場合、経験があり、いくつかの重要な本を読んだ後に生まれます。以下をお勧めします。

   • Robert C. Marting-アジャイルの原則、パターン、およびプラクティス（JavaのバージョンとC＃のバージョンの2つのバージョンがあります。どちらを選択しても構いません。アイデアと原則は、オブジェクト指向だけでなく、 - ソースコード）
   • よりも、ロバートC.マーティングには2つの興味深い本があります：Clean CodeとThe Clean Coder
   • Martinが彼の最初の本ですべてのモダンなデザインパターンを扱っているとしても、Gang of Fourによるオリジナルのデザインパターンの本を調べたいと思うでしょう。
   • 最後に、今日高く評価されている他の本があります：テストに導かれたオブジェクト指向ソフトウェアの成長、M。フェザーズによるリファクタリング（私が思う）、またはA.コックバーンによる効果的なユースケースの作成

これらの本はどれも魔法の弾丸ではありませんが、最初の2つの推奨事項を読むと、おそらくプログラミングに関するあなたの見解と認識が永遠に変わるでしょう。

それがあなたに届かないようにしてください。バグの修正と小さなプログラムの作成に長年の経験がある場合、それが得意です。あなたの同僚は、おそらくより大きなプロジェクトを設計した長年の経験を持っています。

基礎となるビットに精通していることは非常に便利ですが、設計を改善したい場合は、いくつかのプロジェクトを設計する必要があります。スキルが沈むまで繰り返します。

要するに、「経験年数」は必ずしも同等ではありません。あなたの年を何か価値のあるものにしてください。

「良くなる」とは、多くの場合、デザインまたはコードをより良い何か/誰かに対して測定し、違いを注意深く比較し、それらの違いから学習し、それに基づいて今後のデザインを改善しようとすることを意味します。あなたがより多くを学ぶ必要があることを見つけることについてあまりにもひどく感じると、この有益なプロセスが遅くなります。より良い比較を時々または常に提供できる人（または他のリソース）がない場所に移動すると、この機会を失い、より良い賭けのプロセスを学び、遅くすることができます。