Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ko2ic
August 01, 2022

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

ko2ic

August 01, 2022
Tweet

More Decks by ko2ic

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. 8
    無鉄砲 慎重






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

    View full-size slide

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

    View full-size slide

  9. 02 |
    いつ解消する?(When)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. 22
    無鉄砲 慎重






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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. 27
    見える 見えない










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

    View full-size slide

  27. 28
    見える 見えない










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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. Utilsクラス/Staticメソッドだ
    らけの解消方法
    責務にあったクラスを作成する
    DDDでいうところのValue Objectを作成す

    Kotllinの拡張関数で置き換え
    41
    04 | どうやる?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  47. 48
    Single Source of Truth

    Observer
    04 | どうやる?

    View full-size slide

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

    View full-size slide

  49. Viewのロジックが複雑問題の解

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  52. 05 |
    大事なこと

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide