本「ASP.NET Core。 アプリケーション開発»

現代の開発者は、クロスプラットフォームアプリケーションの構築、メンテナンス、および展開に従事しています。 彼らの苦労を軽減するために、新しいMicrosoftフレームワークASP.NET Coreが作成されました。 これで、さまざまなオープンソースライブラリを自由に使用できます。さらに、フレームワーク自体はオープンソース製品です。

ASP.NET Coreが提供するすべての新機能を習得するにはどうすればよいですか？ 著者は、架空の会社Alpine Ski Houseを例として使用して、特定の問題の解決策を説明します。 各章の前には、開発チームが直面している問題と、この問題をどのように克服するかについての短いストーリーがあります。 アプリケーションのアーキテクチャー、クラウドで作業するためのアプリケーションの展開および設計の方法、その他多くのことを理解する必要があります。

この本は、架空の会社Alpine Ski Houseでの最初のアプリケーション開発スプリントを扱っています。 各章の前には、開発チームが直面している問題と、それをどのように克服するかについての短いストーリーがあります。 フィクションの要素が存在するにもかかわらず、この本は、ASP.NET Core MVCの機能だけでなく、開発者がアプリケーションを構築、保守、および展開するために使用するツールについても深くカバーしています。

ASP.NET Core MVCに関するストーリーと技術情報に加えて、本書では、最新のWeb開発者が使用するEntity Frameworkの新しいバージョン、パッケージ管理システム、および周辺技術について説明しています。 理論的なトレーニング資料に加えて、アルペンスキーハウスのプログラマーによって開発されたプロジェクトも付属しています。

この本は誰のために書かれたのですか？

この本は、ASP.NET Coreに基づいて新しいアプリケーションを作成し、インターネットを介してそのアプリケーションへのアクセスを提供するすべての段階を通してプログラマーをガイドします。 多くのプログラマーは、現在利用可能なソフトウェアツールが豊富にあるにもかかわらず、まだWeb開発の世界から遠く離れているか、WebFormsを介してWeb開発とわずかにしか接触していません。 この本は、読者が積極的に開発しているフレームワークで最新のアプリケーションを設計するために必要なスキルを習得するのに役立ちます。 クラウドで作業するためのアプリケーションアーキテクチャ、展開、設計ツールについて学習します。

この本はあなたに適していない場合...

あなたがASP.NET Core MVCの開発に密接に従うか、または直接関与している経験のあるASP.NET MVC開発者である場合、この本はあなたに適さないかもしれません。

本の構造

この本は、アプリケーション開発中に個々のスプリントについて開発者をガイドするという珍しいアプローチを使用しています。 テクノロジーだけでなく、エラーからの回復プロセスと、ユーザーのフィードバックに対する開発者の反応も考慮します。 最初から始めて、本格的な実行可能な製品で終わります。
本は4つの部分に分かれています。

•パートI「スプリントワン：アルパインスキーハウスアプリケーション」では、読者に状況の本質を紹介します。本で使用されるアプリケーションとストーリーの架空の登場人物について説明しています。

•パートII「スプリント2：1000ステップの旅」は、アプリケーションの主な機能的側面と、展開をその場で開始するパイプラインの設定に専念し、プロセスは開発チーム全体が理解できるようにします。

•パートIII、スプリント3：ビーストオブザビーストでは、実際のビジネスプロセスでテストアプリケーションの使用を開始するために必要な基本機能に焦点を当てます。 特に、Entity Frameworkコアを介したデータの操作、Razorベースのビューの作成、構成とログ、セキュリティと権限の管理、最後に依存関係の注入について説明します。

•パートIV、スプリント4：フィニッシュラインでは、JavaScriptと依存関係の管理について説明し、前のトピックのいくつかを開発します。

この本は、テスト、リファクタリング、拡張機能の追加などの重要なトピックで終わります。

抜粋 コード品質のリファクタリングと改善

