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

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

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

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

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

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

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

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

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. 状態をもつ箇所を切り出す
https://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) +
abs(5-3)) / 20 = 70% です。
(20で割っているのは5問あって距離の最大値が1問あたり4だからです)

36. こういうモデル

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

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

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