新しいマイクロソフトテクノロジを学習/実装する理由[終了]

私は中規模のソフトウェア開発者として大規模な医療機関で働いています。Microsoftテクノロジー（ASP.NETとSQL Server）を使用したIT業界で10年以上の経験があります。

カンファレンス、コードキャンプ、.netユーザーグループミーティングに行くと、MVC、LINQ、Entity Framework、WCF Webサービスなど、あらゆる種類の新しいツールとテクノロジについて耳にします。 asp.net 2.0の同じ古いものを使用するゾーン。データアクセスレイヤーに型指定されたデータセットを使用しています。私はマスターページでWebフォームと機能豊富なサーバーコントロールを使用しています。私は、アプリケーションが必要とするデータを取得するために、単純な古いSQLを使用し、型付きデータセットにクエリを作成する方法を知っています。

私のキャリアを通じて、私は自分のスキルセットで時代遅れにならないように常に敏感です。私が現在使用しているものは問題なく動作し、私の開発時間は高速です。しかし、もし私が解雇されるとしたら、インタビューで私が書いたMVCアプリの数を尋ねられるのではないかと心配しています。または、LINQまたはWCF Webサービスの使用方法。

いくつかの新しいテクノロジーについて見た会議、本、ビデオの数は関係ないことはわかっています...それを実装/使用する必要があるか、それがうまくいかないだけです。また、面接するマネージャーは気にしません誰かが何かをどれだけ読んでいるか、実際の使用と技術の経験のみ。

書く新しいプロジェクトがあります。私は上司のところに行って、私が知らないテクノロジーを学習/実装するためのプロジェクトに追加の時間を求めました。私たちの組織は、従業員が「学び、成長」し、教育を続けることを奨励しています。しかし、新しい何かを実装するためにもっと時間をかけるように頼むとき、私はいつも抵抗を感じます。私のマネージャーは、これらの新しいテクノロジーを実装するための具体的なビジネス上の理由を求めています。私にはビジネス上の理由はありません。私の理由は、時代遅れになりたくないからです。将来、他の開発者がプロ​​ジェクトをより保守しやすくなると言えるかもしれません。ある時点で、これらの古いテクノロジの使用をやめることができるからです。Linq / Entity Framework / MCVアプリのパフォーマンスは向上しますか？顧客（私がこのアプリを作成している部門のユーザー）が必要とするほど、そうですか？疑わしい。

私はこれに関するあなたの男の考えに興味があります。あなたの多くは、新しい技術を使用しようとすることで同様の苦境を持っていますか？テクノロジーの最前線にいるとは思えません。これらのテクノロジーを使用するために明らかにする「ビジネス上の理由」はありますか？

前もって感謝します！テキストの長い壁でごめんなさい。

時代遅れにならないことは、新しいテクノロジーを使用するビジネス上の理由としてはかなり良いように思えます。これは、両方の方法を流します。スキルセットが古くなるのは望ましくありませんが、上司も、時代遅れのテクノロジーに進んで取り組んでいる従業員を見つけられない可能性があることを心配する必要があります。開発者と雇用者の大多数が新しいテクノロジーのために古いテクノロジーを残した場合、あなたの会社もそうするのに十分な理由かもしれません。

具体的に質問に答えるには、これらのテクノロジを個別に評価して、ニーズに合っているかどうかを確認する必要があります。私の見解をお伝えしますが、実際には、特定のビジネスニーズに適用するために、少なくとも半日はそれぞれを調査して評価する必要があります。

LINQ：これは、エンティティフレームワークがなくても使用できるものです。LINQは、データのコレクションを操作するために使用されるテクノロジであり、データベースからのデータのロードに使用しなくても、アプリケーションで使用できます。自分で好きにして、ラムダ式とLINQ拡張メソッドの使い方を学びましょう。それはあなたの時間を節約し、開発者としてのあなたの人生を楽にし、そしてあなたが書く必要があるコードの量を減らします。

エンティティフレームワーク：これは、Microsoftの世界でのデータアクセスの将来のようです。Microsoftの新しいフレームワーク、テクノロジー、ツールのほとんどは、エンティティフレームワークと連携するように設計されています。完璧ではありませんが、特にエンティティにLINQを使用する場合は、データセットを使用するよりもはるかに優れています。エンティティフレームワークを使用する大きなビジネス上の理由の1つは、フレームワークが生成するため、記述する必要があるSQLコードの量が減ることです。私の経験では、ほとんどの開発者はとにかくSQLを書くのが得意ではありません（ほとんどの企業には専用のDBAがいません）。エンティティフレームワークでは、オーバーヘッドが少なく、データセットよりも扱いやすいPOCOを使用することもできます。

