Software design and team design
•
24 gostaram•6,897 visualizações
Good Software Design, Good Team Design
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Software design and team design
Semelhante a Software design and team design (20)
Mais de Kenji Hiranabe
Mais de Kenji Hiranabe (20)
Software design and team design
- 1. ソフトウェアデザイン チームデザイン ー Software Design and Team Design ー 株式会社永和システムマネジメント 株式会社チェンジビジョン 平鍋健児 1
- 2. 今⽇のお話の地図 2
- 3. ⾃⼰紹介 • ㈱永和システムマネジメント – 福井市（本社）、神⽥東京（⽀社）、沖縄（事務所） – 「⾦融」、「医療」、「組込みシステム」開発 – 「Ruby と Agile」を使ったシステム開発 • 株式会社チェンジビジョン – 福井市（開発部）、神⽥東京（本社） – astah* (旧：JUDE) の開発 • 平鍋健児 – UML+マインドマップエディタ astah*の開発 – 要求開発アライアンス、理事 – 初代 Agile Japan 実⾏委員⻑ – 翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に役⽴つマインドマップ』 3
- 4. 『アジャイル開発とスクラム』 • 顧客・技術・経営の３者をつなぐ ために、アジャイルと⽇本経営の 接合点を探る • 海兵隊の組織とアジャイル • 知識創造プロセスとアジャイル • 実践知リーダーとアジャイル • 富⼠通・楽天・リクルートの事例 • Jeff Sutherlandインタビュー 平鍋健児＋野中郁次郎著 4
- 5. 5
- 6. The Art of Readable Code 6
- 7. 7
- 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
- 11. 11
- 12. 名前に情報を詰め込む • スコープが⼩さければ短い名前でもいい – i, j, k はループの変数として使ってよい – tmp, data, info, retval はほとんどダメ – ブロックスコープを利⽤する • ⻑い名前を⼊⼒するのは問題じゃない – (現代のエディタ、IDEなら) 12
- 13. コメントすべきことを知る • Director’s Commentary（背景情報や意図 (Why)、設計判断(Design Decisions)、別⼿法 の検討、苦労など）。他の⼈が⾒た時に「な んでこうしたか？」という疑問をもたせない ようにする。 • アルゴリズム調査した本や記事の出展など。 鍵となるアイディア • コメントの⽬的は書き⼿の意図を読み⼿に知ら せること。 13
- 14. 14
- 15. コメントすべきことを知る • コードから明らかに分かることをコメン トに書かない（例：コンスタクタ） • できるだけ変数名や関数名で表す。 – コードブロックにコメントするなら、抜き出 して関数化し、良い名前をつける – 中間に意図を表現する説明変数を使う • コードの⽋陥を認める（パフォーマンス やアルゴリズムの選定）コメントしてお く。 15
- 16. 第II部 ループとロジックの単純化 • 7章 制御フローを読みやすくする • 8章 巨⼤な式を分割する • 9章 変数と読みやすさ 16
- 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
- 19. あわせて読みたい 19 Classic Classic Classic Classic
- 20. 20
- 21. Design Patterns Elements of Reusable Object-Oriented Software 21 Classic
- 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
- 23. 建築の⽅をチラ⾒ 23
- 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
- 31. 31
- 32. 32
- 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
- 34. Design Patterns Elements of Reusable Object-Oriented Software 34 Classic
- 35. デザインパターンの形式 項⽬ 内容 名前 パターンの名前．および後述するカテゴリ ⽬的 解こうとしてる「問題」と「解決」の原理 別名 良く知られた別名 動機 どのような状況で問題が発⽣するか具体例やストーリ 適⽤可能性 どのような状況で適⽤できるか 構造 パターンの構造を⽰すクラス図 構成要素 クラス・オブジェクトの責任分担 協調関係 構成要素がどのように強調するか 結果 パターンが問題の解決にどう貢献するか．トレードオフ 実装 実装にす場合の注意点 サンプル コード コードの例⽰ 使⽤例 実際のシステムで利⽤されている例 関連するパ ターン 他の密接に関連するパターン 35
- 36. 例: Singleton • 「⽬的」 “あるクラスに対してインスタンスが１つしか存在しないことを保証し，そ れにアクセスするためのグローバルな⽅法を提供する．” ここには，「クラスに対してインスタンスが１つしか存在しないことを保証す るには， どうしたらよいか」という問題が書かれている．しかし，このよう な問題の記述は抽象的であることが多く， パターンによっては理解するのが 難しい場合もある．「問題」の理解を助けるのが， 「動機」の記述である． 「動機」は，実際にそのような問題が起こる状況， すなわち⽂脈が，具体的 な例を伴って書かれている． • 「動機」 そのような状況の説明、その例として，プリンタスプーラ，ファイルシス テム， ウィンドウマネージャ，などの例が挙げられている． まず「⽬的」と「動機」を読み， そのパターンが解こうとしている「問題」 とそれが発⽣する「⽂脈」を理解する． そして，そのような状況に⾃分が置 かれたときに， このパターンを思い出せるようにしておく必要がある． 36
- 37. 37http://p-monster.hatenablog.com/archive/category/デザインパターン Singleton (例：ウィンドウマネジャ) たった⼀つのインスタンスを保証 • Singleton Class • インスタンスが１個しか存在しないことをプログラム 上で表現するには、コンストラクタをプライベートに し、外部でnewできなくする。 • ⾃分⾃⾝のインスタンスをstaticで持ち、コンストラク タを⾮公開にする。Singleton の getInstance() で、 staticでたった⼀つのインスタンスへの参照をクライア ントに返す。 • [⽬的] あるクラスに対してインスタンスが１ つしか存在しないことを保証し，それにアク セスするためのグローバルな⽅法を提供する．
- 38. 23 パターンの分類 38
- 42. 42 組み合わせた例
- 43. 43
- 44. 44
- 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
- 48. 48
- 49. SRP(Single Responsibility Principle) 定義 クラスに変更が起こる理由は、⼀つである べき。(A class should have only one reason to change.) ※元々は、「責務が1つ」であるべきの意味で「凝集度が⾼い」モジュールになる。 現代的には、より具体的に「変更のソース」が2つ以上あるなら、分離せよということ。 49
- 50. 50
- 51. OCP(Open/Close Principle) 定義 クラスは、変更することなく振る舞いを拡 張できなくてはらない(You should be able to extend a classes behavior, without modifying it.) 51 クラスの継承と、多態性をつかうことでクラスを拡張できるしくみ。 Bertrand Meyerの「オブジェクト指向⼊⾨」 が初出。
- 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
- 54. 54
- 55. LSP(Liskov Substitution Principle) 定義 派⽣クラスは、それを利⽤するコードから みて基底クラスと交換可能でなければなら ない (Derived classes must be substitutable for their base classes.) ※基底クラスが型指定してある変数の場所には、将来、そのどの派⽣クラスのイン スタンスが⼊ってきても正しく動作するように、クラス継承の意味を正しく維持し なくてはならない。 55
- 56. #include “shape.h” void drawAllShapes (const vector<const Shape*>& shapes) { for (const Shape *s: shapes) s->draw(); } このコードは、Shape の派⽣クラスのどんなものが渡ってきても、その知識なしに 動作しなければならない。そのように、Shape とその派⽣クラスは設計されて いなければならない。 ※どのような派⽣クラスがShapeに追加されようが、この関数は再コンパイル なしで動作する。（C++/Javaでは、プログラマが設計したクラス階層をコンパイ ラが補助する。） 56
- 57. 57
- 58. ISP(Interface Segregation Principle) 定義 利⽤者は⾃分が使わないメソッドに依存す ることを強制されない(Clients should not forced to depend on methods that they don't use.) ※インターフェイスを太らせてはいけない、別⽤途のインターフェイスは分離せよ。 C++では多重継承もしくは別のアダプタクラス、Java では interface を利⽤。 58
- 60. 60
- 61. DIP(Dependency Inversion Principle) 定義 実装の具体に依存してはならない。抽象に 依存せよ (Depend on abstractions, not on concretions.) ※特にフレームワークの設計などでは、「呼び出しの⽅向」と「依存の⽅向」が逆転 することがあります。現代的には、テスト容易性を⾼めるために、”Inversion of Control”や”Dependency Injection”といった⼿法が使われます。昔は、関数ポインタ を渡すことで下位のレイヤから上位のモジュールを「コールバック」してもらう、と いう⼿法がよく取られました。現代では、Observerパターンでインターフェイス（こ こでいう抽象）に依存させて呼び出しと依存の向きを反転させます。 ちなみに、コールバックはJavaではListener、C#ではdelegateと呼ばれます。 61
- 62. 62
- 68. 68
- 71. • Model-View-Controllerアーキテクチャパターン （MVC）は，対話型アプリケーションを3つのコンポー ネントに分割する．モデルコンポーネントは，アプリ ケーションの中核機能とデータを含むコンポーネントで ある．ビューコンポーネントは，情報をユーザに表⽰す るコンポーネントである．そして，コントローラは， ユーザの⼊⼒を取り扱うコンポーネントである．ユーザ インタフェースを実現するのは，ビューコンポーネント とコントローラコンポーネントである．更新伝播のメカ ニズムによって，ユーザインターフェースとそのモデル との⼀貫性を保証することできる． • 適⽤例 Smalltalk, MFC, ET++, …(さらにWebで多い) Model-View-Controller 71
- 73. Blackboard • Blackboardアーキテクチャパターンは， 決定論的な解決戦略が分かっていない課 題に対して有効である．複数のサブシス テムが持つそれぞれの知⾒を組み合わせ ることによって，部分的，もしくは近似 的に妥当な解を得ることができる． • 適⽤例 HEARSAY-Ⅱ⾳声認識システム 73
- 74. Blackboard 74
- 75. Pipes and Filters • Pipes and Filtersアーキテクチャパターンは， データをストリームとして扱うシステムのため の構造を提供する． 個々の処理ステップは，1 つのフィルタコンポーネントにカプセル化され， データはこれらの隣接するフィルタ間をパイプ コンポーネントを介して引き渡される． フィル タの組み合わせを換えることにより，機能の類 似した⼀連のシステムを作成することができる． • 適⽤例 UNIX のコマンドとパイプ、テキスト 75
- 77. 77
- 78. 構造化分析・設計 オブジェクト指向 分析・設計 RUP(96) Waterfall Agile Manifesto(01) 構造化プログラミング オブジェクト指向プログラミング 関数型プログラミング LISP(58) FORTRAN(57) COBOL(59) Java(95) Ruby(95) Perl(87) Python(91) Pascal(70) Ada(80)C(70) Smalltalk(72) Scala(03) C#(00) Haskell(90)Erlang(86) C++(83) Clojure(07) F#(02) Simula(67) Go(09) 手続型 オブジェクト指向 関数型 アーキテクチャ J2EE(01) RubyOnRails(04) Map/Reduce KVS 大型計算機-端末 クライアント サーバ インターネット/ ブラウザ クラウド UML(95) Booch OMT OOSE デザインパターン(95) Yordon DeMarco DFD アナリシスパターン(96) リファクタリング(00) Linux(91) 構造化分析・設計 オブジェクト指向 分析・設計 XP(99) Scrum(95) 1970年代 1980年代 1990年代 2000年代 2010年代 ソフトウェア開発の歴史 Agile 開発手法 LeanSD(03) LeanStartup(11) Microservice Multi-core GPU Swift(10) Kotlin(11) AI プログラミング言語 分析・設計手法
- 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
- 81. 変わっていない重要な デザインコンセプト(Evergreen) 70s 70s-80s 80s-90s-2000s 構造化プログラミング 構造設計設計 オブジェクト指向設計 main fun fun fun 関⼼事が分離され、凝集度が ⾼い⼿続きモジュールが、結 合度低く結びついて、データ を処理、更新する。他⼈には 内部の情報を知らせない（情 報隠蔽：変更が伝搬しないよ うに）。 データと操作がカプセル化 されたクラス。クラスは継 承構造をもつ。クラスから、 オブジェクトが⽣成され、 それらが、メソッドを呼び 合って、ユースケースを成 し遂げる。 81
- 83. 「情報隠蔽」のエピソード • OSを開発していたチームが、メモリをファイルシ ステムに吐き出す必要があり、ファイルシステム のチームにファイルのレイアウトを聞いた。 • ファイルシステムのチームは、まだレイアウトが 決まっていなかったが、（今で⾔う）open(), close(), read(), write() 関数のエントリーポイン トとレジスタに積む・返す値だけ教えた。 • これ以上の知識を与えない⽅が、後々の変更が彼 らの仕事に影響しないだろう、と考えた。 ーDavid Parnas 83
- 84. 保守性が⾼いソフトウェアとは • メンテナンスにかかるコストが低い • 開発中の作業にかかるコストも低い ⇒⽣産性が向上 – デバッグ時間短縮 • 他の品質特性も向上 機能性 信頼性 使⽤性 効率性 保守性 移植性 解析性 変更性 安定性 試験性 ⽮印の元は、⽮印の先に依存している 84
- 85. 変更に強いデザイン + 外部からの変更 （要因）を分析 低周波＝安定している 依存の低レイヤ に置く ⾼周波＝不安定 依存の⾼いレイヤ に置く 変更の1要因が 1クラスになるように à SRP 具体（変更が多い）にし ない。抽象（変更が少な い）に依存せよ à DIP 変更の伝搬を防ぐ(例) à Clean Architecture 85
- 87. Object-Oriented Designを学ぶなら 87 Classic Classic Classic Classic Classic
- 88. 88
- 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
- 91. 91
- 92. Agile 92
- 93. 93 なぜ、 アジャイルか?
- 94. 94 市場 ビジネス IT 市場分析 発注 納品リリース 半年から３年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）
- 95. 95 従来型の問題＝要求の劣化 システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% • Standish group study report in 2000 chaos report
- 98. 98 プロセスとしてのAgile • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ)Waterfall Agile Beck 2000Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成長する
- 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
- 100. Agile Manifesto 100
- 101. 101 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 超重要!
- 103. 103
- 104. 104
- 106. Scrum 106
- 107. 107 スクラムの流れ
- 108. スクラムの3本柱 • 透明性 – プロジェクトが順調か、判断できる情報を標 準化し、関係者全員で正しく共通理解をもつ。 • 検査 – 成果物や進んでいる⽅向がゴールに向かって いるから絶えず確認する。 • 適応 – 何か不備があった場合、ゴールの逸脱を最⼩ 限に抑えるために早期に調整する。 108
- 109. 109 スクラムでの役割
- 110. 110 スクラムのフレームワーク
- 111. 111
- 112. 112
- 114. Agile Practices 114
- 116. 116 • Write a test • Watch it fail • Make it pass • Refactor (improve) • Repeat until done T D D • テストを書く • 失敗することを確認 • 通過させる • リファクタリング（改善） • 繰り返す
- 117. Agile Practices 117
- 119. 119 アジャイル開発 の現場
- 121. タスクかんばん • 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。 POINT (協力：チェンジビジョンastah* チーム） 121
- 122. ⽇本からも海外へ発信 122
- 123. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net 123
- 127. バーンダウンチャート • 進捗の見える化 – バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物で は計測しない。 – メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 バーンダウンチャートの例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくり POINT (協力：永和システムマネジメント：チーム角谷） 127
- 131. デジタルとアナログ
- 134. 134
- 135. 135
- 136. 136
- 137. 137
- 138. 138
- 139. ソフトウェアと⼈は切り離せない 139 Classic Classic Classic Classic
- 140. 140