コードの匂いがするときはどうすればよいですか？

私は初心者プログラマーであり、自分のプロジェクトに取り組んでいるときは、自分のコードの設計が最善ではないという感覚を常に感じます。この感覚は嫌いです。物事を調べるのに時間を費やすことになりますが、その後、選択するデザインパターンや抽象クラスまたはインターフェイスを使用するタイミングなど、多くの詳細に簡単に圧倒されます。一度にすべてのことを少し学習しようとするのですか？

いくつかの提案：

1. 機能を個別のビルディングブロックに分離することにより、カプセル化を使用して複雑さを管理します。各ブロックが機能することを（ユニットテストを介して）証明し、その詳細を気にせずに使用できます。

2. ソフトウェアパターンを学び勉強します。ソフトウェアパターンは、よく知られた特定の一般的なタスクを実行するための実証済みの方法です。

3. データ構造を調べて理解します。 データ構造のタイプごとに適切な使用法とパフォーマンス特性を学習します。

4. プログラミング言語、その長所と短所、およびその機能を最適に使用する方法をよく理解してください。

このすべてを一度に知る必要はありませんが、時間をかけてすべてを研究する必要があります。

私のアドバイスは、心配するのをやめることです。

経験は最高の教師であり、コードを書かないと経験は得られません。また、不適切に設計されたコードは、設計されていない優れたデザインよりも優れています。

したがって、より多くのコードを記述してください。プロジェクトを終了します。コードが理想的ではないという感覚はおそらく正しいです。そして、おそらくこのコードには問題があるでしょう。あなたはこれらの問題を抱えているときに、それから、それは悪かった理由を正確にあなたが学びたいです。「物事を調べる」ことよりも、直接的な経験から多くのことを学びます。

また、この「コードのにおい」の感覚が消えることを期待しないでください。良くなるにつれて、いくつかの問題を修正しますが、新しい、より不明瞭/高度な問題に気づき始めます。

これは初心者プログラマーに共通の問題です。すべてが完璧でなければならないと考えて自分を麻痺させないでください。それがプロジェクトを決して終わらせない最も確実な方法です。開発者として学ぶための最も重要なスキルの1つは、完璧と十分の違いです。作成するすべてのシステムを改善できることを受け入れます。プロジェクトの仕上げに集中してください。終了したら、戻って改善することができます。結局のところ、バージョン2.0があるのです。

一度にすべてのことを少し学習しようとするのですか？

私は望みません。一方、あなたはずっと学び、改善するべきです。

本を読んだり、コースを受講したり、資格を取得したり、それに取り組んだりして、改善する必要があります。

私の最善のアドバイスは、Robert Harveyが提案したリストのような基礎に集中することです。ソフトウェア開発は複雑な怪物であり、特に優れたインターフェイス設計のトピックでは、リモートでの習得までに何年もかかります。ソフトウェア開発の多くの側面を最初に経験せずに評価することは本当に難しいです。コードのコメントと同じくらい基本的なものでさえ、評価することができます。初日から、よく文書化されたコードを書くように教えられます。良いコメントの価値を本当に評価する前に、私が数ヶ月前に書いたコードを理解しようとして本当に$$に少ししかならなかったことを認めます。同じことは、多くのプログラミング概念にも言えます。たとえば、データのカプセル化、低結合モジュール、鮮明なクリーンインターフェイス。

私が遭遇した最も貴重なリソースは、同僚です。あなたは悪いコードを書くつもりです。それを受け入れてください。あなたがプログラマーであることを定義するのは、時間の経過とともにより良いコードを書くことを確実にするためです。たとえば、私が最初に仕事を始めたとき、私の会社には正式なコードや設計レビューの手順はありませんでした。私は自分の仕事をより年上の同僚の批判にさらし、正直に言うと、私の最初の年の仕事のより良い部分のためのばかみたいに感じました。

