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

Transcript

1. 段階的な技術的負債の解消方法
   TechBase vol.2
   2022/07/28
   Koji Ishii
   

   View Slide

2. 2
   自己紹介
   NewsPicks Mobile Unit
   （iOS 7名 Android 6名）
   エンジニアリングマネージャー
   Android中心に開発
   iOSは全然書いてない
   

   View Slide

3. 3
   自己紹介
   こんな本を書いてました。
   経験として、iOSもAndroidもガッツリ
   と開発してきた人間です。
   

   View Slide

4. View Slide

5. ● 自由主義でいこう
   ● 創造性がなければ意味がない
   ● ユーザの理想から始める
   ● スピードで驚かす
   ● 迷ったら挑戦する道を選ぶ
   ● 渦中の友を助ける
   ● 異能は才能
   ユーザベース 7つのルール
   5
   

   View Slide

6. 技術的負債ってなんで起きるんだっけ？(Why)
   いつ解消する？(When)
   誰が判断する(Who)
   どうやる？(How)
   大事なこと
   01
   02
   03
   04
   05
   6
   目次
   

   View Slide

7. 01 |
   技術的負債ってなんで起きるんだっ
   け？(Why)
   

   View Slide

8. 8
   無鉄砲 慎重
   意
   図
   的
   無
   意
   識
   設計する時間がないん
   だからしょうがない
   レイヤー化？なにそ
   れ？
   今すぐリリースしないと
   いけない。あとでどうに
   かしよう
   もっとこうすべきだった
   なぁ
   技術的負債の4象限 by マーチンファウラー
   https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
   01 | 技術的負債ってなんで起きるんだっけ？
   

   View Slide

9. 9
   割れ窓理論
   長期間修正されることのない割れた窓が1枚でもあると誰
   も建物のことなど気にもかけないような感覚になり、次の
   窓が割れ、ゴミが撒き散らかされるようになります。落書
   きもされます。そして、ごく短期間で建物に深刻な毀損が
   起こり始めます。
   01 | 技術的負債ってなんで起きるんだっけ？
   

   View Slide

10. 02 |
    いつ解消する？(When)
    

    View Slide

11. 11
    割れた窓を放置しておかないこと
    割れた窓（つまり、質の悪いコード・設計）をそのままに
    してはいけません。発見と同時に修復するのです。もし正
    しく修復するだけの十分な時間がないのであれば、その旨
    をわかりやすく明示しておくのです。
    02 | いつ解消する？
    

    View Slide

12. 12
    割れた窓を放置しておかないこと
    割れた窓（つまり、質の悪いコード・設計）をそのままに
    してはいけません。発見と同時に修復するのです。もし正
    しく修復するだけの十分な時間がないのであれば、その旨
    をわかりやすく明示しておくのです。
    02 | いつ解消する？
    

    View Slide

13. 13
    割れた窓を放置しておかないこと
    割れた窓（つまり、質の悪いコード・設計）をそのままに
    してはいけません。発見と同時に修復するのです。もし正
    しく修復するだけの十分な時間がないのであれば、その旨
    をわかりやすく明示しておくのです。
    いや、すでに無理！！
    割れてる窓は1枚どころじゃなく、街全体が
    崩壊してるのに全部を修復する時間ないよ
    02 | いつ解消する？
    

    View Slide

14. 14
    割れた窓を放置しておかないこと
    割れた窓（つまり、質の悪いコード・設計）をそのままに
    してはいけません。発見と同時に修復するのです。もし正
    しく修復するだけの十分な時間がないのであれば、その旨
    をわかりやすく明示しておくのです。
    はっきり言えるのは、明示したところで ほぼ効果ない。良いコード
    を書かないと何も解決されない。
    悪いコードをコメントアウトしたら機能なくなっちゃうし。
    02 | いつ解消する？
    

    View Slide

15. じゃあ、いつ解消するか
    15
    02 | いつ解消する？
    

    View Slide

16. 正直いうとここ10年で一番ひどいコード。
    少し触るだけでバグが出る。
    もう辞める...
    優秀な業務委託の方
    16
    02 | いつ解消する？
    

    View Slide

17. このままでは昔からいる人が万が一辞めて
    しまったら、開発スピードは確実に落ちる
    し、バグも増える。何よりも技術スタック
    的にも魅力がなくて優秀なエンジニアを採
    用できない。たとえ採用できてもスピード
    が出せない。
    法人開発者リーダー（表）
    17
    02 | いつ解消する？
    

    View Slide

18. このまま何年も実装していくのはつまらん
    な。技術者としてこれ続けると終わってい
    きそうで不安だ。モチベーションあがら
    ん。
    あと法人の機能は、俺じゃなくてもスマ
    フォ経験値が少ない開発者でも実装できる
    ようにしたいな。俺、楽になるし。
    18
    法人開発者リーダー（裏）
    02 | いつ解消する？
    

    View Slide

