Webサービスの成長を止めずにリファクタリングする技術 / web-refactoring

Slide 1

Slide 1 text

Webサービスの成長を止めずに  リファクタリングする技術  PHPカンファレンス福岡2019

Slide 2

Slide 2 text

What is it?  リファクタリングしてますか？ 

Slide 3

Slide 3 text

What is it?  ● サービス開発が優先…  ● 技術的負債の返済に理解が無い…  ● どこからやればいいかわからない…  現場の声 

Slide 4

Slide 4 text

What is it?  これは全部、言い訳です 

Slide 5

Slide 5 text

What is it?  今日は実際に  どのようにやったらいいか  どのようにやってきたか     

Slide 6

Slide 6 text

What is it?  余すことなく、お伝えします 

Slide 7

Slide 7 text

あじぇんだ  1. 自己紹介  2. Webサービスを止めない工夫  3. リファクタリングとテスト  4. 新規開発とリファクタリングの共存  5. 実際にリファクタリングした例  6. まとめ 

Slide 8

Slide 8 text

Slide 9

Slide 9 text

自己紹介  曽根壮大（34歳）  株式会社オミカレ副社長 CTO    そ　ね　　たけとも  ● 日本PostgreSQLユーザ会勉強会分科会担当  ● 3人の子供がいます（長女、次女、長男）  ● 技術的にはWeb/LL言語/RDBMSが好きです  ● コミュニティが好き

Slide 10

Slide 10 text

婚活といえばオミカレ  https://party-calendar.net/

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Webサービスを止めない工夫  Webサービスは止められない 

Slide 13

Slide 13 text

Webサービスを止めない工夫  ● 365日/24時間、稼働している  ● サービスの停止=ビジネスの停止  ● 複雑な依存関係があり、単純に1つだけ止めれば良いとならない  止められない理由 

Slide 14

Slide 14 text

Webサービスを止めない工夫  Webサービス、止めないとは？ 

Slide 15

Slide 15 text

Webサービスを止めない工夫  Webサービス、止めないとは？  ↓  Webサービスの稼働を止めない？ 

Slide 16

Slide 16 text

Webサービスを止めない工夫  Webサービス、稼働と進化を止めない 

Slide 17

Slide 17 text

Webサービスを止めない工夫  リファクタリング戦略と戦術が大切 

Slide 18

Slide 18 text

Webサービスを止めない工夫  戦略→目的を達成するためのシナリオ  戦術→目的を達成するための手段・手法 

Slide 19

Slide 19 text

Webサービスを止めない工夫  ● 目的と効果の判断をする  ● ゴールを決める  ● 方針を決める  リファクタリング戦略 

Slide 20

Slide 20 text

Webサービスを止めない工夫  ● 目的と効果の判断をする  ● ゴールを決める  ● 方針を決める  リファクタリング戦略 

Slide 21

Slide 21 text

Webサービスを止めない工夫  チーズと腐った牛乳の違い 

Slide 22

Slide 22 text

Webサービスを止めない工夫  何を変更するのか？ 

Slide 23

Slide 23 text

Webサービスを止めない工夫  ● 機能追加  ● バグ修正  ● 最適化  ● リファクタリング  それぞれの目的が違う 

Slide 24

Slide 24 text

Webサービスを止めない工夫  機能追加とバグ修正  ↓  振る舞いが変わる 

Slide 25

Slide 25 text

Webサービスを止めない工夫  最適化とリファクタリング  ↓  振る舞いが変わらない 

Slide 26

Slide 26 text

Webサービスを止めない工夫 

Slide 27

Slide 27 text

Webサービスを止めない工夫  目的 / 対象  新機能  機能  リソース  構造  要件追加  変化する  ー  ー  変化する  バグ修正  ー  変化する  ー  変化する  最適化  ー  ー  変化する  ー  リファクタリング  ー  ー  ー  変化する  引用：レガシーコード改善ガイド第1章ソフトウェアの変更 P7

Slide 28

Slide 28 text

Webサービスを止めない工夫  複数の目的を一つのチケットにしない   

Slide 29

Slide 29 text

Webサービスを止めない工夫  複数の目的を一つのチケットにしない  ↓  目的を単純化して小さいチケットにする 

Slide 30

Slide 30 text

Webサービスを止めない工夫  機能追加のためにリファクタリングが必要 

