コードを書くことはできますが、うまく設計できません。助言がありますか？[閉まっている]

コードを少しずつ書くのは得意だと思いますが、私のデザインは本当にひどいものです。問題は、デザインをどのように改善し、さらに優れたデザイナーになるかです。

学校や大学は人々に数学的な問題解決の達人になる方法を教えるのに良い仕事をしていると思いますが、学校で作成されたほとんどのアプリケーションは一般的に約1000-2000行の長さであるという事実を認めましょうこれは、実際のソフトウェアの複雑さを反映していません-数十万から数百万行のコードです。

ここで、topcoder / project eulerのようなプロジェクトもあまり役に立たないと思います。それらは数学的な問題解決能力を研ぎ澄ますかもしれませんが、あなたはアカデミックプログラマーになるかもしれません。素敵できれいなものにもっと興味を持ち、ほとんどのアプリケーションプログラマが扱う日常的で毛むくじゃらのものにまったく興味がない人。

私の質問は、どのように設計スキルを向上させるのですか？つまり、数千行のコードに入る小規模/中規模のアプリケーションを設計する能力ですか？より良いhtmlエディターキット、またはgimpのようなグラフィックプログラムを構築するのに役立つデザインスキルをどのように学ぶことができますか？

何かに本当に上手になる唯一の方法は、試してみて、見事に失敗して、もう一度試して、以前よりも少しだけ失敗して、時間の経過とともに失敗の原因を認識して、潜在的な失敗の状況を後で管理できるようにすることです。これは、ソフトウェア開発のあらゆる側面を学習するのと同じように、お気に入りの一人称シューティングゲームで楽器を演奏したり、車を運転したり、深刻なPWN年齢を獲得することを学ぶのと同じです。

本当のショートカットはありませんが、経験を積んでいる間に問題が手に負えなくなるのを避けるためにできることがあります。

• 良いメンターを特定する。すでに会費を支払っている人とあなたの問題について話すことができることほど良いものはありません。ガイダンスは、迅速な学習を支援する優れた方法です。
• 読んで、もう少し読んで、あなたが読んでいたものを練習し、あなたのキャリアの生涯を通して繰り返します。私はこのようなことを20年以上続けていますが、それでも毎日新しいことを学んでいます。事前設計だけでなく、緊急設計、テスト、ベストプラクティス、プロセス、および方法論についても学びます。すべてが、デザインがどのように出現し、形をとるか、さらに重要なことには、それらが長期にわたってどのように持続するかに、さまざまな程度の影響を及ぼします。
• いじくり回す時間を見つけましょう。職場でスカンクワークプロジェクトに参加するか、自分の時間に練習してください。これは、新しい知識を実践し、そのようなことがどのように機能するかを確認することにより、読書と連動します。これはまた、あなたのメンターとの良い議論に役立つものです。
• 取得何か技術的に関与外あなたの職場の。これは、プロジェクトまたはフォーラムの可能性があります。物事の新鮮な視点を維持するために、あなたのすぐ近くの仲間の輪の外であなたの理論とアイデアをテストすることを可能にする何か。
• 我慢してください。獲得経験には時間がかかることを認識し、失敗した理由と場所を知るためにしばらく後戻りする必要があることを受け入れることを学びます。
• あなたのタスク、あなたの考え、あなたの失敗とあなたの成功の日記またはブログを保管してください。これは必ずしも必要ではありませんが、時間の経過とともにどのように成長し、スキルがどのように成長し、思考が変化したかを確認することは非常に有益であることがわかりました。私は数ヶ月ごとに自分の日記に戻り、4〜5年前に書いたものを見ます。それは私がその時間にどれだけ学んだかを発見する本当の目を見張るものです。また、時々物事を間違えたことを思い出させてくれます。改善に役立つ健康的なリマインダーです。

まあ、この種の質問には黄金のリンゴはありません。おそらく、これはすべてのコーダー自身が自分に合ったものを見つけるためのものだと思います。とにかく、ここに私の見解があります。

あなたは主題に関する本を読むことができました。素晴らしい本。素晴らしい本。しかし、これらの本が役立つのは、アプリケーションを構築して設計しようとして失敗した場合だけです。

