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

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

41e5cd2b99a8e7c84f91a8137c8be3ed?s=47 ko2ic
August 01, 2022

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

41e5cd2b99a8e7c84f91a8137c8be3ed?s=128

ko2ic

August 01, 2022
Tweet

Other Decks in Programming

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もガッツリ と開発してきた人間です。

  4. 4

  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