Slide 31

Slide 31 text

Webサービスを止めない工夫  テストの内容が変わる 

Slide 32

Slide 32 text

Webサービスを止めない工夫  機能追加のためにリファクタリングが必要  ↓  それぞれ別のPRにする 

Slide 33

Slide 33 text

Webサービスを止めない工夫  ● 目的と効果の判断をする  ● ゴールを決める  ● 方針を決める  リファクタリング戦略 

Slide 34

Slide 34 text

Webサービスを止めない工夫  ゴールを決める   

Slide 35

Slide 35 text

Webサービスを止めない工夫  ゴールを決める  ↓  期間と目的を決める 

Slide 36

Slide 36 text

Webサービスを止めない工夫  1回で終わらないタスクもある  数ヶ月単位のリファクタリングもある   

Slide 37

Slide 37 text

Webサービスを止めない工夫  ゴールを決める  ↓  スケジュールを設計する 

Slide 38

Slide 38 text

Webサービスを止めない工夫  1. 第1法則  仕事の量は、完成のために与えられた時間を  すべて満たすまで膨張する  2. 第2法則  支出の額は、収入の額に達するまで膨張する  パーキンソンの法則 

Slide 39

Slide 39 text

Webサービスを止めない工夫  リファクタリングの完成は無い 

Slide 40

Slide 40 text

Webサービスを止めない工夫  だからこそ、ゴールを決めることが大切 

Slide 41

Slide 41 text

Webサービスを止めない工夫  ● 目的と効果の判断をする  ● ゴールを決める  ● 方針を決める  リファクタリング戦略 

Slide 42

Slide 42 text

Webサービスを止めない工夫  どのようにリファクタリングするか 

Slide 43

Slide 43 text

Webサービスを止めない工夫  Webサービス、稼働と進化を止めない 

Slide 44

Slide 44 text

Webサービスを止めない工夫  ● 新機能とコンフリクトしない  ● 振る舞い(既存機能)を壊さない  ● サービス停止を伴わない  ● 新たな負債を作らない  要件 

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Webサービスを止めない工夫  改善と新機能追加を  明確に分ける 

Slide 47

Slide 47 text

Webサービスを止めない工夫  新機能→ユーザ画面  改善→管理画面  これはコンフリクトする場合がある   

Slide 48

Slide 48 text

Webサービスを止めない工夫  ユーザ機能は管理画面と  依存関係がある 

Slide 49

Slide 49 text

Webサービスを止めない工夫  依存関係の例  ユーザ画面  管理画面  ユーザ  ① 予約アクション  ② 予約情報の確認  ④ 予約情報の確認  管理者  ③ 予約情報の変更 

Slide 50

Slide 50 text

Webサービスを止めない工夫  機能で分ける 

Slide 51

Slide 51 text

Webサービスを止めない工夫  ？？？「既存機能は密結合してる」   

Slide 52

Slide 52 text

Webサービスを止めない工夫  機能で分ける  ↓  機能別に分割することが  リファクタリングの最初 

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Webサービスを止めない工夫  壊さないための工夫 

Slide 56

Slide 56 text

Webサービスを止めない工夫  壊れてないことの証明   

Slide 57

Slide 57 text

Webサービスを止めない工夫  壊れてないことの証明  ↓  テストコード 

Slide 58

Slide 58 text

Webサービスを止めない工夫  壊さないリファクタリング   

Slide 59

Slide 59 text

Webサービスを止めない工夫  壊さないリファクタリング  ↓  デザインパターンを活用する 

Slide 60

Slide 60 text

Webサービスを止めない工夫  例えばDecoratorパターン  (GoFデザインパターン) 

Slide 61

Slide 61 text

Webサービスを止めない工夫  ルーク、Do You PHPを読め  http://shimooka.hateblo.jp/entry/20141217/1418788239  

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Webサービスを止めない工夫  変更の影響を小さくする 

Slide 64

Slide 64 text

Webサービスを止めない工夫  ● データストアとアプリケーションを  できるだけ一緒に変更しない  ● 変更前と変更後でも同じ振る舞いをする  ● テスト項目が現実的なサイズに留める  変更の影響を小さくする 

Slide 65

Slide 65 text

Webサービスを止めない工夫  リファクタリングの場合は満たしやすい  機能追加の場合は腕の見せ所 

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Webサービスを止めない工夫  目的がブレると陥りやすい 

