4

モジュールを開発するために、2 つまたは 3 つのテクノロジ/戦略から選択しなければならない場合がありました。

現在、大小を問わずすべてのコンポーネント/モジュール/プロジェクトに対して、ほぼ無数のオプションがあります。長年の経験がある人にとっては簡単かもしれませんが、プログラミングを始めて 1 年未満の人にとってはそうではありません。

私は、.NET の世界でのデータ アクセスの選択肢に不満を感じることがあります。市場に出回っているすべてのツールと、それが提供するものすべてについて、すべての製品について読むことはできません。

この質問を思いついた理由は、最近プロジェクトに取り組む必要があり、DataAccessLayer の仕様が ADO​​.NET で最終決定されたためです。プロジェクトの約 20% で、新しい開発者が私たちの部門に加わりました (ただし、私たちのチームではありません)。私は彼を頭が良くて助けになると思っています。

コード レビュー中に、彼は個人的に、私たちが取り組んでいるモジュールには LINQ to SQL を使用する方が良いとアドバイスしてくれました。彼は説得力がありました。前向きな議論の後、LINQ to SQL を使用することに同意しました。

しかし、「経営者」はそれについて満足していませんでした。モジュールを開始する前に、この「素晴らしいアイデア」を思いつくべきだったという議論がありました。彼らの主張は、これまでの作業の 20% にリソースが費やされており、その作業は無駄になるというものです。

新しい製品/テクノロジー/戦略が頻繁に発表されるペースを考えると、これらすべてのツールとテクノロジーに関するすべての情報を入手することは困難です。

ADO.NET を使用して成功しました。LINQ (一般的に)、NHibrnate、その他多くのアイデアがありましたが、ADO.NET より先に進みました。私は新しいことを学ぶことに反対しているわけではありません。それが、私たちが LINQ の使用をまとめて推し進めた理由です。

質問 この選択をした時点で、私たちに責任はありますか?

特定の状況でどのテクノロジーを選択するか、およびストリームの途中でいつ切り替えないかを決定するための指標やガイドラインはありますか?

4

7 に答える 7

4

新しいプロジェクトを開始するときに、現在のすべてのテクノロジーを念頭に置くことは、困難であり、ますます困難になる作業です。

私は常に最先端を追うようにしています。そうすれば、そこに何があるのか​​がわかります。これは、たくさんのブログを読んだり、会議に出席したり、最新の状態を維持したりすることです。

そうは言っても、常に最先端のものを使いたくはありません。私の経験則は、製品の出荷日を見積もることです。私は、少なくとも1つの「サービスパック」を受け取った最新のテクノロジーを使用するか、出荷日までに更新するようにしています。確かに、出荷日は不明であるため、これには多くの推測が必要ですが、（業界を監視する）経験は非常に役立ちます。

どのテクノロジーが人気があり、どれが時間の経過とともに衰退するかについて、知識に基づいて推測するための技術があります。残念ながら、それは本当に経験の問題です。長年の経験があり、最新のテクノロジ（重要）を常に把握している開発者がいる場合は、この意思決定に役立つ優れたリソースです。

于 2010-01-26T21:32:34.103 に答える
4

時間枠、およびプロジェクトのリスク。それらが基本です。

私は LINQ や ADO.NET について詳しくは知りませんが、それは重要ではありません。

大まかに言えば、LINQ と ADO.NET の間に違いは見られません。LINQ が「より優れている」、「よりエレガント」で、コードが少なく、より明確であることがわかります。しかし、実際には、チームが既に ADO.NET に精通しており、慣れている場合、これらは大きなプロジェクト リスクではありません。あなたはまだデータベースにデータを出し入れするつもりであり、チームは「洗練されておらず、コードが多く、明確ではない」ADO.NET に対処する方法をすでに知っています (これらは一般化であり、判断そのものではないことに注意してください)。 .

プロジェクトに LINQ のようなものの採用を吸収できる時間があり、それが新しいテクノロジであっても明らかに優れている場合は、それを新しい作業に採用したり、古い作業にレトロフィットしたりすることができます。

たとえば、1 年にわたるプロジェクトがある場合、タイムラインのどこに新しいテクノロジを採用するのに十分な「余裕」があるかを簡単に確認できます。1 か月のプロジェクトであれば、おそらくそれほど多くはありません。

