秋季割引
CodeGym University
勉強
コース
タスク
アンケートとクイズ
ゲーム
ヘルプ
励ましのスケジュール
コミュニティ
ユーザー
フォーラム
チャット
記事
サクセスストーリー
アクティビティ
レビュー
サブスクリプション
ライトテーマ
レッスン
レビュー
会社紹介
開始
勉強を始める
今すぐ勉強をはじめる
クエストマップ
レッスン
すべてのクエスト
すべてのレベル
優れたソフトウェア アーキテクチャの基準
モジュール 3
レベル 14、
レッスン 3
効率 経験豊富なプログラマは、良いアーキテクチャと悪いアーキテクチャを簡単に見分けることができますが、それをいくつかの言葉で説明するように求められると、うまく説明できる可能性は低いでしょう。優れたアーキテクチャに対する単一の基準や単一の定義はありません。 しかし、よく考えてみると、優れたアーキテクチャが満たすべき基準をいくつか書くことができます。優れたアーキテクチャとは、まず第一に、プログラムの開発と保守のプロセスをよりシンプルかつ効率的にする論理アーキテクチャです。 プログ
悪いソフトウェア アーキテクチャの基準
モジュール 3
レベル 14、
レッスン 4
悪いデザインの基準 人生は非常にシンプルに機能します。多くの場合、賢くなるためには、愚かなことをしないだけで十分です。これはソフトウェア開発にも当てはまります。ほとんどの場合、何かをうまくやるには、下手にやらないだけで十分です。 ほとんどのプログラマーは、システムの設計が不適切だった部分を経験したことがあります。しかし、さらに悲しいことに、皆さんのほとんどは、自分がそのようなシステムの作成者だったことに気づくという悲しい経験をしているでしょう。私たちは最高のものを望んでいまし
モジュール型ソフトウェア アーキテクチャ
モジュール 3
レベル 14、
レッスン 5
6.1 分解 基準はさまざまですが、大規模システムの開発における主なタスクは、システムの複雑さを軽減することです。複雑さを軽減するためには、パーツに分割すること以外はまだ発明されていません。 わかりやすくするために、これを「分割統治」の原則と呼ぶことがありますが、ソフトウェア アーキテクトの観点からは、階層分解について話しています。 複雑なシステムは、少数の単純なサブシステムから構築する必要があります。各サブシステムは、さらに小さな部品から構築され、最小の部品が直接理解して作
正しいソフトウェア分解
モジュール 3
レベル 14、
レッスン 6
階層分解 アプリケーションのクラスの作成をすぐに開始しないでください。まず設計する必要があります。設計は思慮深いアーキテクチャで終わる必要があります。そして、このアーキテクチャを実現するには、システムを一貫して分解する必要があります。 分解は階層的に実行する必要があります。まず、システムは、その動作を最も一般的な形式で記述する大きな機能モジュール/サブシステムに分割されます。次に、結果のモジュールがより詳細に分析され、サブモジュールまたはオブジェクトに分割されます。 オブジェ
ソフトウェアモジュール間の結合を緩める方法
モジュール 3
レベル 14、
レッスン 7
8.1 分解がすべて わかりやすくするために、優れた記事「オブジェクト指向システムの分離」からの図で、これから説明する主な点を示しています。 アプリケーション アーキテクチャの設計は簡単だとまだ思っていますか? 8.2 インターフェース、実装の隠蔽 システムの結合を減らすための主な原理は、OOP の原理と、その背後にあるカプセル化 + 抽象化 + ポリモーフィズムの原理です。 それが理由です: モジュールは相互に「ブラック ボックス」である必要があります (カプセル化)。これ
依存関係の逆転
モジュール 3
レベル 14、
レッスン 8
9.1 依存関係の逆転 以前、サーバー アプリケーションでは単にストリームを作成することはできないと述べたことを覚えていますかnew Thread().start()? コンテナのみがスレッドを作成する必要があります。今後はこのアイデアをさらに発展させていきます。 すべてのオブジェクトもコンテナによってのみ作成される必要があります。もちろん、すべてのオブジェクトについて話しているのではなく、いわゆるビジネス オブジェクトについて話しています。ビンとも呼ばれることがよくあります
ソフトウェアモジュールをリンクする別の方法
モジュール 3
レベル 14、
レッスン 9
直接の依存関係をメッセージングに置き換える 場合によっては、モジュールで何らかのイベント/変更が発生したことを他のモジュールに通知する必要があるだけで、この情報が後でどうなるかは問題ではありません。 この場合、モジュールは「お互いのことを知っている」必要はまったくありません。つまり、直接リンクが含まれて直接対話する必要はありませんが、メッセージ (メッセージ) またはイベント (イベント) を交換するだけで十分です。 メッセージングを介したモジュール通信は、直接の依存関係より
ソフトウェアのライフサイクル
モジュール 3
レベル 15、
レッスン 0
ソフトウェア製品のライフサイクルの段階 高品質のソフトウェアの開発には、有能なチーム、ワークフロー計画、顧客の期待への製品コンプライアンス、期限の遵守など、多くの要素が必要です。 1. 要件分析 この段階は最も重要な段階の 1 つと考えられます。プロジェクトの成功はそれにかかっています。すべてはプロジェクトの目標を設定することから始まります。次に、完了すべきタスクのリストと将来のソフトウェアの範囲が記載されます。その後、プロジェクトの条件、期限、予算を明確にします。第 1 段
ウォーターフォール - ウォーターフォール モデル
モジュール 3
レベル 15、
レッスン 1
カスケードモデルデバイス ウォーターフォール モデルはウォーターフォールとしても知られ、ソフトウェア開発への最もよく知られたアプローチの 1 つです。モデルの作者はウィンストン・ロイスです。1970 年、彼はその長所と短所を詳しく説明した記事でそのイノベーションの本質を説明しました。同じ場所で、彼はこのモデルを反復モデルにどのように改良できるかについて説明しました。ウォーターフォール モデルでは、最初は次の順序で開発段階が進みます。 要件の定義と調整。 プロジェクトの承認。
アジャイル開発手法 - アジャイル
モジュール 3
レベル 15、
レッスン 2
アジャイルモデル 柔軟な (アジャイル) 方法論は、ワークフローをいくつかの小さなサイクルに移行することで、ソフトウェア開発のリスクを軽減します。これらのサイクルは反復と呼ばれ、通常は 2 ~ 3 週間続きます。 イテレーションは、タスクごとに機能を向上させる、複数のタスクで構成される小さなソフトウェア プロジェクトのようなものです。これらには、計画の作成、要件の評価、プロジェクトへの同意、コードの作成、テスト、技術文書の作成が含まれます。 通常、本格的なソフトウェア リリー
スクラムの概要
モジュール 3
レベル 15、
レッスン 3
スクラムの歴史 1970 年にウィンストン ロイスの「大規模ソフトウェア システム開発の管理」レポートが出版されて以来、多くの人がウォーターフォール開発モデルの欠点を解消できる方法論を見つけようと試みてきました。「ウォーターフォール」に代わる方法は、これから説明するスクラム手法でした。 スクラムという名前は、1986 年に竹内と野明の著作『新製品開発の新しいルール』に由来しています。この文書では、目標を達成するための最も効果的な方法は、開発者に明確な行動計画を与えることである
スクラムの使用
モジュール 3
レベル 15、
レッスン 4
ユーザーストーリー ユーザー ストーリーは、開発中のソフトウェアの要件を述べる効果的な方法です。このようなストーリーには、ソフトウェアのユーザーを代表する簡単なアドバイスが含まれています。 スクラム方法論では、目標の設定は通常、顧客またはソフトウェア所有者の特権であるため、開発プロセスに影響を与える主な方法とみなされます。各ユーザー ストーリーには、テキストの量とプレゼンテーションの複雑さに制限があります。歴史は小さな紙に書かれることがほとんどですが、それ自体が量を制限します
さらに表示
1
...
30
31
32
33
34
35
Please enable JavaScript to continue using this application.