Slide 68

Slide 68 text

Webサービスを止めない工夫  納期のために…  良い方法が思いつかない…  やりたい事の問題が大きい… 

Slide 69

Slide 69 text

Webサービスを止めない工夫  こうなったらリファクタリングしない 

Slide 70

Slide 70 text

Webサービスを止めない工夫  良い解決策がない場合  それは時期早々 

Slide 71

Slide 71 text

Webサービスを止めない工夫  リファクタリングは機能追加ではない   

Slide 72

Slide 72 text

Webサービスを止めない工夫  リファクタリングは機能追加ではない  ↓  必ず必要ではない 

Slide 73

Slide 73 text

Webサービスを止めない工夫  目的を明確に、小さくやる 

Slide 74

Slide 74 text

Slide 75

Slide 75 text

リファクタリングとテスト  実際にリファクタリングしましょう 

Slide 76

Slide 76 text

リファクタリングとテスト  実際にリファクタリングしましょう  ↓  テストはありません 

Slide 77

Slide 77 text

リファクタリングとテスト  ？？？「わかるぅ〜〜〜」  (CV:そーだい) 

Slide 78

Slide 78 text

リファクタリングとテスト  テストを書きましょう 

Slide 79

Slide 79 text

リファクタリングとテスト  テストを書きましょう  ↓  責務が多くてテストが書けません 

Slide 80

Slide 80 text

リファクタリングとテスト  ？？？「わかるぅ〜〜〜」  (CV:そーだい) 

Slide 81

Slide 81 text

リファクタリングとテスト  まずはテストできる状況を目指す 

Slide 82

Slide 82 text

リファクタリングとテスト  ● 機能が疎結合  ● テストの実行環境がある  ● 振る舞いが明確である  テストができる状態 

Slide 83

Slide 83 text

リファクタリングとテスト  状況に合わせてテストを使い分ける 

Slide 84

Slide 84 text

リファクタリングとテスト  ● ユニットテスト  ● インテグレーションテスト  ● シナリオテスト  etc...テストは奥が深く他にも色々  主なテストの種類 

Slide 85

Slide 85 text

リファクタリングとテスト  何をテストしたいのか 

Slide 86

Slide 86 text

リファクタリングとテスト  機能要件ベースならシナリオテスト  コードベースならユニットテスト  自動化はとても大切だけど全てではない 

Slide 87

Slide 87 text

リファクタリングとテスト  責務が多すぎてユニットテストが出来ない  ↓  まずはシナリオテストを用意する 

Slide 88

Slide 88 text

リファクタリングとテスト  ● 本番相当のテストデータ  ● 本番相当のテスト環境（staging）  ● 明確な機能要件  シナリオテストに必要なこと 

Slide 89

Slide 89 text

リファクタリングとテスト  いきなりシナリオテストを自動化しない  （例えばSeleniumとかで） 

Slide 90

Slide 90 text

リファクタリングとテスト  シナリオ（機能要件）は変化しやすい  ↓  Viewに近いところは  ビジネスの変化を受けやすい 

Slide 91

Slide 91 text

リファクタリングとテスト  要件を絞る  ↓  フルテストみたいなシナリオを書かない 

Slide 92

Slide 92 text

リファクタリングとテスト  シナリオテストが出来たら？  ↓  シナリオテストが通るように機能を分解   

Slide 93

Slide 93 text

リファクタリングとテスト  機能を分解するとき  ユニットテストは最初から書く 

Slide 94

Slide 94 text

リファクタリングとテスト  テストが出来ないコードを防ぐ   

Slide 95

Slide 95 text

リファクタリングとテスト  テストが出来ないコードを防ぐ  ↓  TDDでなくてもいいけど、テストは書く 

Slide 96

Slide 96 text

リファクタリングとテスト  Viewから遠いところからテストを書く 

Slide 97

Slide 97 text

リファクタリングとテスト  Viewから遠いところからテストを書く  ↓  例えばドメイン層 

Slide 98

Slide 98 text

リファクタリングとテスト  データソース層 Table Data Gateway ActiveRecord DataMapper　などデータストアドメイン層プレゼンテーション層 View Controller ビジネスロジック Service Entity Repository ドメイン層から着手する   目指すアーキテクチャに合わせてリファクタリング   ※左記の例は一例でドメインの分割は多種多様   (フレームワークの制約も受ける)  

