Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Application Design 勉強会 #2
Search
Kazuki Chigita
June 26, 2019
Technology
1
220
Application Design 勉強会 #2
Application Application Design 勉強会 #2
Kazuki Chigita
June 26, 2019
Tweet
Share
More Decks by Kazuki Chigita
See All by Kazuki Chigita
Building Android and looking into the Android System
chigichan24
2
3.9k
DroidKaigiカンファレンスアプリの歴史からみるアプリアーキテクチャのこれまでとこれから
chigichan24
3
3.1k
継続的に機能開発を進めながら行うマルチモジュール化
chigichan24
2
5.7k
Application Design 勉強会 #12
chigichan24
0
55
Application Design 勉強会 #10
chigichan24
0
82
Application Design 勉強会 #6
chigichan24
0
160
Application Design 勉強会 #4
chigichan24
0
150
Read DroidKaigi2019 app source code
chigichan24
1
380
Battle of GridLayout with RecyclerView
chigichan24
0
260
Other Decks in Technology
See All in Technology
Understanding and Optimising INP
akshayysharma
0
150
RAGの性能を評価しよう
kurahara
1
300
ドメインと向き合う - 旅行予約編
hidenorigoto
4
530
山手線一周のパフォーマンス改善
suzukahr
0
120
Oracle GoldenGate 23ai 導入Tips
oracle4engineer
PRO
1
220
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
370
過去のインプットとアウトプットを振り返る
diggymo
0
100
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
13k
Strict Concurrencyにしたらdeinitでクラッシュする話
0si43
0
120
Hazard pointers with reference counter
ennael
PRO
0
120
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
13k
小さな勉強会の始め方、広げ方、あるいは友達の作り方 / How to Start, Grow, and Build Connections with Small Study Groups
ar_tama
4
2k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.1k
Producing Creativity
orderedlist
PRO
341
39k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
59k
Rails Girls Zürich Keynote
gr2m
93
13k
How GitHub (no longer) Works
holman
311
140k
Writing Fast Ruby
sferik
625
60k
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
Embracing the Ebb and Flow
colly
83
4.4k
The Pragmatic Product Professional
lauravandoore
31
6.2k
Building a Scalable Design System with Sketch
lauravandoore
459
32k
RailsConf 2023
tenderlove
28
840
Transcript
Application Design 勉強会 #2 Wed Jun 26 Kazuki Chigita
第7章 アジャイル設計
アジャイル開発の考え - アジャイル開発での全体像はソフトウェアと共に 展開していく. - 先を見越してデータベースの設計はしないし,将来の要求に 時間を掛けない. -
各イテレーションで「今」を最良の構造にし,常に「今」と同じ レベルの品質を保つ.
アジャイル設計ってなに? - アジャイル開発で用いる 設計 手法 - つまり,どういうソースコードであるべきかが 「設計」だ (著者談)
- なぜアジャイル設計をするのか? - ソフトウェアはアジャイル開発のイテレーションを 通して変化し続ける. - これに追従して設計をしないと「悪臭」がする. - 「悪臭」がすると,保守がしづらくなったり,機能追加に多大 な工数がかかったりする. UMLダイアグラムのような抽象 的に表現する技法での 設計ではなく,これを具体化した ソースコード自身のこと. だから,設計をしなければならない.
悪臭の例 1. 硬さ 変更しにくいシステム.1つの変更のためにそれと依存関係に あるモジュールが芋づる式に変更点があらわれること. 2. もろさ 1つの変更によって,概念的に関連のない箇所までもが壊れて しまうシステム.
3. 移植性のなさ 他のシステムで利用価値のある部分をモジュールとして切り出すことが 難しい状態. 4. 扱いにくさ ソフトウェアの扱いにくさ,開発環境の扱いにくさ. 5. 不必要な複雑さ 設計時に不必要な仕様を取り込んでいる(アジャイル開発の考えに反し ている) 6. 不必要な繰り返し 別モジュールからコピペしてきたものを含んでいる. 抽象化すべき. 7. 不透明さ わかりにくいモジュールが存在する状態.
何がソフトウェアを腐敗させるのか? - 仕様変更に追従できなくなったときにソフトウェアが 腐る. - 仕様変更に追従できない→設計に問題がある→ アジャイル開発に耐えうる設計やプラクティスを実践するべき -
アジャイルチームはソフトウェアの腐敗を許すな. - じゃあどうすれば?→クリーンな設計やプラクティスを実践す るべき. - クリーンな設計やプラクティスを以降の章で紹介.
第8章 単一責任の原則(SRP)
単一責任の原則 (SRP : Single Responsibility Principle) - SOLID原則の一角を成す. -
日本語での説明 - クラスを変更する理由は2つ以上存在してはならない - 本には1つ以上と書いてあるけど,多分違う.
Rectangleクラスの例 - Geometry applicationが演算処理のためにRectangleクラスを 参照する. - Graphical ApplicationはGUIへの描画のためにRectangleクラ スを参照する.
Geometry Application GUI Graphical Application Rectangle +draw() +area(): double
SRP違反の改善 - この状況下でのRectangleの役割 1. 数学的なモデルを提供する役割 2. GUIで四角形を塗りつぶす役割 - 悪臭シリーズでいうところの扱いにくさ
- Geometry applicationが不必要にGUIを含む構図に なっている. - GUI都合で表示するものが変わったときに無関係なGeometry Applicationも変更の必要が生まれる. - 解決策は,演算部分を切り出す(抽象化してinterfaceを切り出 す操作と言える) Geometry Application GUI Graphical Application Rectangle +draw() +area(): double
SRP違反の改善 Geometry Application GUI Graphical Application Rectangle +draw() +area(): double
Geometry Application GUI Graphical Application Rectangle +draw() Geometric Rectangle +area(): double
単一責任の原則の「責任」とはなにか? - 「責任 = 役割 = 変更理由」と定義している. - クラスの変更理由は1であるべき
<=> クラスの変更理由が2つ 以上ある場合そのクラスには2つ以上の役割がある.
単一責任の原則の適用を見極める - 役割が2つ以上あるときに分離するのが基本. - しかし,異なる役割ながら,必ず同時に変更が生じる役割は 分離する必要なない. <=> 複数の役割が結合する理由を持っている事がある.
- 過剰な適用は設計を不必要に複雑にする. - これは他の原則でも不必要な適用は良くない. - 「変更の理由が変更の理由たるのは,"実際に"変更の理由 が生じる場合だけ」
第9章 オープンクローズドの 原則
オープンクローズドの原則 (OCP : Open-Closed Principle) - 拡張に対して開かれている(Open) モジュールの振る舞いを拡張できる. 追加の仕様要求がきてもモジュールに新たな振る舞いを 追加することでその変更に対処できる.
- 修正に対して閉じている(Closed) モジュールの振る舞いを修正しても,そのモジュールの ソースコードやバイナリは影響をうけない. これはなんか矛盾している概念に見えるがなんとかなる.
client-serverの例 - Client,Serverともに具体的な実装を持っている. - Serverの実装が変更されるとClientも変更せざるを えない.(OCP違反) Client Server
解決策1 : 抽象を利用することでOCPを実現(Strategy pattern) - 依存部分をinterfaceとして切り出す. - server abstractにしない理由→抽象クラスはそれを実装す
る側より使う側のほうが関係が密接だから. - Serverの実装が変わってもClientは影響を受けない. Client <<interface>> Client Interface Server
解決策1 : 抽象を利用することでOCPを実現(Strategy pattern) - 依存部分をinterfaceとして切り出す. - server abstractにしない理由→抽象クラスはそれを実装す
る側より使う側のほうが関係が密接だから. - Serverの実装が変わってもClientは影響を受けない. Client <<interface>> Client Interface Server Piyo
解決策2 : 抽象を利用することでOCPを実現(Template Method Pattern) - Policyクラス(方針クラス)は具体的な実装を持っている(一つ 前のClientに対応). と同時に,抽象メソッドを持っている.(Client interfaceに対応)
- Policyクラスの抽象メソッドを実装する実装クラスが ある(Serverに対応) Policy + PolicyFunction() - ServiceFunction() Implementation - ServiceFunction()
OCPの実現 - Strategy Pattern , Template Method Patternが 典型的.
- 汎用的な機能と,その機能の具体的な実装を明確に 分離する役割を持つ. - 使い所 : 最も変更されるプログラム部分にだけ的を 絞って抽象化を適用するように務める (早まった抽象をしないことも抽象を使うのと同等に 重要なこと)
参考資料 - アジャイルソフトウェア開発の奥義 - ロバート・C・マーチン - pp. 103 - 141