それはYAGNIか? それとも思考停止か?

DevLOVE X Day1 C-5のセッションです。

ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。

1. それはYAGNIか?
それとも思考停止か ?
kawasima

2. ビジネス目標に応じてプロセスを適切に使い分けることがされる土壌が
整いつつあるといっても過言ではない状況といえるようになってきた
Agile or die
SoE SoR
市場に速く出して、
改善を繰り返す
十分よく計画して、
安定したシステム運用を
実現する
ここ10年での変化

3. 「市場に速く出して、改善を繰り返す」方の
システム設計
タイム・トゥ・マーケット
正解なんて誰にも
分からないんだから
速く出して速く失敗しよう
「とにかく動かせ」
「お便利フレームワーク使って早く作れ」
「YAGNIだYAGNIっ」

4. YAGNI
You ain’t gonna need it.
(どうせ必要ないって！ )
覚えたら、つい使いたくなる甘美な響き
もともとは Featureについての要 /不要の話が
転じてDesignについても議論されるようになった

5. ビジネスの成長と共にゴールは切り替わっていく
とにかくスピード 品質・生産性
時間がかかる
工数がかかる
リリースするたび本番障害発生

6. ますますYAGNIの判定は重要に
「YAGNI = 設計をサボって良い」では断じてない
「あとでクリーンにすればいいよ。先に市場にだ
さなければ！」
開発者たちはそうやっていつもごまかす。だが、
あとでクリーンにすることはない。市場からのプ
レッシャーはとまらないからだ。
クリーンアーキテクチャ

7. 設計のサボりと YAGNI
ログ・例外設計
インタフェース設計
管理画面
リカバリの自動化
バリデーション
基本はリスクマネジメント
(発生確率×流出コスト )
データが貯まら
ないと意味をな
さない機能
データのパージ
SEO対策
メッセージの
変更リロード機能

8. 2種類の非YAGNI
①それ、そもそも後回しにできないよ。
②今やっとかないと後でやるにはコストがかかり
すぎる。
後者を対象に今日は話をします

9. アーキテクチャ設計にどれくらい時間をかけるか
には統計に基づいた研究がある
プロジェクトの時間
= 開発時間
+ アーキテクチャとリスク削減時間
+ やり直しの時間
Making Software, How Much Architecting Is Enough?

10. コード規模によって
パーセンテージは変わる

11. 技術的負債をおさえるための
非YAGNI
①インタフェースを使い Detailを分離する
②必要になるまで状態をもたない /持つ箇所を限
定する
③(誰のためにのデザインかを明らかにして、分類しまとめる )

12. 最速インタフェース設計
~じっくりドメイン設計する時間がなくともここだけはやっておけポイント ~
①区分値,ステータスを属性にもつデータの塊
②開発体制の境界
•開発体制が分かれるところにインタフェースを定義して並
行開発する
③レイヤの境界
•大抵はフレームワークの仕事
•引数をインタフェースにしてテスタビリティをあげる。
④ホットスポット
•不具合が集中
的に発生する箇所を 抜き出してテストしたり、作り
直して実
装置換するためにインタフェースを作る。

13. 区分値,ステータスを属性にもつ
データの塊
テー
ブルの中に「〜区分」や「 〜ステー
タス」を
見つけたら、それ 扱うクラスで
は、必
ずインタフェース作っておく

14. 【例題】会員の種別によって料金や
サービスメニューが異なる

15. 区分はまず増減しがちなので
たとえ数が少なくてもインタフェースを用意する

16. 実装が1つしかなくても
インタフェースが必要か ?
https://softwareengineering.stackexchange.com/questions/159813/do-i-need-to-use-an-interface-when-only-one-class-will-ever-implement-it/
実
装の数が問題なのではない

17. ステータスも同様

18. ステータスもつデータの設計は
こちらをどうぞ
https://speakerdeck.com/kawasima/lu-li-wochi-tudetafalseshe-ji

19. 業務ルール
E
TC
割
引の計算ロジックを実 装します。
●
平
日朝夕割引
–平
日「朝
:6時
〜
9時」、「
夕
:17時
〜
20時」
–地方部
–当月
の利用回数が
5回
〜
9回 30%割
引、
10回
以上
50%割
引
●
休
日割引
–普通車
、軽自動車等
(二輪車)限定
–土曜
・日曜・祝日
–地方部
–30%割
引
●
深夜割
引
–す
べての車種
–毎
日
0〜４
時
–30%割
引
htt
ps://github.com/kawasima/kata

20. 【例題】ETC割引のルール実装
上記
の業務ルールにしたがい、 割引率を計算するインタフェー
スDiscountSer
vice
を実
装して下さい。
p
ublic interface DisountService {
p
ublic long calc(HighwayDrive drive);
}
走
行記録は
Highwa
yDrive
ク
ラスで表現さ
れ、DiscountSer
vice#calc
に
渡されるものとします。 ま
た、
割引率はパーセンテージの正の 整数で表現されます。