私にとって、それはすべて経験です。新人として始めたとき、デザインの方法に関する本を読みました。私は当時の内容の多くを理解していませんでした。仕事を始めて自分でアプリケーションを設計しなければならなかったとき、非常に面倒なアプリケーションを作成しました。彼らは働いたが、維持するのは苦痛だった。それから私はそれらの本を再び読みました-そして今度はそれらをよりよく理解しました。

今、私は新しい間違いを犯し、古い間違いから学び続けています。

設計をやめて、コードのリファクタリングを学びます。継続的かつ積極的なリファクタリングによる漸進的な開発は、どのような先行設計よりもはるかにクリーンな最終製品をもたらします。

確かにパターンについて読んでください、しかし何よりもまずアンチパターンについて読んでください。アンチパターンを認識することは重要であり、なぜそうすべきなのかよりも、なぜこのような方法ですべきでないのかを理解するのは簡単です。

たとえば、http：//sourcemaking.com/antipatterns/software-development-antipatternsを参照してください。

要件が変更された場合に迅速に調整できるようにコードを記述します（実稼働環境では非常に一般的です）。

「もう1つ小さなハック」を追加することについては非常に懐疑的です。ここにもう1つ、そこにもう1つ、コードは保守不能になります。

値がオープン/クローズの原則を。

テストを記述します（TDDなど）。実際に実装する前であっても、設計を熟考する必要があります。

オープンソースプロジェクトのコードを参照します（つまり、適切なサイズのプロジェクト）。かつては、非常に多くのレベルの抽象化が見られることに驚いていました。今では、芸術のために芸術ではないことを理解しています。このようにした理由があります。

良い設計のために私が非常に重要だと思う原則の1つは、分解です。クラスが大きすぎる（たとえば、300〜400行のコード）場合、それを小さなクラスに分割します。メソッドが大きすぎる場合（たとえば、50行を超えるコード）、メソッドを分解します。プロジェクトに50を超えるクラスが含まれている場合は、それを分解します。

重要な点は、システムのサイズを推定し、いくつかの抽象化レイヤー（サブシステム、アプリケーション、プロジェクト、モジュール、クラス、メソッドなど）を構築することです。

難しいですが、私たちが実際に話しているのは、より良いコードを作成するのではなく抽象化する能力ですが、2つのことがあなたをより良くし、1つがあなたを幸せにします：

「良い」

A）できる限り最高のデザイナーを見つけて、プログラムをペアリング/デザインを一緒に行います。問題に対処する際に彼らが考えていることを説明するように依頼し、「それがちょうどいいと感じている」ことに落ち着かないで、掘り続けてください。そのプロセスは「メンタリング」パーティにも役立ちます

B）すべてを個々の俳優およびそれらの間の会話として想像してください。各アクターには単一の役割/責任があり、それらのグループは異なるシステムを処理します。その会話がうまくいき、各俳優が首尾一貫した、まとまりを感じるなら、あなたはあなたの道にいます。

そして「幸せ」

C）最善を尽くしても、まだうまくいかない場合は、一部の人ができないことを受け入れることに何の問題もありません。タイトで素晴らしいコードを書くことはできますが、設計や設計はできません。だから何？私はタフィーのために物理的なスポーツをすることができません、私は見栄えがよくなく、私の車の運転は平均より良くなることはありません。自分の得意なことを楽しんで活用しましょう。

私の個人的な経験では、他の人を読むコードは「インスピレーション」の良い源です。他の人のデザインを理解し、なぜ彼/彼女がそのように物事をするのかを自問することを意味しますか？

研究用の多くのオープンソースプロジェクトを見つけることができます。

とにかく練習が必要です。

恐れて生きるな

シンプルさを目指して

ユーザーの意見を聞く

たくさんのアイデアを試してください

何かを作成し、それを改善する

価値を高めるものに取り組み、そうでないものを捨てる

適切な質問をすることを学ぶ。多くの場合、問題を別の角度から見て、設計を改善します。特に、これは、手元の問題の解決に集中することから離れ、複数の関連する問題を解決するソリューションをさらに検討するのに役立ちます。