MVC：ほとんどのアプリケーションはあまりメリットがないため、これを正当化するのは難しいかもしれません。私が見た最新の求人情報に基づくと、MVCはまだ少数派です（ただし、急速に進歩しています）。ほとんどのビジネスアプリケーションでは、MVCはやり過ぎになる可能性があり、いくつかのコントロールをaspxページにドラッグするだけで十分です。MVCには学習曲線があり、生産性を上げて最大限に活用するには、HTTP、HTML、CSS、JavaScriptを本当に理解する必要があります。MVCは、パフォーマンスが最優先事項である本当にカスタマイズされたWebアプリケーションが必要な場合にうまく機能します。それが当てはまらず、従業員がそれをあまり経験していない場合、それを使用する強力なビジネスケースはおそらくありません。

WCF Webサービス：リモートクライアントアプリケーションにデータを提供する必要がありますか？WCFはおそらく進むべき道です。データベースと同じサーバーまたはローカルネットワークで実行されるWebアプリケーションを作成しているだけですか？WCFを使用しないでください。WCFは必要ありません。WCFは、不必要な抽象化によって物事を複雑にするためにのみ役立ちます。

手短に言えば、意味のある場合は新しいテクノロジーを使用し、そうである場合は時間をかけて調べてください。新しいテクノロジーを習得するには時間がかかりますが、それらを評価して特定の状況に役立つかどうかを確認するのにそれほど時間はかかりません。これは、会社の上級管理職がすでにやっているはずのことですが、そうでない場合は、それを実行し、時間をかけて、学んだことを彼らに教える必要があります。

編集：上記のコメントを読んだ後、私はいくつかのより多くの考えを持っていました。アジャイルなアプローチでこのアプリを開発し、それをさまざまなコンポーネントに分割して、それぞれを完全に完了してから次のコンポーネントに進むことができれば、役立つかもしれません。マネージャーは、あなたが途中で着実に進歩していることを確認できれば、新しいテクノロジーのために余分な時間を割くことを承認する可能性が高くなります。また、アプリ全体をMVCで書き込むか、Entity FrameworkまたはASPXページとデータセットで書き込むかを選択する必要はありません。ハイブリッドアプローチを使用して、同じアプリで両方を使用することが可能です。MVCとエンティティフレームワークをいくつかのコンポーネントに使用することから始めることができます。物事がうまくいって上司が幸せならあなたは続けることができますが、彼がそれを感じているなら

新しいMSテクノロジのいくつかを確実に学ぶ必要がありますが、WPFやWCFなどについての最近の経験により、最新のMS APIの学習についてもう少し慎重になりました。

LINQは、生産性を向上させるための大きな恩恵です。良い点は、実際のクエリ構文の有無にかかわらず、あらゆる種類のランダムな状況でLINQ-to-objectsを段階的に導入できることです（多くの場合Where()、from-select構文が短いため、構文なしで呼び出します）。拡張機能は、あなたが知っておくべきことですが、私はまだ本当に良いユースケースを見つけるのに苦労しています。同様に、C＃3/4/5のすべての機能は役に立ちます。したがって、「古い」BCLのものを使い続けている場合でも、それらを調べて、それらが役立つ場所に注意する必要があります。

ただし、私は悪魔の支持者を取り上げて、WCFやWPFなどの非常に最新の大きなMSライブラリは、必ずしも学習する価値がないことをお勧めします。

主な理由は、それらが巨大であり、特にうまく設計されていないことです（前者は後者の症状です）。最近、WPFの問題について簡単にブログを書きました。WCFについては、ホワイトペーパー「Windows以外のシステムで実行されているJava EEサーバー」や「さまざまなプラットフォームで実行されているパートナーアプリケーション」と簡単にうまく相互運用できるように聞こえますが、WCF APIは特にSOAP指向であり、非SOAPプロトコルの制限付きサポート。MSは、プラグイン可能なプロトコルを許可する一般的なシステムを簡単に設計でき、機能がどこかに隠されている（文書化されていない）可能性がありますが、私が知る限り、SOAPと制限されたHTTPのみを実行できるはるかに制限されたシステムを設計することを選択しました（メッセージ本文がシリアル化された.NETオブジェクト、IIRCである限り）。私はEntity Frameworkをより簡潔に調査しましたが、（はるかに単純な）LINQ-to-SQLがそのままで処理できるいくつかのシナリオをサポートできないという不満に気づきました。

