段階的な技術的負債の解消方法.pdf

Transcript

1. 段階的な技術的負債の解消方法 TechBase vol.2 2022/07/28 Koji Ishii
2. 2 自己紹介 NewsPicks Mobile Unit （iOS 7名 Android 6名） エンジニアリングマネージャー Android中心に開発 iOSは全然書いてない
3. 3 自己紹介 こんな本を書いてました。 経験として、iOSもAndroidもガッツリ と開発してきた人間です。
5. • 自由主義でいこう • 創造性がなければ意味がない • ユーザの理想から始める • スピードで驚かす • 迷ったら挑戦する道を選ぶ • 渦中の友を助ける • 異能は才能 ユーザベース 7つのルール 5
6. 技術的負債ってなんで起きるんだっけ？(Why) いつ解消する？(When) 誰が判断する(Who) どうやる？(How) 大事なこと 01 02 03 04 05 6 目次
7. 01 | 技術的負債ってなんで起きるんだっ け？(Why)
8. 8 無鉄砲 慎重 意 図 的 無 意 識 設計する時間がないん だからしょうがない レイヤー化？なにそ れ？ 今すぐリリースしないと いけない。あとでどうに かしよう もっとこうすべきだった なぁ 技術的負債の4象限 by マーチンファウラー https://martinfowler.com/bliki/TechnicalDebtQuadrant.html 01 | 技術的負債ってなんで起きるんだっけ？
9. 9 割れ窓理論 長期間修正されることのない割れた窓が1枚でもあると誰 も建物のことなど気にもかけないような感覚になり、次の 窓が割れ、ゴミが撒き散らかされるようになります。落書 きもされます。そして、ごく短期間で建物に深刻な毀損が 起こり始めます。 01 | 技術的負債ってなんで起きるんだっけ？
10. 02 | いつ解消する？(When)
11. 11 割れた窓を放置しておかないこと 割れた窓（つまり、質の悪いコード・設計）をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 02 | いつ解消する？
12. 12 割れた窓を放置しておかないこと 割れた窓（つまり、質の悪いコード・設計）をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 02 | いつ解消する？
13. 13 割れた窓を放置しておかないこと 割れた窓（つまり、質の悪いコード・設計）をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 いや、すでに無理！！ 割れてる窓は1枚どころじゃなく、街全体が 崩壊してるのに全部を修復する時間ないよ 02 | いつ解消する？
14. 14 割れた窓を放置しておかないこと 割れた窓（つまり、質の悪いコード・設計）をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 はっきり言えるのは、明示したところで ほぼ効果ない。良いコード を書かないと何も解決されない。 悪いコードをコメントアウトしたら機能なくなっちゃうし。 02 | いつ解消する？
15. じゃあ、いつ解消するか 15 02 | いつ解消する？
16. 正直いうとここ10年で一番ひどいコード。 少し触るだけでバグが出る。 もう辞める... 優秀な業務委託の方 16 02 | いつ解消する？
17. このままでは昔からいる人が万が一辞めて しまったら、開発スピードは確実に落ちる し、バグも増える。何よりも技術スタック 的にも魅力がなくて優秀なエンジニアを採 用できない。たとえ採用できてもスピード が出せない。 法人開発者リーダー（表） 17 02 | いつ解消する？
18. このまま何年も実装していくのはつまらん な。技術者としてこれ続けると終わってい きそうで不安だ。モチベーションあがら ん。 あと法人の機能は、俺じゃなくてもスマ フォ経験値が少ない開発者でも実装できる ようにしたいな。俺、楽になるし。 18 法人開発者リーダー（裏） 02 | いつ解消する？
19. つまりDX（開発者体験）が著し く低下していると感じたとき • これ以上、このコードは触りたくない • ユーザ体験をよくしたいのにできない 19 02 | いつ解消する？
20. つまりDX（開発者体験）が著し く低下していると感じたとき 20 改善する意志がある人物 が出てきたとき 02 | いつ解消する？
21. 03 | 誰が判断する(Who)
22. 22 無鉄砲 慎重 意 図 的 無 意 識 設計する時間がないん だからしょうがない レイヤー化？なにそ れ？ 今すぐリリースしないと いけない。あとでどうに かしよう もっとこうすべきだった なぁ 技術的負債の4象限 by マーチンファウラー https://martinfowler.com/bliki/TechnicalDebtQuadrant.html 03 | 誰が判断する？
23. 「毎回、技術者から技術的負債があるから リニューアルで解決しましょう」と言われ てやるんだけど、結局、障害数も変わらな いし、改善された試しがないんだよね 上場会社の副社長 23 03 | 誰が判断する？
24. 改善する意志がある人物が出て きたとき 24 良いコードの知識・経験 がある人が判断する 03 | 誰が判断する？
25. 04 | どうやる?(How)
26. 技術的負債の返済に理解のない 組織の場合（例） プログラマー以外が見ても優先度が上がる ように技術的負債の見せ方を変えればいい 04 | どうやる？ 26
27. 27 見える 見えない ポ ジ テ ィ ブ ネ ガ テ ィ ブ 新機能 バグ アーキテクチャ 技術的負債 バックログの4象限 by フィリップ・クルーシュテン https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw are-architecture/ 04 | どうやる？
28. 28 見える 見えない ポ ジ テ ィ ブ ネ ガ テ ィ ブ 新機能 バグ アーキテクチャ 技術的負債 バックログの4象限 by フィリップ・クルーシュテン https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw are-architecture/ 04 | どうやる？
29. 技術的負債の返済に理解がある 組織の場合 やればいい。 モジュール分割/依存度や 結合度と凝集度の知識は必要 29 04 | どうやる？
30. とはいえ、ビジネス止められないので 少しづつ解消していく必要がある 30 04 | どうやる？
31. 最初に手を付けるべき解消箇所 それは依存性の方向性を決めること • レイヤードアーキテクチャとマルチモ ジュール化は必須 • 既存のアーキテクチャに縛られない方 がうまくいく -> 旧はlegacyに突っ込む 31 04 | どうやる？
32. 32 • ポイントは古いコードはすべて legacyに突っ込むこと(できない場合はappモジュール) • ui -> UIに関連する全て。Activity,Fragment,ViewModel。ViewModelは全くViewに依存させない • infrastructures -> 永続レイヤー。HttpやDBにアクセスする • domains -> ビジネスロジック, ValueObject, EntityなどDDDの考えを取り入れた • 明確な役割のあるレイヤーで分割することで依存させるライブラリを変える • コンパイラーに任せる 04 | どうやる？
33. 33 • 依存性逆転を容易にしたいので DI導入(Dagger Hilt) • 非同期処理はCoroutines Flow • StateFlowで状態管理 04 | どうやる？
34. 34 legacyモジュール domainモジュール 古いコードに依存 させないため 依存性逆転の原則が段階的技術的負債の解消に何故いいのか 04 | どうやる？
35. 35 legacyモジュール domainモジュール 依存性逆転の原則が段階的技術的負債の解消に何故いいのか
36. 36 新しいコードを汚いコードに依 存させずに古いコードを使える たとえば・・・ • 新アーキのActivityから旧アーキの Activityに遷移可能 • 新アーキは汚いコードに汚染されない 結果
37. ストラングラーパターンで旧 コードを新しくする 大きめのリファクタリングをする場合に旧 コードに影響を与えずに新コードをmaster にマージしていく 37 04 | どうやる？
38. 38 Push受信時のクラス 旧 MyFcmListenerService -> 新 FirebaseMessagingService に書き換えたい 04 | どうやる？
39. 39 新 Push受信クラスのテストが終わった段階で本番に繋げる 04 | どうやる？
40. 40 新しいコードをmasterに入れる ので、旧コードの変更にも一緒 に追随できる 別ブランチにあるわけでもなく、コメント アウトしてるわけではなく、本番コードに 旧も新のコードも存在するので、両方とも コンパイラーが動き、既存の動作を確認し ながら修正できる 結果
41. Utilsクラス/Staticメソッドだ らけの解消方法 責務にあったクラスを作成する DDDでいうところのValue Objectを作成す る Kotllinの拡張関数で置き換え 41 04 | どうやる？
42. 42 Value Objectの例 04 | どうやる？
43. 43 細かな処理の責務が明確になる / ドメインロジックが見えてくる 特にValue Objectの場合は、その型のまま 扱える。プリミティブ型、たとえば、 Stringで引数に渡っていくより、型安全に 使える 結果
44. Repositoryで実装を隠蔽するこ とによる負債の解消方法 • キャッシュ・アプリ内DB・APIのどこか ら取得するかの意識が必要問題 • 同期？非同期？ • 非同期処理がコールバックインター フェイスを利用している問題 44 04 | どうやる？
45. 1. SharedPreference / Realm / Roomなどは全てInfrastruturesのDaoに移動する。 2. Daoはinternalにし、外部からはRepository経由でしかアクセスできないようにする 3. HttpClientも外部からはRepository経由でしかアクセスできないようにする 4. キャッシュ機構はRepositoryに持たせる 5. 全ての戻り値はFlowにする 6. 扱う側は、キャッシュなのかAPIなのかはわからないが同じインターフェイスでアクセスす るだけ 方法 04 | どうやる？
46. 46 余計なロジックが排除される、 必要データが取れないなどのエ ラーがなくなる キャッシュは同期、APIは非同期とやるから 余計なロジックが必要になる。 全てFlowで対応し、Repositoryに隠蔽した ことでシンプルに利用できる 結果
47. 状態変化の管理が難しい問題の 解決 シングルトンクラスだらけで、それが状態 を持っていて、手続き的に処理している。 ほぼそれってグローバル変数。 いろんな箇所で情報を保持し、更新するか ら複雑になる 47 04 | どうやる？
48. 48 Single Source of Truth と Observer 04 | どうやる？
49. 49 コードを深く読み込まなくとも データを把握できる。値の変更 が勝手に反映される データが一つのクラスにまとまっていて、 変更箇所もカプセル化されるので、デバッ グが容易。 結果
50. Viewのロジックが複雑問題の解 決 カスタムViewが複雑すぎる。再利用性がな い。 原因は、 • スタンプ結合（巨大な構造体が渡され ている） • ビジネスロジックがViewにある 50 04 | どうやる？
51. 51 • DataBindingを使ってる場合は、ほと んどの場合カスタム Viewは不要 • <include>だけで十分 • Viewにはロジックを持たせず、外か ら渡す • Composeの場合も外からロジックや データを渡す 04 | どうやる？
52. 52 単体テスト可能な部分と不要な 部分を分けることができる （Humble Objectパターン) テスト可能なViewModelに処理を持ってこ れるので、品質・生産性向上に寄与できる 結果
53. 05 | 大事なこと
54. 技術的負債の解消をすることで ・・・ 負債を解消した箇所（uiモジュール以降）と 解消前（legacyモジュール）での生産性の 差は、昔からいるメンバーで1.5倍以上違 う。 昔からいるメンバーはコードの属人化知識 があるため、新人の場合は10倍以上ありそ う。 54 05 | 大事なこと
55. 55 • 技術的負債の解消で、生産性は必ず上がる • 意思と知識があれば、技術的負債の解消は絶 対できるよ • ただし、組織の文化は大事。（意思を実現し やすいかどうか） • 文化が寛容でなくとも技術的負債を別の問題 として見える化すると進めやすいよ
56. ご清聴ありがとうございました 56