-
Notifications
You must be signed in to change notification settings - Fork 0
400_001 プログラム設計ガイドライン
1. 導入
2. プログラム設計の範囲
3. 戦略的設計について
4. アーキテクチャの選定
5. プログラム設計の進め方
6. 例外について
7. 成果物について
設計を大別して下記の2つに分類する。
・仕様の設計
・ソースコードの設計
ユーザから見た画面や動作、導線、使う時にどう動作すべきか決めることを指す。
つまり、ソフトウェアの振る舞いを設計する。
仕様を実現するために、どのようにソースコードを実装していくか方針を決めることを指す。
ここでは、ソースコードの設計のガイドラインを記載するものとする。
以降、プログラム設計と呼ぶ。
プログラム設計には、下記の2つのレベルがある。
・戦略的設計
・戦術的設計
責務の観点から考えられるクラス設計を行う。
具体的には、クラス名やその責務、そのクラスと協調するクラスを決めることを指す。
戦略的設計をもとに、メソッド（パラメタ）、フィードル変数等の詳細な情報を決めることを指す。
なお、弊社ではプログラム設計を戦略的設計までに留め、戦術的設計まで実施しないこととする。
但し、コーディング時にメソッドにはコメントを記載すること
/// ◯◯を生成するメソッド
///
/// - Parameter parameter: ◯◯◯
/// - Returns: ◯◯◯
func hoge(parameter: String) -> String{
return ""
}
戦略的設計で決めることは、下記の3点とする。
| No. | 設計内容 | 説明 |
|---|---|---|
| 1. | クラス名 | クラス名を決める。 |
| 2. | 責務 | そのクラスがすべき仕事を決める。 （責務の境界線を決める。） |
| 3. | 協調クラス | そのクラスが責務を果たすために協調するクラスを決める。 |
なお、プログラム設計は正確であって、精密でなくてもよい。
アーキテクチャの選定は、チーム規模やメンバーのスキルセットによって判断すること。
Appleのアーキテクチャ(MVC)
https://www.objc.io/issues/13-architecture/mvvm/
├─ Models
├─ ViewModels
├─ Views
├─ Controllers
http://blog.tai2.net/the_clean_architecture.html
├─ Data
├─ Domain
├─ Presentation
├─ Util
アーキテクチャの選定後、下位レイヤーから順に設計していくこと。
例）MVCを採用した場合
Model → ViewController → Viewの順で設計を進める。
複数のクラスと協調するクラスを作成または、変更を加える場合は、
担当者間でコミニュケーションをとること。
また、クラス図を作成し、影響範囲を十分に調査した上で進めること。
継承関係のあるクラスは、デグレードを起こしやすいので注意が必要。
| 分類 | 説明 |
|---|---|
| 例外 | プログラムのバグ等により、システム上の不具合が発生したときに発生するものとする。 (開発者にログ情報として、伝える必要がある。) |
| エラー | パスワード入力ミスなどにより、ヒューマンエラーが起因するものを指すものとする。 (ユーザーにアラート等を利用して、視覚的に伝える必要がある。) |
・なるべく例外で処理を止めない。(アプリを落とさない）
・例外を特定できる場合は、その例外を個別にcatchする。
・例外のcatchは、可能な限り狭い範囲でcatchし、上位層にthrowしない。
・例外のトレースは、スタックトレースに任せる。(必要なログ情報が埋もれるのを避けるため。)