IMOこれらのすべてのライブラリーの設計には根本的な欠陥があります。これらのライブラリーは相互に密結合している多くのコンポーネントを使用しているため、各フレームワークのクラスの依存関係グラフはおそらく巨大で、落書き線の乱雑な混乱のように見えます。そして、デザインが良かったとしても、下位レベルの詳細を掘り下げた公開の建築ドキュメントがなく、ほとんどの場合、MSDNドキュメントがあまりよくないため、わかりません（多くの場合、下位レベルおよび下位レベルのクラスを見ると、次第に役に立たなくなります。）

ライブラリの膨大なサイズも欠点のようです。20年以上に渡るプログラミングの中で、単純さが美徳であり、マイクロソフトがこれまでに評価したことがない美徳であることを学びました。

しかし、「それで何を」と尋ねるかもしれません。まあ、そのような大きなライブラリを使用すると、実際にそれらを理解しているように感じることはありません。つまり、MicrosoftがWCF / WPF / EFを特別に設計したユースケース以外で何かをしたい場合、その方法を知ることはできず、レドモンドの外部の誰もその方法を知らない可能性もあります。そして、何かがうまくいかないとき、あなたは何がうまくいかなかったかを理解するのに苦労するでしょう。そして今、マイクロソフトがその上に移動したときから15年の次の次の世代のAPIは、誰もがそう悪い、理解されている基盤の上に構築されたソフトウェアを維持楽しむつもりはありません。

また、これらの新しいAPIは大きく複雑であるため、.NETのクロスプラットフォーム代替物であるMonoは、サポートが不十分であるか、サポートされていません。LinuxまたはMacで型付きデータテーブルを使用するのにほとんど困難はないでしょうが、Entity Frameworkはどうでしょうか。気にしないで。Monoがこれをサポートしなくても驚かないでしょう。

新しいプロジェクトでLINQ-to-SQLを使用しましたが、悪くありません。いくつかの点でそれはより良いかもしれませんが、開発者の経験はADO.NETよりも実質的に優れていると思います。重要な制限の1つ：アクティブなデータベース接続なしで動作するように特別に設計された古いADO.NETとは異なり、「接続」モードでテーブルを変更する場合、L2Sははるかに簡単です。とにかく、LINQ-to-SQLは（Monoの人々によると）Entity Frameworkのサイズの4分の1なので、MSがその作業をやめることにしたのは残念です。

Microsoft Windowsベースのソフトウェアを10年以上開発してから、完全にフリーのオープンソースソフトウェアに切り替えてMS開発をあきらめました。私は長い個人的な経験からこれを書いています。

私がFOSSに切り替えたことによる他の理由は別として、プログラミングに関連する理由は、プロプライエタリなテクノロジーを学習/実装する正当な理由がほとんどないということです。問題の核心は、マイクロソフトがこれまでに配布したテクノロジーのありとあらゆる部分をサポートすることにコミットしていないということです。MSはAPIとフレームワークに廃止予定の変更を導入することがよくあります。これにより、既存のAPIの多くとその知識が古くなります。実際、エンドユーザーソフトウェアを使用してこれを実現しています。たとえば、MS Office 2007/2010はMS Office 2003と似ていません。さらに重要なことに、Windows 8は既存のプラットフォームから根本的に離れています。特に、Windows 8にはすべて新しいAPIとフレームワークが存在することになり、それらを実装しない限り、Windows 8を（現在ではないとしても、将来的に）サポートすることはできません。unsupportedは、MSがリリースする新しいテクノロジーの実装を続ける主なビジネス上の理由の1つです。MSが古いテクノロジーのサポートを明日停止した場合、レガシーコードはどこに行きますか？アップデートはどこで入手できますか？

また、MS開発を中止してFOSSに切り替えるようにお願いしているのではありません。MSテクノロジーで長い経験を積んできた私は、ここであなたを助けたいだけでした。

新しいテクノロジーを採用することの具体的なメリットを理解し、それを正当化する理由として、陳腐化したくないというあなた自身の願望よりも、主なことは何かと思います。あなたは「ビジネス上の理由」はないと言いますが、確かにあなたは研究でいくつかを見つけることができます...

