独自のフレームワークを作成するか、既存のフレームワークを使用しますか？
私はこれと同様の質問があることを知っており、それらのほとんどを読みました。これらの質問に対する答えのほとんどは、フレームワークの「費用対効果」と「時間節約」の側面について語っています。これは、フレームワークの使用を支持する大きな理由です。
私はかなり新しい.NET開発者であり、WPF、MVVM、階層化アーキテクチャ設計、依存関係の注入、ロギング、データベースアクセス、テスト駆動型開発、その他多くの異なるテクノロジー/テクニックなどを学ぼうとしています。
そのようなトピックに関して私が見つけるリソースのほとんどは、与えられたテクノロジー/テクニックを使用する必要がある理由を「示す」ための非常にシンプルな例から始まります。それは正直にそのシンプルな例ではかなり問題ないように見えますが、これらのテクノロジー/テクニックが役立つ実際の問題に対処しなかった人にとっては意味がありません。
特定のテクノロジー/テクニックが本当に何を解決するのか不思議に思う簡単な例の後、彼らは通常続けて、「ねえ、あなたは何を知っている、そのためのフレームワークがある...、それを残りの例のために使ってみましょう。 」依存性注入？ Ninjectを使用するだけです。偽物をしたいですか？ C'monはMoqを使用します。 MVVM？冗談だろ？ MVVM Light Toolkitを使用してください！
本当に素晴らしいです。これらのツールはすべて、きっとすべての開発者の生活を楽にします。しかし、私の問題は、
- 私はTDDを使用しようとしていますが、TDDなしで開発しているときに人々が経験した問題を一度も経験したことがないので、結局そのような手法が思い付きました。私は背後にある概念を理解しています。理論的にはなぜそれが作成されたのかはわかりますが、実際にはTDDの恩恵を受けるコードを見るのに十分な経験がありません。あまり見たことがないので。
- 巨大なアプリケーションを開発して問題を切り離す必要がなく、「まあ、それはばかげています。次回はこれほど多くの問題が発生しないようにするためのテクニックを見つける必要があります。」 「依存性注入」について知りました。これまでに開発したすべての小さなものは、依存関係の注入を必要とせずに問題なく動作しました。
- 私は、WPFアプリケーションを記述したことがないので、物事がより簡単になり、プレゼンテーションレイヤーが分離され、データバインディングが必要になると感じました。地獄、私はWPFアプリケーションを1つも作成していません。
これらすべてのことから、これらのツールを作成しようとする現実の状況を直接体験することなく、これらすべてのツールを使用するように思えます。
しかし同時に、MVVMまたは優れたレイヤードデザインを使用せずにWPFで巨大なビジネスアプリケーションを作成し、過去に経験したすべての問題を体験して、これらのすべての新しいテクノロジー/テクニックを評価することはできません。何かを開発し、さらに前進し、機能するものをリリースする人々がいるからです。学ぶためにそこにあるすべてを学ぼうとすることに夢中になっているので、私は取り残されます。さらに、これらのことは、最初に自分で問題を経験せずに学ぶのは簡単ではありません。
しかし、同時に、私は新しい会社で働き始めるという悪夢があり、人々は「自分のMVVMフレームワークをコーディングできないのですか？常にPrismを使用する必要があるのですか？Hahahahaha！」そして彼らは輪になって私を指さしながら笑い回ります。
私はあまりプログラマーではないようです。自分でフレームワークを作成するのに必要なものがないように感じます。私は、他の「より良い」人々によって作成されたものだけを組み合わせることができるような気がします。
世界中の経験豊富な人々にお願いしたいのですが、あなたのキャリアを通してどのような戦略を使用しましたか？常に既存のフレームワークを使用していますか？それらのフレームワークが存在する理由を学ぶためにペットプロジェクトを作成しますか？
簡単に言えば、フレームワークの使用と独自のフレームワークの作成の間の細い線を構成するものは何ですか？さらに重要なのは、テクノロジー/テクニックを使用する場合に、実際に発生する問題を確認せずに自動的に発生する知識のギャップをどのように埋めるかです。
私はかなり新しい.NET開発者であり、WPF、MVVM、階層化アーキテクチャ設計、依存関係の注入、ロギング、データベースアクセス、テスト駆動型開発、その他多くの異なるテクノロジー/テクニックなどを学ぼうとしています。
私は何かをすばやく学ぶ方法について素晴らしい話を一度見ました（すみません、それを見つけることができません）：
- 20から80の規則に従います。使用例の80％をカバーするために必要な20％だけを学習します。詳細に行き詰まらないでください。基本を理解し、壁にぶつかるまで一緒に作業します。そして、あなたはおそらくいつか壁にぶつかるでしょう。しかし、あなたはそれまでに多くの地面をカバーしているでしょう。ツールをほとんど使用せずにほとんどのユースケースをカバーする方法がない場合、それは仕事にとって間違ったツールであり、可能性があれば、より良いツールがあります。
- 一度に多くのことを学ばないでください。あなたは今、あなたが良いと思うどんなツールも必要としないと言います。それで大丈夫です。次のステップは、一度にすべてを試すことではありません。一つを選ぶ。目前の作業に最も役立つと思われるもの。それを適用します。それを理解したら、再帰的に進みます。
しかし、同時に、私は新しい会社で働き始めるという悪夢があり、人々は「自分のMVVMフレームワークをコーディングできないのですか？常にPrismを使用する必要があるのですか？Hahahahaha！」そして彼らは輪になって私を指さしながら笑い回ります。
私はあまりプログラマーではないようです。自分でフレームワークを作成するのに必要なものがないように感じます。私は、他の「より良い」人々によって作成されたものだけを組み合わせることができるような気がします。
すべてがプログラミングに固有というわけではありませんが、いくつかのアドバイス：
- 自我を取り除く。それは一歩一歩取り組んだ人生の課題です。しかし、あなたはそれが必要になります。自分が投影しようとしている自分のイメージについてそれほど心配しなければ、自分の発言について考える時間を増やすことができます。ほとんどの人は敬意をもって恩返しをします。
- 本当に重要な質問は次のとおりです。何ができますか？あなたがそれをどのように行うかは、完全に無関係です。上司、ユーザー、および自分のコードを作成するユーザーにとって重要なのは、どれだけ迅速にそれを実行できるか（つまり、どれほどのコストがかかるか）、変化する要件に直面した場合の柔軟性、およびそれがどれほど使いやすいか（ユーザーの視点から、または他のコードからのインターフェースの場合）。サードパーティのツールを使用するか、毎回最初からホイールを作り直すかは問題ではありません。知覚可能な影響はあります。
- ろくでなしに悩まされないでください。開発者（または任意の領域）として注目に値するスキルを習得した人の大多数は、どれだけの時間と作業が必要かを知っています。ほとんどの人は、あなたが彼らに尋ねた場合、あなたを助けるために彼らの道を外れます（そして、実際に彼らにあなたを助けさせます）。あなたを中傷しようとする人はごくわずかです。多くの場合、それらは自分のスキルの不足を補う必要を感じている人々です。
- 自分で「汎用フレームワーク」をうまく作成できる人がたくさんいると思い込まないでください。 「成功する」とは、人々がそれを使用してそれに貢献することを意味し、主流は主にそれを特定の問題に対する標準のソリューションの1つと見なします。その時までに、プロジェクトは通常少なくとも半年にわたって繰り返され、多くの人々によって絶え間ない見直しと強化を受け、文字通り数千のフィードバックがありました-ほとんどすべての関係者のかなりの経験があります。そして、ほとんどの場合、それは既に成熟プロセス全体を通過した他のいくつかのテクノロジーの後継またはノックオフです。それを使用することに恥はありません。逆に、それが問題を解決する場合、それを使用しないことはリソースの浪費です。多くの場合、それは傲慢または無知、あるいはその両方の組み合わせの兆候です。
言われていること：そこには、むかつく「肥大した「フレームワーク」がたくさんあります。ダグラス・アダムスがかつて指摘したように、人間の脳のかゆみは、それが大きなことにどれほど驚いたかで最もよく示されます。ドキュメントがたくさんある大きなフレームワークを目にしたとき、人々はそれが良いはずだと思います。逆のことがよくあります。多くの場合、これは過剰設計の指標です。しかし、通常、特定の一般的な問題については、十分にテストされ、適切に設計されたソリューションがすでに利用可能であることがよくあります。
簡単に言えば、フレームワークの使用と独自のフレームワークの作成の間の細い線を構成するものは何ですか？さらに重要なのは、テクノロジー/テクニックを使用する場合に、実際に発生する問題を確認せずに自動的に発生する知識のギャップをどのように埋めるかです。
- ツールが仕事を終えたら、それを使用します。 「仕事」を理解するのは難しいことです。それが最初で最も重要なステップです。次に、ツールを選択する必要があります。そしてそれを行います。そして、「仕事」への理解が深まったことに気付くかもしれません。そのため、プログラムの一部のツールと部分を追加/置換する必要があります。これが起こる可能性は「仕事」の一部であり、初期のツールセットを選択する上で重要な要素です。
- 50年前の自動車に衝突して、現代の安全性に組み込まれているすべての安全性を評価したいですか？私はそうは思いません。とにかくあなたは地獄の自分のスライスを持っています。これ以上トラブルを起こす必要は全くありません。
常に何を知っているかだけでなく、何を知らないかを選択する必要があります。これは、複雑なシステムのthedivide and conquerである情報非表示の基礎です。あなたのプログラミング言語はすでに、惑星uglydetailiaの抽象圏の上位にある大きな白い雲です。あなたの脳は実際にはこのようにしか機能できないため、抽象的なレベルから物事を見る。それはあなたが現実の世界を扱う方法であり、それをプログラミングに適用することは非常に賢明です。
また、知識自体には価値がありません。価値は理解から生まれます。多くの場合、知らないことの知識が含まれます;）
スキルを間違った方法で練習しても、習得するのに役立ちません。誤って間違って実行したり、他の人が不適切に実行したコードを維持したりする可能性は十分にあります。
これらの種類の質問では、人々は抽象化の最上位層についてのみ心配することも魅力的です。数十年に及ぶプログラミング言語の研究、設計パラダイム、オペレーティングシステム、データベース、コンピューターアーキテクチャに基づいて構築していますが、CMOSテクノロジーがダウンしていても、過去10年かそこら。
人々がウェブページを作り始めたとき、フレームワークのようなものはありませんでした。今後10年間で、あなたが苦労して学んだことは改善され、初心者はそれらの改善の根本的な理由を十分に理解して、TDD、依存性注入、MVVMなどを完全に理解できるかどうか疑問に思います。彼らが物事を比較的小さな機能に分解するべきだというこの新しい考えがいつあったかを覚えている人々はまだ働いています。
つまり、過去10年間の経験不足を心配する必要はありません。今後10年間で、まったく新しい種類の経験が必要になります。
すべての優れたプログラマーと同じように、新しいことを学び、新しい問題を発見し、ソリューションを構築するという3つのことを継続的に実行します。コードの作成（ソリューションの構築）に費やす時間が長いほど、他の2つの問題にうまく取り組むことができます。これは、新しい問題を解明し、役立つ新しいことを学ぶためです。
新しいフレームワークまたは方法論をいつどのように使用するかを知りたいが、コメントを書くライフサイクルのような、もう少し単純なことについて考えてみましょう。
- 公開されているすべてのコード例がすべてにコメントしていることに注意してください。
- 時間の制約、役に立たないコメント、そして誰もあなたのコードをレビューしてコメントを書かざるを得ないので、あなたは何も書かないのです。
- 古いコードに戻り、理解するのが難しいことに気づいてください。
- コメントを書き、考えのすべての流派を発見するための最良の方法を研究します。コメントを書くか、コメントツールを使用するか、コメントが古くなるので自己コメントコードを書く必要があります。
多分コメントは問題ではないのですか？他のすべてのように、あなたはそれを最初に正しく得ることはできません。これが、新しいプログラマーの開発プロセスにおいてメンターが非常に重要（そしてしばしば欠けている）な理由です。すべてを試行錯誤することにあまりにも多くのことが起こっています。データベースを使用するアプリを作成することはないので、キャリア全体を費やしてもORMは必要ありません。
物事を学びたいというのは、健全な好奇心であり、何かを構築するのを妨げるような執着ではない限り、開発者にとって素晴らしいツールです。 TDDは、テストに合格するのに十分なコーディングを行うことで要件を満たすことだけに集中するため、役立つ場合があります。結局、あなたは何かをコーディングして、「これを行うためのより良い方法がなければならない」という結論に達するでしょう。フレームワークを探すか、独自のフレームワークを作成してください。