Weitere ähnliche Inhalte Ähnlich wie Software design and team design (20) Mehr von Kenji Hiranabe (20) Software design and team design3. ⾃⼰紹介
• ㈱永和システムマネジメント
– 福井市(本社)、神⽥東京(⽀社)、沖縄(事務所)
– 「⾦融」、「医療」、「組込みシステム」開発
– 「Ruby と Agile」を使ったシステム開発
• 株式会社チェンジビジョン
– 福井市(開発部)、神⽥東京(本社)
– astah* (旧:JUDE) の開発
• 平鍋健児
– UML+マインドマップエディタ astah*の開発
– 要求開発アライアンス、理事
– 初代 Agile Japan 実⾏委員⻑
– 翻訳、XP関連書籍、『リーン開発の本質』
『IMPACT MAPPING』等多数。
– 著書『アジャイル開発とスクラム』、『要求開発』
『ソフトウェア開発に役⽴つマインドマップ』
3
8. The Art of Readable Code
鍵となるアイディア
• コードは理解しやすくなければならない
• 他⼈が短時間で理解できるように
• 第1章 理解しやすいコード
8
9. 第 I 部 表⾯上の改善
• 2章 名前に情報を詰め込む
• 3章 誤解されない名前
• 4章 美しさ
• 5章 コメントすべきことを知る
• 6章 コメントは正確で簡潔に
9
10. 名前に情報を詰め込む
• 類語辞典(Thesaurus)でもっとカラフルな
(意図を明確に伝えられる)名前を探す
単語 代替案
send deliver, dispatch, announce, distribute, route
find search, extract, locate, recover
start launch, create, begin, open
make create, setup, build, generate, compose,
add, new
鍵となるアイディア
• 明確で正確な情報密度の⾼い名前を探す努⼒を
惜しまない。
10
17. 第III部 コードの再構成
• 10章 無関係の下位問題を抽出する
• 11章 ⼀度にひとつのことを
• 12章 コードに思いをこめる
• 13章 短いコードを書く
• 14章 テストと読みやすさ
17
18. その他のトピック抜粋
• ヨーダ記法
• ガード節
• 説明変数
• ブロックスコープ
• メソッドの抽出
• テストに優しい開発
If line.split(' :' )[0].strip() == "root" { }
⇨
username = line.split(':’)[0].strip();
If (username == “root”) { }
// YODA notation
if (NULL == object) // old style
public bool contains(string str) {
if (str == null) return false;
// do what you do
18
22. Design Patterns
Elements of Reusable Object-Oriented Software
• ソフトウェア分野のベストセラー (1995) by
GoF(Gang of Four)/Erich Gamma, Richard Helm,
Ralph Johnson and John Vlissides, foreword by
Grady Booch.
• 建築家、Christopher Alexander の「パターン⾔語」
をWard Cunningham/Kent Beck/Grady Booch らが
最初に先導(Hillside Group)。
• 後のアジャイル(XP, Scrum)にもつながる。
• 厳格なフォーマット(いくつか流儀がある)に則って
いる。
• 過去に繰り返し使われた、典型的な設計解を、「⽂
脈」(Context)「問題」(Problem)「解決策」
(Solution)の組みにして、名前(Name)をつけたもの。
22
27. 1 ⾃⽴地域
2 町の分布
3 フィンガー状の都市と⽥園
4 農業渓⾕
5 レース状の⽥園道路
6 ⽥舎町
7 ⽥園
8 モザイク状のサブカルチャー
9 仕事場の分散
10 都市の魔⼒
11 地区交通区域
12 7000⼈のコミュニティ
13 サブカルチャーの境界
14 ⾒分けやすい近隣
15 近隣の境界
16 公共輸送網
17 環状道路
18 学習のネットワーク
19 商店網
20 ミニバス
21 4階建の制限
22 9パーセントの駐⾞場
23 平⾏道路
24 聖地
25 ⽔への近接
26 ライフサイクル
27 男と⼥
28 中⼼をはずれた核
29 密度のリング
30 活動の節点
31 プロムナード
32 買物道路
33 ナイトライフ
34 乗りかえ地点
35 世帯の混合
36 公共度の変化
37 住宅クラスター
38 連続住宅
39 段状住宅
40 どこにも⽼⼈
41 仕事コミュニティ
42 ⼯業の帯
43 市場のような⼤学
44 地区タウンホール
45 コミュニティ活動の輪
46 多店舗マーケット
47 保健センター
48 あいだの家
49 ループ状の地区道路
50 T字路
51 緑路
52 ⼈と⾞のネットワーク
53 ⼤きな⾨⼝
54 横断道路
55 ⼩⾼い歩道
56 ⾃転⾞路と置場
57 都市の⼦供
58 カーニバル
59 静かな奥
60 ⼿近な緑
61 ⼩さな広場
62 ⼩⾼い場所
63 街頭の踊り
64 池と⼩川
65 出産所
66 聖域
67 共有地
68 つながった遊び場
69 公共⼾外室
70 墓地
71 泳げる⽔
72 地区スポーツ
73 冒険遊び場
74 動物
75 家族
76 ⼩家族の家
77 ふたりの家
78 ひとりの家
79 ⾃分だけの住まい
80 ⾃主管理の作業場とオフィス
81 形式ぬきの⼩さな窓⼝
82 事務室のつながり
83 師匠と弟⼦
84 ⼗代の社会
85 店先学校
86 ⼦供の家
87 個⼈商店
88 路上カフェ
89 ⾓の⽇⽤店
90 ビアホール
91 旅⼈の宿
92 バス停
93 屋台
94 ⼈前の居眠り
パタン⾔語(町)
27
28. 95複合建物
96 階数
97 ⾒えない駐⾞場
98 段階的な動線領域
99 おも屋
100 歩⾏者道路
101 通りぬけ街路
102 ⾒分けやすい⼊り⼝
の集まり
103 ⼩さな駐⾞場
104 敷地の修復
105 南向きの屋外
106 正の屋外空間
107 光の⼊る棟
108 つながった建物
109 細⻑い家
110 正⾯⽞関
111 ⾒えがくれの庭
112 ⼊⼝での転換
113 ⾞との接続
114 段階的な屋外空間
115 ⽣き⽣きとした中庭
116 カスケード状の屋根
117 守りの屋根
118 屋上庭
119 アーケード
120 歩⾏路と⽬標
121 歩⾏路の形
122 建物の正⾯
123 歩⾏者密度
124 ⼩さな⼈だまり
125 座れる階段
126 ほぼ中央の焦点
127 親密度の変化
128 屋内の陽光
129 中⼼部の共域
130 ⽞関室
131 通りぬけ部屋
132 短い廊下
133 舞台のような階段
134 禅窓
135 明暗のタピストリー
136 夫婦の領⼟
137 ⼦供の領⼟
138 東まくら
139 農家⾵キッチン
140 街路を⾒おろすテラス
141 ⾃分だけの部屋
142 くつろぎ空間の連続
143 ベッド・クラスター
144 ⼊浴室
145 ⼤物倉庫
146 柔軟な事務空間
147 会⾷
148 ⼩さな作業集団
149 親しみやすい受付
150 待ち合わせ場所
151 ⼩さな集会室
152 半私的な事務室
153 貸せる部屋
154 ⼗代の離れ
155 ⽼⼈の離れ
156 腰をすえた仕事
157 家庭ワークショップ
158 ⻘空階段
159 どの部屋も⼆⾯採光
160 建物の外縁
161 ⽇のあたる場所
162 北の⾯
163 ⼾外室
164 道路にむかう窓
165 街路への開⼝
166 外廊
167 ⼀間バルコニー
168 ⼤地へのなじみ
169 段上の斜⾯
170 果樹
171 ⽊のある場所
172 野⽣の庭
173 庭囲い
174 格⼦棚の散歩道
175 温室
176 庭の腰掛
177 菜園
178 コンポスト
179 アルコーブ
180 窓のある場所
181 炉⽕
182 ⾷事の雰囲気
183 作業空間の囲い
184 台所のレイアウト
185 くるま座
186 ざこ寝
187 ふたりのベッド
188 ベッド・アルコーブ
189 着がえ室
190 天井⾼の変化
191 屋内空間の形
192 ⽣活を⾒おろす窓
193 半開の壁
194 室内窓
195 階段の容積
196 隅のドア
197 厚い壁
198 部屋ざかいのクロゼット
199 ⽇のあたるカウンター
200 浅い棚
201 腰⾼の棚
202 造りつけの腰掛
203 ちびっ⼦のほら⽳
204 開かずの間
パタン⾔語(建物)
28
29. 205 ⽣活空間に
したがう構造
206 無駄のない構造
207 ふさわしい材料
208 順に固める構造
209 部屋の割り付け
210 床と天井の割り付け
211 外壁の厚み
212 隅の柱
213 補強柱の配分
214 根のような基礎
215 ⼀階の床版
216 ボックス柱
217 がわ梁
218 構造膜
219 床・天井ヴォールト
220 屋根ヴォールト
221 ⾃然なドアと窓
222 低い窓台
223 深い窓枠
224 低い⼾⼝
225 厚い縁どりの枠
226 柱のある場所
227 柱の接合部
228 階段ヴォールト
229 配管スペース
230 輻射暖房
231 屋根窓
232 屋根飾り
233 床⾯
234 重ね張りの外壁
235 柔らかい内壁
236 いっぱいに開く窓
237 ⼩窓つきの厚いドア
238 柔らげた光
239 ⼩割りの窓ガラス
240 半インチの⾒切り縁
241 腰掛の位置
242 ⽞関先のベンチ
243 座れるさかい壁
244 キャンバス屋根
245 さわれる花
246 つる植物
247 すき間だらけの舗⽯
248 柔らかいタイルと
レンガ
249 装飾
250 暖かい⾊
251 まちまちの椅⼦
252 明かりだまり
253 ⾃分を語る⼩物
パタン⾔語(施⼯)
29
33. • Pattern Oriented Software Design(POSA)
• Clean Architecture, Domain Driven Design
アーキテクチャ
• Analysis Patterns, Real-Time UML(3rd)
分析
• Design Patterns(GoF), Real-Time Design Patterns
設計
• Smalltalk Best Practice Patterns, Advanced C++, CODE COMPLETE,
Programming Pearls, Test-Driven Development, Refactoring
• Readable Code, Clean Code, Pragmatic Programmers,
Test-Driven Development, Test-Driven Development in Embedded C
コードレベル
ソフトウェアのパターン(粒度⼤→粒度⼩)
• Classics / Modern / Embedded
33
35. デザインパターンの形式
項⽬ 内容
名前 パターンの名前.および後述するカテゴリ
⽬的 解こうとしてる「問題」と「解決」の原理
別名 良く知られた別名
動機 どのような状況で問題が発⽣するか具体例やストーリ
適⽤可能性 どのような状況で適⽤できるか
構造 パターンの構造を⽰すクラス図
構成要素 クラス・オブジェクトの責任分担
協調関係 構成要素がどのように強調するか
結果 パターンが問題の解決にどう貢献するか.トレードオフ
実装 実装にす場合の注意点
サンプル
コード
コードの例⽰
使⽤例 実際のシステムで利⽤されている例
関連するパ
ターン
他の密接に関連するパターン
35
46. Pictures by Derick Bailey
https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ 46
47. SOLID
• Single Responsibility Principle SRP
• Open-Closed Principle OCP
• Liskov Substitution Principle LSP
• Interface Segregation Principle ISP
• Dependency Inversion Principle DIP
By Robert C. Martin
47
52. typedef struct { int x, y; } Point;
typedef struct { Point p1, p2; } Line;
typedef enum { LINE, POINT } Kind;
typedef union { Point* point; Line* line; } ShapeUnion;
typedef struct {
Kind kind;
ShapeUnion of;
} Shape;
void draw(Shape* shape) {
switch(shape->kind) {
case LINE:
/* draw line (shape->of->line.p1 ---- shape->of->line.p2) */
break;
case POINT:
/* draw point (shape->of->point)*/
break;
}
}
コードを変更しないと拡張できないコード
52
53. // shape.h
class Shape {
public:
virtual void draw() const = 0;
};
コードを変更しなくても(再コンパイルもなしで)拡張できるコード
※ただし、LSPを満たしていることが条件(”Line” is-a “Shape”)
// point.h
#include “shape.h”
class Point : public Shape {
int x, y;
public:
void draw() const { /* draw point (x,y) */ }
};
// line.h
#include “shape.h”
class Line : public Shape {
Point p1, p2;
public:
void draw() const { /* draw line p1-p2 */ }
};
53
56. #include “shape.h”
void drawAllShapes
(const vector<const Shape*>& shapes) {
for (const Shape *s: shapes)
s->draw();
}
このコードは、Shape の派⽣クラスのどんなものが渡ってきても、その知識なしに
動作しなければならない。そのように、Shape とその派⽣クラスは設計されて
いなければならない。
※どのような派⽣クラスがShapeに追加されようが、この関数は再コンパイル
なしで動作する。(C++/Javaでは、プログラマが設計したクラス階層をコンパイ
ラが補助する。) 56
61. DIP(Dependency Inversion Principle)
定義
実装の具体に依存してはならない。抽象に
依存せよ (Depend on abstractions, not on
concretions.)
※特にフレームワークの設計などでは、「呼び出しの⽅向」と「依存の⽅向」が逆転
することがあります。現代的には、テスト容易性を⾼めるために、”Inversion of
Control”や”Dependency Injection”といった⼿法が使われます。昔は、関数ポインタ
を渡すことで下位のレイヤから上位のモジュールを「コールバック」してもらう、と
いう⼿法がよく取られました。現代では、Observerパターンでインターフェイス(こ
こでいう抽象)に依存させて呼び出しと依存の向きを反転させます。
ちなみに、コールバックはJavaではListener、C#ではdelegateと呼ばれます。
61
75. Pipes and Filters
• Pipes and Filtersアーキテクチャパターンは,
データをストリームとして扱うシステムのため
の構造を提供する. 個々の処理ステップは,1
つのフィルタコンポーネントにカプセル化され,
データはこれらの隣接するフィルタ間をパイプ
コンポーネントを介して引き渡される. フィル
タの組み合わせを換えることにより,機能の類
似した⼀連のシステムを作成することができる.
• 適⽤例 UNIX のコマンドとパイプ、テキスト
75
80. 変わっていない重要な
Design Concepts(Evergreen)
70s 70s-80s 80s-90s-2000s
構造化プログラミング 構造設計設計・分析 オブジェクト指向設計
E.Wdijkstra
Harlan Mills
Hoare
Larry Constantine
Ed Yordon
David Parnus
Tom Demarco
Bertrand Meyer
Grady Booch
James Rambaugh
Ivar Jacobson
DFD, ERD UML(統⼀された)
• “GOTO harmfull”
• TOP-down design
(現在も層構造とし
て)
• Divide by Structure
• Divide and Conquer
• Separation of
Concerns(関⼼事の分離)
• Information Hiding
(情報隠蔽)
• Abstraction(抽象化)
• High Cohesion/
Low Coupling
(結合度と凝集度)
• Divide by Responsibility
• Module→ADT(→Class)
• Encapsulation
(カプセル化)
• Class and Object
• Polymorphism(多態性)
• Inheritance/Subtyping
(継承/サブタイプ)
• Use Case
• Domain Model
• Software Patterns
※2000以降についてはアジャイルで詳述(Divide by Value、テスト性)など 80
89. Conway’s Law
“organizations which design systems … are constrained
to produce designs which are copies of the
communication structures of these organizations”
— M. Conway
”組織の構造がソ
フトウェアの構
造に反映する“
であれば、よい組織構造をつくろう。
(Inverse Conway Maneuver) 89
99. 99
分割の仕⽅
• 顧客に分かる機能で切る。
• 層で切らない。
• ビジネスの価値が分かる。
“These days we do not program software
module by module; We program software
feature by feature.”
—Mary Poppendieck
by Akiyah“Divide by Value”
—Tom Gilb
116. 116
• Write a test
• Watch it fail
• Make it pass
• Refactor
(improve)
• Repeat until
done
T
D
D
• テストを書く
• 失敗することを確認
• 通過させる
• リファクタリング(改善)
• 繰り返す
127. バーンダウンチャート
• 進捗の見える化
– バーンダウン(下向き)
– タスクかんばんと連動
– 中間成果物で
は計測しない。
– メールでエクセルシート
を配布したり、
サーバに置いたから
見てね、はナシ。
バーンダウンチャートの例
全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT
(協力:永和システムマネジメント:チーム角谷)
127