最初が肝心！技術的負債解消に向けて最初にやるべきこと/first-step-to-pay-off-technical-debt

by Takehiro Kaneko

Slide 1

Slide 1 text

最初が肝心！技術的負債解消に向けて最初にやるべきこと 2023.04.12 モバイルアプリの技術的負債みんなで学ぶ Lunch LT NewsPicks iOSエンジニア / 金子雄大

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

02 なぜ依存の方向を強制するのか？ ©NewsPicks Inc. All Rights Reserved.  ● フォルダ分けをしただけでシングルモジュール構成のままだと、新しいコードから古いコードを利用できてしまう ○ 負債を返済しているつもりが、新たな負債を生み出すことに... ● モジュールを分けて依存の方向を強制してしまえば、これができなくなる「古いコードは参照しない」というルールを決めても、それを継続し続けるのは実は難しいルールを強制してあげることで、新しいコードをキレイな状態に保ちながら、負債を返済していくことができる

Slide 14

Slide 14 text

02 依存の方向を強制することによるその他のメリット ©NewsPicks Inc. All Rights Reserved.  ● 何でも屋クラスが作られづらくなり、各クラスの責務が明確になる。さらに、その状態を維持しやすい ● ライブラリへの依存がモジュールに閉じるので、ライブラリを使ったコードが散らばらないし、ライブラリの更新、差し替えもしやすくなる負債が生まれにくく、かつ生まれても返済可能な状態を維持できる！

Slide 15

Slide 15 text

Slide 16

Slide 16 text

02 Adapterパターンを使った古いコードの利用方法 ©NewsPicks Inc. All Rights Reserved.  ● 利用したいクラス（例: SelfLogic）がLegacyモジュールにあるとする ● Domainモジュールに利用したい機能のインタフェースを定義したプロトコル（例: SeﬂLogicAdapter）を作成する ● SelfLogicをSelfLogicAdapterに準拠させる ● DIコンテナがPresentationモジュールのクラスにSelfLogicをインジェクトする

Slide 17

Slide 17 text

02 Adapterパターンを使った古いコードの利用方法 ©NewsPicks Inc. All Rights Reserved.  // MARK: - Domainモジュール protocol SelfLogicAdapter { func someLogic() } // MARK: - Legacyモジュール class SelfLogic { func someLogic() {...} } // SelfLogicAdapterに準拠させる extension SelfLogic: SelfLogicAdapter {} // MARK: - Presentationモジュール class NewsFeedresenter { private let selfLogic: SelfLogicAdapter init(selfLogic: SelfLogicAdapter) { // 実体はSelfLogicインスタンス self.selfLogic = selfLogic } } ● インジェクションをどうやるかはプロジェクトによって異なる

Slide 18

Slide 18 text

02 The Composable ArchitectureでのDIの例 ©NewsPicks Inc. All Rights Reserved.  // MARK: - Domainモジュール public enum SelfLogicAdapterKey: TestDependencyKey { public static let testValue: SelfLogicAdapter = MockSelfLogic() public static let previewValue: SelfLogicAdapter = MockSelfLogic() } public extension DependencyValues { var selfLogic: SelfLogicAdapter { get { self[SelfLogicAdapterKey.self] } set { self[SelfLogicAdapterKey.self] = newValue } } } // MARK: - Legacyモジュール extension SelfLogicAdapterKey: DependencyKey { public static let liveValue: SelfLogicAdapter = SelfLogic.shared } // MARK: - Presentationモジュール struct NewsFeedReducer: ReducerProtocol { @Dependency(\.selfLogic) var selfLogic func reduce(into state: inout State, action: Action) -> EffectTask { ... selfLogic.someLogic() } } ● DependencyValuesを使ってReducerに SelfLogicをインジェクトしている

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

02 なぜユニットテストの実装を強制するのか？ ©NewsPicks Inc. All Rights Reserved.  ● ユニットテストを実装するためには、テスタブルな設計にしなければならない。その結果、ロジックがシンプルで、可読性が高くなりやすい ○ 何でも屋クラスや、複雑過ぎるメソッドが作られづらくなる（負債化しにくくなる） ● ユニットテストの実装がしづらいと感じたら、プロダクションコードを見直すことになり、より良い設計にしようという意識が働く ○ どうすれば良い設計になるかをチームで議論する機会が明らかに増えた ● ユニットテストがあると、リファクタしやすくなる ○ 負債を継続的に返済していくための環境ができる負債が生まれにくく、かつ生まれても返済可能な状態を維持できる！

Slide 22

Slide 22 text

02 ユニットテストはバランスが大事 ©NewsPicks Inc. All Rights Reserved.  ● マルチモジュール化して依存の方向を強制したり、テスタブルにした結果、テストするまでもないシンプルなコードが多くなった ○ ロジックがほとんどないシンプルなコード、変わることがほとんどないコードについては、テストを書いてもコスパが悪い ● 比較的変更の多いプレゼンテーションロジックを中心にテストを書くのが良い