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

by ko2ic

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

03 | 誰が判断する(Who)

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

04 | どうやる?(How)

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

05 | 大事なこと

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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