新しいフレームワーク/テクノロジーに移行することで、メモリフットプリントが小さく、応答性が高く、デプロイが高速になるなどのアプリを設計できるようになるかもしれません。これらはすべて、ビジネス上の具体的な理由です。したがって、少し引き下げて、「そもそもなぜMVC、LINQ、Entity Framework、WCF Webサービスなどを使い始めたのか」を調査することをお勧めします。その質問に答えてください。そうすれば、ビジネス上の正当性を提供できるでしょう。「何がうまくいくか」という理念を捨てるだけで十分かどうかは別の問題であり、セールスマンシップの関数である可能性があります。

私が現在使用しているものは問題なく機能し、開発時間は短い

残念ながら、マイクロソフトはこれについていちじくを提供していません。彼らにとって重要なのは、より多くのツールを販売することです。つまり、新しいテクノロジーを作成することになります。つまり、より多くのトレーニングを購入する必要があります。双方にとって有利なことです。

あなたにとって、それは新しいことを学ぶための絶え間ない戦いを意味します、そしてあなたがそれらをうまく使い始めたら、そしてあなたの開発生産性がかつてと同じくらい速くなったならば...もう一度。ソフトウェアが一般的に低品質である理由があります。それは、ソフトウェアがエンジニアリングやアーキテクチャのような「プロフェッショナル」サービスのように扱われていないため、機能を維持します。私たちはそれらを捨て、常にゼロから始めます。

しかし、この貧しい世界の状態はあなたを助けません。したがって、私のアドバイスは、「テクノロジーに遅れずについていく」と「遅れを取りたくない」の組み合わせを使用することです。上司は採用に関心を持つ必要があります。VB6の開発だけを行った場合、新しいスタッフを採用するのは非常に困難です（実際、おそらくVB6を好きだった人は皆、あなたに集まります。しかし、それは別の問題です）。

新しいテクノロジーxが将来の開発をより迅速に行うのに役立つかどうかを確認する必要があると思います。個人的なタスクや無駄なタスクでなくなり、ビジネス改善タスクになるため、企業は常にR＆Dに取り組んでいます」革新」は彼らが競争力を維持するのに役立ちます。

開発者は、新しいテクノロジを使用するように管理を推進し​​、企業にもたらすメリットと価値（パフォーマンス、機能、使いやすさ、メンテナンスなど）を実証することによってそれを正当化する必要があります。管理は通常、変更を嫌い、現在使用されているものに対していくつかの追加の利点をもたらさない限り、何かを変更することを正当化しません。

いくつかの新しい「最先端の」テクノロジーを使用することは、現在のテクノロジートレンドの上にあり、レガシーテクノロジーやプラットフォームを使用して過去に行き詰まっていないように会社をマーケティングできるように、マーケティングチームにも適しています。

あなたの会社が彼らに彼らを学ぶのを許さないならば、あなたはあなたの余暇にいくつかのより小さなプロジェクトをする必要があるでしょう。あなたがプライベートな時間に行う学習は、より新しいテクノロジーの改善について上司に伝えるビジネスケースを与えるはずです。現在、日々の仕事が焦りすぎて新しいことを学ぶことができない場合は、数週間の休暇を取って、数日間休んでから、自分で集中的なトレーニングセッションを行う必要があります。

あなたはどうなるかと言うマイクロソフト、あなたがそれらを上の障害傾ける一つのことを行っている開発ツールをし、訓練で利用できる無償。PCに最新のMicrosoft Web Platformインストーラーをインストールし、それを起動して、試してみることができるすべての無料の開発ツールとプラットフォームが表示されるのを待ちます。訪問MSDN、ASP.NetとChannel9のウェブサイトを、そのチュートリアルをチェックしてください。

信じられるなら、私はまだASPクラシックで開発していますが、数時間の説得で、ビジネスケースを作成することによって、上司に.Netが進むべき道であると確信させました。来年は、レガシーコードの移行を開始します。

新しいテクノロジの使用を正当化する最良の方法は、それらが開発者の生産性を向上させることを示すことができる場合です。これは、より多くの作業を低コストで実行できることを意味します。それがビジネスの観点から重要な唯一のことです。

いくつかの例：

1. 開発者が作業しやすくするツール
2. 社内で開発する必要がある機能を提供するライブラリ
3. 読みやすくなるコード、または記述/デバッグする必要のあるコード行が少なくなる、より強力な言語