1年前に書いたコードに満足している開発者はほとんどいません。 多くのプログラミングセミナーでよくあるジョーク：プログラマーは「誰がこのゴミを書いたのか？」と叫び、歴史を調べて、それが彼だとわかります。 これは実際に素晴らしい機会です。 コードの記述を開始すると、多くの場合、サブジェクト領域、プログラミングの問題、および記述しなければならないアプリケーションの構造のみを理解しようとしています。 心が一度に吸収できる情報の量は限られており、多くの「可動部分」がコードの構造や機能のエラーにつながることがよくあります。 数か月後、アプリケーションの理解が向上したときに戻って古いコードを修正することは、最大の贅沢です。

この章では、リファクタリングの概念と、パフォーマンスを損なうことなくアプリケーションの機能を改善する可能性について説明します。

リファクタリングとは何ですか？

「リファクタリング」という用語は、1990年代初頭にWilliam OpdykeとRalph Johnsonによって提案されました。 はい、The Gang of Fourによって書かれた本があります1 リファクタリングは、コードブロックの内部構造の変化として理解され、その結果、コードがより理解しやすくなり、テストで便利になり、変更によりよく適応し、その外部機能は変化しません。 入力データを受け取り、出力データを提供する「ブラックボックス」の形式の関数を想像すると、入力と出力が変更されない場合、「ブラックボックス」の内部構造の変更は特別な役割を果たしません（図23.1）。

この観察により、機能を維持し、アプリケーションの全体的な品質を向上させながら、アプリケーションのコードを置き換えることができます。 また、「関数」という用語をコードブロックの指定として使用しますが、その範囲は関数の内部構造に限定される必要はありません。 オブジェクト指向プログラミングのポイントは、実装の詳細を開示しないように抽象化を広く導入することです。 リファクタリングの目的で「ブラックボックス」と見なすことができる多くのデザインがあります。 最初の候補はクラスです。 入力データと出力データが変更されない場合、クラスの実装は重要ではないため、適切と思われる内部メカニズムを変更できます。 名前空間は、クラスと同じレベルの保護を提供しませんが、置換の候補と見なすこともできます。 最後に、マイクロサービスの世界では、アプリケーション全体を別のアプリケーションに置き換えることができ、そのような置き換えもリファクタリングの一部になります。

メーリングリストを介して電子メールを送信することを責務とするサービスを検討してください。 入力は、受信者と送信するメッセージのリストです。 ここでの出力の場所は、結果によって占められています：受信者のリストからのすべての受信者によるメッセージの受信（図23.2）。


マイクロサービスがメッセージを送信する方法は関係ありません：Sendgridを使用するか、独自のサーバーから。 いずれにしても、結果は同じままです。 この場合、マイクロサービスの置換はリファクタリングと見なすことができます。

プログラマは通常、コードの改善に役立つリファクタリングを呼び出します。 余分なメソッドパラメーターを除外しますか？ DevOpsのサポートを改善するために、陰湿な方法でログエントリを追加しましたか？ どちらの場合もコードの品質またはアプリケーションの品質は向上しますが、それらはいずれもアプリケーションの機能を変更するため、リファクタリングと正式に見なすことはできません。 リファクタリングの定義を完全に順守するには、入力（パラメーターの構成を含む）と出力（ジャーナル内のメッセージを含む）の両方を変更しないことが必要です。

コード品質評価

開発者がコードの品質を改善するためのリファクタリングに関与している場合、もちろん、コードの品質を評価するための何らかの基準が必要です。 コード品質を評価するためのツールがあれば、それは素晴らしいことです。これは、コード品質のあらゆる側面を単一の数値で表すことができる非の打ちどころのないメトリックです。 残念ながら、そのようなメトリックは存在しません。 長年にわたり、遠心クラッチおよび求心クラッチからコード行のエラー数の推定やコードのテスト範囲の推定まで、無数の品質メトリックが提案されてきました。 コード品質メトリックのセットを選択することは、それ自体が本全体に値するトピックです。

ただし、コードの品質を評価するには、いくつかの簡単なメトリックを強調表示すると便利です。

•コードは、想定されていることを行いますか？ 一見すると明らかですが、この指標はしばしば忘れられます。 コード1,000行あたりの報告されたエラーの数、またはクラスごとのエラーの数によって推定できます。 一部の開発者はこのメトリックをグローバルに使用し、2つのプロジェクトの相対的な品質を検出された欠陥の数で比較します。 ただし、2つのプロジェクトが1つの問題を解決することはないため、このアプローチは非生産的です。 電子グリーティングカードを作成および配信するシステムが、インスリンディスペンサー制御システムと同じ程度の複雑さまたはエラー率を持つことを期待することは可能ですか？ いいえ、もちろんです。 このメトリックは、他のほとんどの製品と同様に、グループと製品が時間とともに改善されているかどうかを調べるのに役立ちます。