そこには多くの素晴らしい新しい技術があり、それらは毎日出てきていますが、「あなたが知っている悪魔」と新しいものや証明されていないものを採用することについて、多くのことを言うことができます. これが、私が個人的に、この種の調査のほとんどを自宅で「趣味モード」で行う理由です。これにより、新しい技術が私たちの試行錯誤よりも適切で適切である可能性があるときに、新しいプロジェクトについてより良い情報を得ることができます。 「古い学校」の方法。

それ以外の場合は、プロジェクトの仕様策定中に、新しい技術を証明して、プロジェクトの開始時に含めるのが適切かどうかを判断するための時間を確保する必要があります。多くの場合、仕様を作成する人々にはその時間が与えられません。

于 2010-01-26T21:37:33.650 に答える
1

1 年間の経験があれば、そもそも適切なテクノロジを選択しなかったのはあなたのせいではありません。この種の決定を下すのは難しく、経験が必要です。

ここで責任を負うのは、プロジェクト マネージャーが、プロジェクトの開始時にこれらのアーキテクチャに関する決定を行うための適切なリソースを提供しなかったことです。

于 2010-01-26T21:37:10.787 に答える
1

特定のソリューションまたは開発プロジェクトにどのテクノロジが「適切」であるかを左右する要素は多数あります。

多くの場合、選択肢、「正しい」と思われるもの、人気のあるもの、最も楽しいかもしれないものに関して、多くの内部および外部の影響を受けることになります。

私が見ている「適切な」決定を下すことは、最も安定した、文書化された、実行可能なソリューションを選択することです。これを行うには、テクノロジーに遅れずについていき、そこに何があるかを知る必要があります。そのため、LINQ、Entity Framework などについていくことが不可欠です。

真の「芸術」とは、環境に適したものを決定することであり、それぞれの環境は異なります。考慮すべきさまざまな項目があります。これは内部使用のみですか？そうでない場合、環境に対してどのような制御と影響力を持っていますか? VSなどの最新バージョンを使用することは可能ですか？

それが何であるかという理由だけで、私は「最先端」を使用するのが好きではありません。新しいツールを使用するには、技術的な基礎が必要です。

于 2010-01-26T21:38:17.727 に答える
1

プロジェクトがすでに始まっていて、誰もが準備ができていないときに Linq-to-SQL に切り替えるのは、おそらく間違いでした。最初からそれを使用するべきだったとしても、プロジェクトが開始されたら、知っていることに固執することをお勧めします。その逆は異なります。プロジェクトの開始時に何か新しいことを試みて、うまくいかない場合は、より慣れ親しんだものに戻すのが最善かもしれません。

Linq-to-sql の場合、プロジェクトの途中で切り替える価値のある利点が得られる可能性は低いです。これは賭けでしたが、残念ながらうまくいかなかったようです。

.Net Data Access オプションは、私たちの多くを夢中にさせています。あなた一人じゃありません。すべてのテクノロジーについて知ろうとすることさえ難しくなっています。適切に評価するには、経験を積み、徹底的に調査する必要があります。きちんとしているように見えるからといって、最新のものを試したくないのは間違いありません。使い慣れた古いテクノロジ (ADO.NET など) の一部は問題なく動作します。

于 2010-01-26T21:39:49.563 に答える
0

半分の時間は、手元にあるリソース（つまり、人々はどの言語を知っていますか？）を使用することであり、私たちは何をライセンスしているのでしょうか？

于 2010-01-26T21:34:18.603 に答える
0

プロジェクトの最初または最後に「LINQ」を使用することは、必ずしも「素晴らしい」アイデアではありません。あなたのチームが ADO​​.NET の経験があり、そのテクノロジを使用してプロジェクトを成功裏に完了した場合は、実際にそのテクノロジを使用する必要がありました。

ポイントは、VB6 の内外を「知っている」チームを持っている場合...まあ、何を推測するか...あなたは VB6 のコーディングが好きだということです。

チームの大部分が快適で知識豊富なテクノロジーを使用してください。

于 2010-01-26T21:39:44.207 に答える