19. つまりDX（開発者体験）が著し
    く低下していると感じたとき
    ● これ以上、このコードは触りたくない
    ● ユーザ体験をよくしたいのにできない
    19
    02 | いつ解消する？
    

    View Slide

20. つまりDX（開発者体験）が著し
    く低下していると感じたとき
    20
    改善する意志がある人物
    が出てきたとき
    02 | いつ解消する？
    

    View Slide

21. 03 |
    誰が判断する(Who)
    

    View Slide

22. 22
    無鉄砲 慎重
    意
    図
    的
    無
    意
    識
    設計する時間がないん
    だからしょうがない
    レイヤー化？なにそ
    れ？
    今すぐリリースしないと
    いけない。あとでどうに
    かしよう
    もっとこうすべきだった
    なぁ
    技術的負債の4象限 by マーチンファウラー
    https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
    03 | 誰が判断する？
    

    View Slide

23. 「毎回、技術者から技術的負債があるから
    リニューアルで解決しましょう」と言われ
    てやるんだけど、結局、障害数も変わらな
    いし、改善された試しがないんだよね
    上場会社の副社長
    23
    03 | 誰が判断する？
    

    View Slide

24. 改善する意志がある人物が出て
    きたとき
    24
    良いコードの知識・経験
    がある人が判断する
    03 | 誰が判断する？
    

    View Slide

25. 04 |
    どうやる?(How)
    

    View Slide

26. 技術的負債の返済に理解のない
    組織の場合（例）
    プログラマー以外が見ても優先度が上がる
    ように技術的負債の見せ方を変えればいい
    04 | どうやる？ 26
    

    View Slide

27. 27
    見える 見えない
    ポ
    ジ
    テ
    ィ
    ブ
    ネ
    ガ
    テ
    ィ
    ブ
    新機能
    バグ
    アーキテクチャ
    技術的負債
    バックログの4象限 by フィリップ・クルーシュテン
    https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw
    are-architecture/
    04 | どうやる？
    

    View Slide

28. 28
    見える 見えない
    ポ
    ジ
    テ
    ィ
    ブ
    ネ
    ガ
    テ
    ィ
    ブ
    新機能
    バグ
    アーキテクチャ
    技術的負債
    バックログの4象限 by フィリップ・クルーシュテン
    https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw
    are-architecture/
    04 | どうやる？
    

    View Slide

29. 技術的負債の返済に理解がある
    組織の場合
    やればいい。
    モジュール分割/依存度や
    結合度と凝集度の知識は必要
    29
    04 | どうやる？
    

    View Slide

30. とはいえ、ビジネス止められないので
    少しづつ解消していく必要がある
    30
    04 | どうやる？
    

    View Slide

31. 最初に手を付けるべき解消箇所
    それは依存性の方向性を決めること
    ● レイヤードアーキテクチャとマルチモ
    ジュール化は必須
    ● 既存のアーキテクチャに縛られない方
    がうまくいく
    -> 旧はlegacyに突っ込む
    31
    04 | どうやる？
    

    View Slide

32. 32
    ● ポイントは古いコードはすべて
    legacyに突っ込むこと(できない場合はappモジュール)
    ● ui -> UIに関連する全て。Activity,Fragment,ViewModel。ViewModelは全くViewに依存させない
    ● infrastructures -> 永続レイヤー。HttpやDBにアクセスする
    ● domains -> ビジネスロジック, ValueObject, EntityなどDDDの考えを取り入れた
    ● 明確な役割のあるレイヤーで分割することで依存させるライブラリを変える
    ● コンパイラーに任せる
    04 | どうやる？
    

    View Slide

33. 33
    ● 依存性逆転を容易にしたいので
    DI導入(Dagger Hilt)
    ● 非同期処理はCoroutines Flow
    ● StateFlowで状態管理
    04 | どうやる？
    

    View Slide

34. 34
    legacyモジュール
    domainモジュール
    古いコードに依存
    させないため
    依存性逆転の原則が段階的技術的負債の解消に何故いいのか
    04 | どうやる？
    

    View Slide

35. 35
    legacyモジュール
    domainモジュール
    依存性逆転の原則が段階的技術的負債の解消に何故いいのか
    

    View Slide

36. 36
    新しいコードを汚いコードに依
    存させずに古いコードを使える
    たとえば・・・
    ● 新アーキのActivityから旧アーキの
    Activityに遷移可能
    ● 新アーキは汚いコードに汚染されない
    結果
    

    View Slide

37. ストラングラーパターンで旧
    コードを新しくする
    大きめのリファクタリングをする場合に旧
    コードに影響を与えずに新コードをmaster
    にマージしていく
    37
    04 | どうやる？
    

    View Slide