Slide 99

Slide 99 text

リファクタリングとテスト  ● 責務の分割  ● ロジックの整理  ● 不要なコードの削除  etc...  ドメイン層のリファクタリング例 

Slide 100

Slide 100 text

リファクタリングとテスト  何年も稼働しているサービスなら  ビジネスロジックのコアが見えてるはず 

Slide 101

Slide 101 text

リファクタリングとテスト  ビジネスロジックのコアを整理する  ↓  変化のインパクトが大きいからこそ  リファクタリングとテストが活きる 

Slide 102

Slide 102 text

Slide 103

Slide 103 text

新規開発とリファクタリングの共存  偉い人「新規開発は止めないで」 

Slide 104

Slide 104 text

新規開発とリファクタリングの共存  Webサービス、稼働と進化を止めない 

Slide 105

Slide 105 text

新規開発とリファクタリングの共存  新規開発は既存部分と分ける 

Slide 106

Slide 106 text

新規開発とリファクタリングの共存  ？？？「fileやコンポーネント増えません？」   

Slide 107

Slide 107 text

新規開発とリファクタリングの共存  ？？？「fileやコンポーネント増えません？」  ↓  増えます 

Slide 108

Slide 108 text

新規開発とリファクタリングの共存  サービスレイヤが無いなら導入する   

Slide 109

Slide 109 text

新規開発とリファクタリングの共存  サービスレイヤが無いなら導入する  ↓  既存は少しづつリファクタリングで  サービスレイヤに移行する 

Slide 110

Slide 110 text

新規開発とリファクタリングの共存  サービスレイヤが無いなら導入する  ↓  既存は少しづつリファクタリングで  サービスレイヤに移行する  新規は最初から利用する 

Slide 111

Slide 111 text

新規開発とリファクタリングの共存  モック化しやすいように変更する  ↓  例えばAPI経由にする 

Slide 112

Slide 112 text

新規開発とリファクタリングの共存    データソース層 Table Data Gateway ActiveRecord DataMapper　などデータストアドメイン層プレゼンテーション層 View Controller ビジネスロジック Service Entity Repository API層新たなロジック

Slide 113

Slide 113 text

新規開発とリファクタリングの共存  新規開発はリファクタリング後の姿で  最初から開発する 

Slide 114

Slide 114 text

新規開発とリファクタリングの共存  リファクタリング新規開発理想の状態両軸から理想を目指す 

Slide 115

Slide 115 text

1. 自己紹介  2. Webサービスを止めない工夫  3. リファクタリングとテスト  4. 新規開発とリファクタリングの共存  5. 実際にリファクタリングした例  6. まとめ  あじぇんだ 

Slide 116

Slide 116 text

実際にリファクタリングした例  オミカレのフルリニューアル  (なんと6/25にリリースしたばかり！) 

Slide 117

Slide 117 text

実際にリファクタリングした例  ● テーブル設計に不備がある  ● 一つのモデルの責務が大きい  ● FatController  ● Viewにロジックが含まれている  今までのオミカレ 

Slide 118

Slide 118 text

Slide 119

Slide 119 text

実際にリファクタリングした例  一つ一つ改善してきた 

Slide 120

Slide 120 text

実際にリファクタリングした例  https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000

Slide 121

Slide 121 text

実際にリファクタリングした例  https://speakerdeck.com/soudai/aws-dms

Slide 122

Slide 122 text

実際にリファクタリングした例  https://speakerdeck.com/soudai/kichijojipm

Slide 123

Slide 123 text

実際にリファクタリングした例  細かく知りたい人は  資料を見てください 

Slide 124

Slide 124 text

実際にリファクタリングした例  エンジニアHubから引用

Slide 125

Slide 125 text

新規開発とリファクタリングの共存    データソース層 Table Data Gateway ActiveRecord DataMapper　などデータストアドメイン層プレゼンテーション層 View Controller ビジネスロジック Service Entity Repository API層新たなロジックまさにこれ！ 

Slide 126

Slide 126 text

実際にリファクタリングした例  APIとRDBMSの機能を使って  データ構造を変える 

Slide 127

Slide 127 text

実際にリファクタリングした例  APIはINとOUTが明確  ↓  テストコードが書きやすい！ 