ソフトウェア開発は継続的な学習体験です。たくさんの質問をし、コードをレビューし、より多くのシニアの人々が提供する提案の理由を理解し、より多くのシニア開発者が提供する提案の妥当性に疑問を持たないでください。最終的には、刺激因子または圧倒的な流行の感覚。記録のために...学習曲線は吸う。

• 最初：リファクタリング（まだ匂いはしますが、もう少し整理されます）
• 2番目：デザインパターンを使用して、リファクタリングされたピースをロジックに一致させることができるかどうかを確認します。
• 3番目：物事が良くなったら、最初と2番目のステップに費やした時間を思い出してください。このようにして、新しい機能を作成するときは、別のプロセスとしてではなく、それを行うときに考えます。

Martin Fowler 著のRefactoring：Improving The Design of Existing Codeの本をご覧ください。あなたが最初にすべきことはあるあなたのコードリファクタリング、コードの可読性を向上させ、それのmaintabilityを改善するための複雑さを軽減するために、。

コードをリファクタリングするときは、既にデザインパターン、カプセル化コードなどを使用しています。

これは、私がこのトピックについて読んだ中で最高の本の一つです。多くの便利なレシピを提供します。

優れたリソースはThe Pragmatic Programmerです。「壊れたウィンドウ」の章では、自分がどこにいるかを説明しています。短く簡潔な対応は、問題を解決することです。

デザインの修正を開始するとき、それが好きではないことを理解するのに役立ちます。「あちこちに行き渡る」や「なぜそこに行ったのか」といったあいまいな答えを思い付くのは簡単です。しかし、時間をかけて、使用した一般的なパターンがあるかどうかを確認してください。

• 優れた設計は、コードベース全体で少数の概念を再利用します（理想は1つの概念ですが、実際にはさらに2、3が必要になる場合があります）
• 優れた設計により、どこで問題を修正するかを簡単に把握できます（DRY原則、SRP原則）
• 優れた設計では、優れたエラー報告が得られます（上記の点に関連していますが、見過ごされがちな側面であるため、個別のアイテムとして呼び出されます）

どこに行きたいかがわかったら、そこにたどり着くために小さく簡単に元に戻せる手順を実行します（つまり、これがリファクタリングの目的です）。コードを改善するたびに、残りのコードへの影響を考慮してください。あなたは物事を良くしたり悪くしたりしましたか？これは少なくとも秩序を混乱に導く私のアプローチです。

既にプログラミングの経験がある場合は、きれいなコードを持ついくつかのオープンソースプロジェクトを勉強してみませんか？関連するリンクがあるSOからこの質問を調べることができます。

また、設計パターンは知っておく必要があります-考えてみてください。パターンを持つという考えは、ホイールを再発明したりバグのあるコードを書いたりすることなく、既知の問題を解決することです。

最後に、頭をクリアするためには、関数型プログラミングを必要とするようです。HaskellまたはOcamlを開始してください。

あなたが危険なモンスターではない場合、あなたはあなたのコードをレビューできるいわゆる友人を見つける必要があります。また、あなたが物事を作り直したり、他の人に見守られたりする場合、より良い方法でそれを行うのは良い印象です。

忘れないでください、プログラミングはコーディングの前に始まり、常にアイデアや計画を再確認してください。あなたの計画が悪い場合、それを捨てるのは楽しい行為です。悪い計画に基づいて大量のコード（およびその作成時間）を捨てるというフラストレーションをたった今保存しました。

私のアドバイスは、それぞれの匂いを真剣に受け止めて修正することです。このトピックに関する多くの優れた本があります（きれいなコードとGOOSが最高の私見です）。しかし、他の人やオンラインコミュニティ（メーリングリスト、グループ）で聞いたり議論したりするために、本は会議に行くだけではありません。ローカルxxug（dotnetug、jug、xpugなど）に参加するか、見つけた方が良いでしょう。

他のプログラマーと議論することが、私が本当に改善する唯一の方法です（幸運にも他の専任プログラマーと一緒に仕事をするのに十分でない限り）。