38. 38
    Push受信時のクラス
    旧 MyFcmListenerService -> 新 FirebaseMessagingService に書き換えたい
    04 | どうやる？
    

    View Slide

39. 39
    新 Push受信クラスのテストが終わった段階で本番に繋げる
    04 | どうやる？
    

    View Slide

40. 40
    新しいコードをmasterに入れる
    ので、旧コードの変更にも一緒
    に追随できる
    別ブランチにあるわけでもなく、コメント
    アウトしてるわけではなく、本番コードに
    旧も新のコードも存在するので、両方とも
    コンパイラーが動き、既存の動作を確認し
    ながら修正できる
    結果
    

    View Slide

41. Utilsクラス/Staticメソッドだ
    らけの解消方法
    責務にあったクラスを作成する
    DDDでいうところのValue Objectを作成す
    る
    Kotllinの拡張関数で置き換え
    41
    04 | どうやる？
    

    View Slide

42. 42
    Value Objectの例
    04 | どうやる？
    

    View Slide

43. 43
    細かな処理の責務が明確になる /
    ドメインロジックが見えてくる
    特にValue Objectの場合は、その型のまま
    扱える。プリミティブ型、たとえば、
    Stringで引数に渡っていくより、型安全に
    使える
    結果
    

    View Slide

44. Repositoryで実装を隠蔽するこ
    とによる負債の解消方法
    ● キャッシュ・アプリ内DB・APIのどこか
    ら取得するかの意識が必要問題
    ● 同期？非同期？
    ● 非同期処理がコールバックインター
    フェイスを利用している問題
    44
    04 | どうやる？
    

    View Slide

45. 1. SharedPreference / Realm / Roomなどは全てInfrastruturesのDaoに移動する。
    2. Daoはinternalにし、外部からはRepository経由でしかアクセスできないようにする
    3. HttpClientも外部からはRepository経由でしかアクセスできないようにする
    4. キャッシュ機構はRepositoryに持たせる
    5. 全ての戻り値はFlowにする
    6. 扱う側は、キャッシュなのかAPIなのかはわからないが同じインターフェイスでアクセスす
    るだけ
    方法
    04 | どうやる？
    

    View Slide

46. 46
    余計なロジックが排除される、
    必要データが取れないなどのエ
    ラーがなくなる
    キャッシュは同期、APIは非同期とやるから
    余計なロジックが必要になる。
    全てFlowで対応し、Repositoryに隠蔽した
    ことでシンプルに利用できる
    結果
    

    View Slide

47. 状態変化の管理が難しい問題の
    解決
    シングルトンクラスだらけで、それが状態
    を持っていて、手続き的に処理している。
    ほぼそれってグローバル変数。
    いろんな箇所で情報を保持し、更新するか
    ら複雑になる
    47
    04 | どうやる？
    

    View Slide

48. 48
    Single Source of Truth
    と
    Observer
    04 | どうやる？
    

    View Slide

49. 49
    コードを深く読み込まなくとも
    データを把握できる。値の変更
    が勝手に反映される
    データが一つのクラスにまとまっていて、
    変更箇所もカプセル化されるので、デバッ
    グが容易。
    結果
    

    View Slide

50. Viewのロジックが複雑問題の解
    決
    カスタムViewが複雑すぎる。再利用性がな
    い。
    原因は、
    ● スタンプ結合（巨大な構造体が渡され
    ている）
    ● ビジネスロジックがViewにある
    50
    04 | どうやる？
    

    View Slide

51. 51
    ● DataBindingを使ってる場合は、ほと
    んどの場合カスタム Viewは不要
    ● だけで十分
    ● Viewにはロジックを持たせず、外か
    ら渡す
    ● Composeの場合も外からロジックや
    データを渡す
    04 | どうやる？
    

    View Slide

52. 52
    単体テスト可能な部分と不要な
    部分を分けることができる
    （Humble Objectパターン)
    テスト可能なViewModelに処理を持ってこ
    れるので、品質・生産性向上に寄与できる
    結果
    

    View Slide

53. 05 |
    大事なこと
    

    View Slide

54. 技術的負債の解消をすることで
    ・・・
    負債を解消した箇所（uiモジュール以降）と
    解消前（legacyモジュール）での生産性の
    差は、昔からいるメンバーで1.5倍以上違
    う。
    昔からいるメンバーはコードの属人化知識
    があるため、新人の場合は10倍以上ありそ
    う。
    54
    05 | 大事なこと
    

    View Slide

55. 55
    ● 技術的負債の解消で、生産性は必ず上がる
    ● 意思と知識があれば、技術的負債の解消は絶
    対できるよ
    ● ただし、組織の文化は大事。（意思を実現し
    やすいかどうか）
    ● 文化が寛容でなくとも技術的負債を別の問題
    として見える化すると進めやすいよ
    

    View Slide

56. ご清聴ありがとうございました
    56
    

    View Slide