21. 割
引ルールのインタフェースを 以下のように定義し
各ル
ールをインタフェースに 沿って実装する。
業務ル
ールは、「適用判定」と
「
適用計算」のメソッドを分ける
のがポイント

22. そうすることで、
割引の計算はルールが増減、変更になっても変 わる
ことはなくなる。
※この
形は業務システムにおいて 頻出なので、
K
ATA
トレー
ニングして
身
につけまし ょう。

23. 開発体制の境界インタフェース
目指
すところが「リ ソース効率」か「フロー 効率」かで、
実
際に並行で開発するかを 決める
依存関係
開発
順序

24. レイヤ境界のインタフェース
ログイン機能
<<
Interface>>
認証
Auth
Request
+authenticate(Auth
Request)
L
DAP
認証
+authenticate(Auth
Request)

25. 実際にはインタフェースと実装の
パッケージングを分ける
ログイン機能
<<
Interface>>
認証
Auth
Request +authenticate(Auth
Request)
L
DAP
認証
+authenticate(Auth
Request)

26. レイヤ間の通信が HTTPになっても
考えは変わらない
ログイン機能
<<
Interface>>
認証
Auth
Request
+authenticate(Auth
Request)
L
DAP
認証
+authenticate(Auth
Request)
Op
enAPI
による
A
PI
仕
様
<<
Interface>>
認証
Auth
Request
+authenticate(Auth
Request)
仕
様からインタフェースを生 成

27. ホットスポットのインタフェース
●変更が
多い箇所には、不具合の発生 確率も高まる。
●
変更が
多い箇所には、 技術的負債 も溜まっていく。
(これは
最初の段階では読めないことが 多いので、
考
えすぎるのは
YAGNIです)

28. とある
有名な句
「不具合に/テストを書いて /立ち向かう」
1
.
手元
で不具合を 再現させる
2
.
コードを
注意深く調べ、不具合を発生させている 最小の部分を絞り込む
3
.
最小
レベルで不具合を 再現させ、不具合が 修正されたら 通るような自動テストコー
ドを
書く
4
.
書
いたテストコードを実行し、 落ちることを 確認する
5
.
不具合を
修正する
6
.
書
いたテストコードが 通ることを 確認する
7
.
全
てのテストを実行し、不具合 修正が他の部分を壊していないことを 確認する
8
.
不具合箇所をリフ
ァクタリングして
TestabilityとDisposabilityをあげておく
https://t-wada.hatenablog.jp/entry/debugging-tests

29. ホットスポットの見つけ方

30. 同時に変更されるものが、あちこちに分散しているのは SRPに反する

31. 状態(ステート)
●
更
新は最小限に。
●
状態の更
新の向きは一方向に。
●
状態をもつ箇所を
切り出す。
●
途
中の計算結果は必要になるまでもたない。

32. 分解して考えてみよう

33. 状態をもつ箇所を切り出す
htt
ps://github.com/kawasima/bouncr
例)認証
状態をリバースプロキシレイヤで管理して、後ろのアプリケー
ションをステートレスにする Bouncr

34. 途中の計算結果を保存すると…
●
性能限界が早くきやすい
●性能でないときの対策が
取りづらい
●
最初
からオーバーエンジニアリングになりがち

35. 【例題】価値観マッチングシステムの設計
いろんな
人に価値観のアンケートを 取ります。
例えば
以下のような設 問です。それ ぞれ、
1
(
そうは
思わない
) 〜

5
(
とてもそう
思う
)を
付けても
らいます。
Q1
.
お年
寄りは運転 免許を返上すべき
Q2
.
ラ
ッシュ時のベビーカーはたたんだ ほうが良い
Q3
.
コンビ
ニは深夜の営業やめた方が良い
Q4
.
洗濯
は晴れた日にまとめてやりたい
Q5
.
電車
が目の前で行ってしまったらかなりカチンとくる
この回
答の値の距離で、各人の相性を測ることとします。
たとえば、
Aさんの回
答
(
Q1, Q2, Q3, Q4, Q5) = (1,2,3,4,5)
Bさんの回
答
(
Q1, Q2, Q3, Q4, Q5) = (3,3,3,3,3)
のとき、
二人の相性は
1
- (abs(1-3) + abs(2-3) + abs(3-3) + abs(4-3) +
a
bs(5-3)) / 20 = 70%
です。
(
20
で
割っているのは
5問
あって距離の最大値が
1問
あたり
4だからです)

36. こういうモデル

38. 【例題】階層をもつメッセージ
親子
それぞれで取得件数の
Limit定めたい

40. S
QL1
発で
処理するようにしておいて、 遅くなってきた
ら、パーティショ
ニング
/シャーディングで対
処するの
が開発ボリ
ューム抑えながらスケー ルさせていく 近道

41. さいごに
ここでお話した設計は 技法(テク
ニック
)を
知
っているかどうかであって、やると
工数が
爆増するものではないのが ミソです。
YAGNIの
顔をした思考停止 を
やっつけまし
ょう