Slide 128

Slide 128 text

Slide 129

Slide 129 text

既存のオミカレ  データストアドメイン層プレゼンテーション層 View Controller モデルクラス - データアクセスとロジックが同じクラスにかかれている - Controllerに一部のロジックが漏れている（書かれている）

Slide 130

Slide 130 text

実際にリファクタリングした例  エンジニアHubから引用

Slide 131

Slide 131 text

実際にリファクタリングした例  APIを経由することで  ロジックの責務を分解する  APIがドメイン層とも言える 

Slide 132

Slide 132 text

実際にリファクタリングした例  リファクタリングの例  例えばpartyの取得 

Slide 133

Slide 133 text

実際にリファクタリングした例  REST API(/api/public/party)を作る   

Slide 134

Slide 134 text

実際にリファクタリングした例  APIを呼び出すRepository(PartySearch)を作る  パラメータをSetして呼び出すだけ   

Slide 135

Slide 135 text

実際にリファクタリングした例  PartySearchを使って情報を取得する  Presenter(SearchPartyPresenter)を作る 

Slide 136

Slide 136 text

実際にリファクタリングした例 

Slide 137

Slide 137 text

実際にリファクタリングした例  検索条件は複雑だから、PresenterからRepositoryを呼び出すパターンが無限にある 

Slide 138

Slide 138 text

実際にリファクタリングした例  PresenterとRepositoryをつなぐ  Model(SearchModel)を作る  Presenter ↔ Model ↔ Repository 

Slide 139

Slide 139 text

新規開発とリファクタリングの共存    データストアドメイン層プレゼンテーション層 View Controller Presenter ビジネスロジックを書く Repository 適切なデータにアクセスする API層データの取得と調整まさにこれ！  キャッシュ Model データの取得と加工する

Slide 140

Slide 140 text

実際にリファクタリングした例  Modelの責務を分ける  ↓  Controllerが呼び出す  get_party()の振る舞いは変わらない  get_party()はPresenterに実装する 

Slide 141

Slide 141 text

実際にリファクタリングした例  Presenterはデータの保存先を知らない  ↓  ビジネスロジックだけに注力する  NoSQLでもRDBMSでもキャッシュでも良い 

Slide 142

Slide 142 text

実際にリファクタリングした例  Modelはビジネスロジックに  必要なお膳立てをする  振る舞いの例  1. PresenterがSetした条件に合わせてPartyを取得する  2. 与えられた条件から参加可否を加工する  3. 不要な情報をフィルタする　…など 

Slide 143

Slide 143 text

実際にリファクタリングした例  RepositoryはModelが必要な  データアクセスを提供する  RDBMSもキャッシュも同じフォーマット（オブジェクト）で返ってきてほしい 

Slide 144

Slide 144 text

実際にリファクタリングした例  責務を分けるとモック化やテストが楽 

Slide 145

Slide 145 text

Slide 146

Slide 146 text

実際にリファクタリングした例  controllers ❯❯❯ wc -l area.php  5124 area.php 

Slide 147

Slide 147 text

実際にリファクタリングした例  5000行超えのController、趣がありますね 

Slide 148

Slide 148 text

実際にリファクタリングした例  SEOのために必要な  パンくずやキーワードの取得を書いてしまう 

Slide 149

Slide 149 text

実際にリファクタリングした例  AパターンのときとBパターンの時に  パンくずの出力を分けてください  ↓  Controllerにif文が生える 

Slide 150

Slide 150 text

実際にリファクタリングした例  どんどんControllerがロジックを持つ   

Slide 151

Slide 151 text

実際にリファクタリングした例  どんどんControllerがロジックを持つ  ↓  無限に増える行数 

Slide 152

Slide 152 text

実際にリファクタリングした例  ロジックがControllerに漏れているのが原因   

Slide 153

Slide 153 text

実際にリファクタリングした例  ロジックがControllerに漏れているのが原因  ↓  Presenterに責務を移していく  データアクセスがない部分でもしっかりPresenterにする 

Slide 154

Slide 154 text

実際にリファクタリングした例  Presenterは先に作れる  ↓  他の開発の邪魔をしない 

Slide 155

Slide 155 text

実際にリファクタリングした例  controllers ❯❯❯ wc -l Area.php  542 Area.php  同等の機能が約1/10の行数になった！ 