•コードは非機能要件を満たしていますか？ 関数の入力または出力に関係しない要件（たとえば、コードフラグメントのパフォーマンスやそのセキュリティなど）について話している。

•コードはどれくらい明確ですか？ 理想的なコードはまったく存在せず、エラーが検出されたり要件が変化したりするため、遅かれ早かれ誰かがそれを更新する必要があります。 コードの作成者、つまりあなたも、この「誰か」になることができます！ 次のスニペットをご覧ください。

for (var i = 1; i < parts.length; i++) { root[parts[i]] = root[parts[i]] || (root[parts[i]] = {}); root = root[parts[i]]; } 

これは効率的でスマートなコードかもしれませんが、それを理解することはほとんど不可能です。 わかりやすさや読みやすさの客観的な指標を見つけることは困難です。 このメトリックは、メンテナンスの利便性に関する開発者の合意された意見の具体化ほどではありません。 野心に悩まされていない普通の人々のグループでは、コードの読み方に関して深刻な違いが生じることはめったにありません。 コードレビューは、コードのあいまいなセクションを発見するための優れたツールです。

別の単純だが実用的なメトリック-循環的複雑さ-メソッドのコード分岐の数によって関数の複雑さを推定します。 ifコマンドを1つ持つメソッドには、コードの2つの可能な分岐が含まれます。つまり、その循環的複雑度は2です（図23.3）。


•コードは要件の変更に簡単に対応できますか？ 繰り返しますが、このメトリックは素数として表現できません。 むしろ、それは経験豊富な開発者のグループで生じる感覚です。 開発者の顔の酸性表現によると、コードに重大な変更が加えられた場合、この目標が達成されたかどうかを自信を持って判断できます。

これらの4つの単純なメトリックは、アプリケーションのどの部分をリファクタリングする必要があるかを判断するための良い出発点です。 おそらく、アプリケーションの成長と開発中に、新しいメトリックを発見して追加できるようになるでしょう。

複数のメトリックを自由に使用できる場合、アプリケーションが誤ったメトリック用に最適化されていないことを確認することが重要です。 人々は、故意にシステムを欺く傾向があります。 関数から最も速いリターンを提供するパフォーマンスメトリックを選択したが、メモリコストに合理的な制限を設定するメトリックを追加しない場合、計算リソースと引き換えにメモリを消費するように関数を最適化しようとするでしょう。 これが本当に必要なものなのか、最終的な目標がバランスなのかを考えてください。 メトリックを分析し、最適化が間違った方向に進まないことを確認し、もしそうなら、メトリックのセットを更新します。

著者について

開発技術における5回のMicrosoft MVPステータスであるジェームズチェンバーズは、AzureおよびAWSでASP.NET CoreとMVCフレームワークを使用して現在開発中です。 彼は独立したコンサルタントであり、教師であり、積極的なブロガーであり、多くのオープンソースプロジェクトのメンバーでもあります。

4回Microsoft MVPであるDavid Packettは、ソフトウェア開発者であり、独立コンサルタントです。 彼は、WindowsおよびWebアプリケーションの構築に.NETを使用した豊富な経験、深い技術的背景、高品質のユーザーインターフェイスへの情熱を持っています。

Microsoft MVPホルダーであるSimon Timmsは、コミュニティの主催者、ブロガー、開発者、および独立コンサルタントです。 彼の技術的関心は非常に多様であり、分散システムから最新のJavaScriptフレームワークまですべてを楽しんでいます。 開発の分野と進行中の作業の組織の両方で優れたトレーニングを受けているため、彼はしばしばグループを狂気に追い込み、建設と開発からサーバーのメンテナンスまでのすべての段階に参加します。

»本の詳細については、出版社のウェブサイトをご覧ください
» コンテンツ
» 抜粋

ホーカーのクーポンが20％オフ-ASP.NET Core