Slide 156

Slide 156 text

実際にリファクタリングした例  Controllerの行数は  メンテナンス工数に直撃する 

Slide 157

Slide 157 text

実際にリファクタリングした例  Controllerが小さくなることで  影響範囲が明確になった 

Slide 158

Slide 158 text

Slide 159

Slide 159 text

実際にリファクタリングした例  Viewにif文を書いてませんか？ 

Slide 160

Slide 160 text

実際にリファクタリングした例  = $this->load->view('/parts/header'); ?> // headerがいらないときの処理

Slide 161

Slide 161 text

実際にリファクタリングした例  ？？？「1行だけだし、これでいっか」   

Slide 162

Slide 162 text

実際にリファクタリングした例  ？？？「1行だけだし、これでいっか」  ↓  良くない！！！！   

Slide 163

Slide 163 text

実際にリファクタリングした例  ？？？「PCとSPでheaderを分けてほしい」   

Slide 164

Slide 164 text

実際にリファクタリングした例  = $this->load->view('pc/parts/header'); ?> = $this->load->view('sp/parts/header'); ?> // headerがいらないときの処理

Slide 165

Slide 165 text

実際にリファクタリングした例  ？？？「AMPもやりたい」  ↓  こうやって無限に増える   

Slide 166

Slide 166 text

実際にリファクタリングした例  Viewにifがある=状態を持っている  ↓  状態を持っているとテストが難しい 

Slide 167

Slide 167 text

実際にリファクタリングした例  ● 見た目のテストは成否が難しい  ● ブラウザなど依存環境が多い  ● テストの自動化のコストが高い  ● テスト項目が多いと時間がかかる  そもそもViewのテストは難しい 

Slide 168

Slide 168 text

実際にリファクタリングした例  できるだけテストしたくない   

Slide 169

Slide 169 text

実際にリファクタリングした例  できるだけテストしたくない  ↓  Viewにif文を書かない   

Slide 170

Slide 170 text

実際にリファクタリングした例  とある日のCTO  「突然ですがViewでif文を禁止にします」 

Slide 171

Slide 171 text

実際にリファクタリングした例  どうやって実現するか 

Slide 172

Slide 172 text

実際にリファクタリングした例  どうやって実現するか  ↓  出力するデータをPresenterで事前に用意する  Viewは出力するだけ 

Slide 173

Slide 173 text

実際にリファクタリングした例  100文字以上は末尾を…にしたい  ↓  Helperで吸収してViewはechoするだけ 

Slide 174

Slide 174 text

実際にリファクタリングした例  Viewのif文が無くなるとデバッグが楽になる  Presenterだけに注力すれば良い  そしてPresenterにはテストが書ける！ 

Slide 175

Slide 175 text

実際にリファクタリングした例  現状に合わせて1つ1つ積み重ねる  オミカレも1年以上かかった    この他にもFWやPHPのバージョンアップなどもした 

Slide 176

Slide 176 text

Slide 177

Slide 177 text

まとめ  リファクタリングの戦略を決める 

Slide 178

Slide 178 text

まとめ  リファクタリングの戦略を決める  ↓  どこからやるか、どのようにやるか 

Slide 179

Slide 179 text

まとめ  https://speakerdeck.com/naoya/ji-shu-de-fu-zhai-toxiang-kihe-u

Slide 180

Slide 180 text

まとめ  [オープンセミナー岡山 2017] [検索]

Slide 181

Slide 181 text

まとめ  優先順位は大切  小さく始める 

Slide 182

Slide 182 text

まとめ  まずはテストをできる状態にする     

Slide 183

Slide 183 text

まとめ  まずはテストをできる状態にする  ↓  自動化じゃなくてもテストはできる 

Slide 184

Slide 184 text

まとめ  分割してからテストの自動化を目指す 

Slide 185

Slide 185 text

まとめ  分割ができれば新規機能追加と衝突しない 

Slide 186

Slide 186 text

まとめ  分割ができれば新規機能追加と衝突しない  ↓  新規とリファクタリングの両輪で  理想を目指す 

Slide 187

Slide 187 text

まとめ  技術で課題を解決する 

Slide 188

Slide 188 text

まとめ  テストを工夫したり  監視をすることでテストの代用をしたり  デザインパターンを活用したり 