Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
段階的な技術的負債の解消方法.pdf
Search
ko2ic
August 01, 2022
Programming
2
1.7k
段階的な技術的負債の解消方法.pdf
ko2ic
August 01, 2022
Tweet
Share
More Decks by ko2ic
See All by ko2ic
モバイルでもエリートDevOpsチームを目指そう
ko2ic
0
86
50回面接して学んだ強い技術者チームを作る採用とオンボーディング
ko2ic
0
450
ビジネス中心に7年間走り続けたAndroidをリアーキしてる話
ko2ic
0
16
Other Decks in Programming
See All in Programming
Microsoft Fabricを7ヶ月使ってわかったこと
shun_oshidari
2
450
Reckoner の Scala プロジェクトにおける オブザーバビリティの取り組み / Observability Initiatives in Reckoner's Scala Project
nomadblacky
0
810
シェルの履歴とイクンリメンタル検索を使う
naoya
7
2.3k
「Hono遍歴」と「HonoXでブログ作成」
yasu551
0
170
TokyoR#111_ANOVA
kilometer
1
710
TerraformをやめてCDKでReStartしたあと、 CDKをやめてCDK for TerraformでReStartした話
tmiura0203
0
770
sbt-assemblyにハマってDB接続できず時間が溶けた話
wakye5815
1
660
document.write再考
brn
5
1.8k
Spring Boot 2 to Spring Boot 3 with Java 21 and Jakarta EE
ivargrimstad
0
820
OpCode目線で眺める PHPコードのカバレッジ
o0h
PRO
2
470
Не учите алгоритмы
hellsquirrel
1
700
Catch Up with Swift 5.10
ojun9
1
450
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
23
1.9k
Making Projects Easy
brettharned
106
5.4k
Keith and Marios Guide to Fast Websites
keithpitt
407
22k
Learning to Love Humans: Emotional Interface Design
aarron
266
39k
What the flash - Photography Introduction
edds
64
11k
Optimising Largest Contentful Paint
csswizardry
7
2.3k
Scaling GitHub
holman
456
140k
Large-scale JavaScript Application Architecture
addyosmani
501
110k
Building an army of robots
kneath
300
41k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
6
930
Adopting Sorbet at Scale
ufuk
66
8.5k
Building Flexible Design Systems
yeseniaperezcruz
317
37k
Transcript
段階的な技術的負債の解消方法 TechBase vol.2 2022/07/28 Koji Ishii
2 自己紹介 NewsPicks Mobile Unit (iOS 7名 Android 6名) エンジニアリングマネージャー
Android中心に開発 iOSは全然書いてない
3 自己紹介 こんな本を書いてました。 経験として、iOSもAndroidもガッツリ と開発してきた人間です。
4
• 自由主義でいこう • 創造性がなければ意味がない • ユーザの理想から始める • スピードで驚かす • 迷ったら挑戦する道を選ぶ
• 渦中の友を助ける • 異能は才能 ユーザベース 7つのルール 5
技術的負債ってなんで起きるんだっけ?(Why) いつ解消する?(When) 誰が判断する(Who) どうやる?(How) 大事なこと 01 02 03 04 05
6 目次
01 | 技術的負債ってなんで起きるんだっ け?(Why)
8 無鉄砲 慎重 意 図 的 無 意 識 設計する時間がないん
だからしょうがない レイヤー化?なにそ れ? 今すぐリリースしないと いけない。あとでどうに かしよう もっとこうすべきだった なぁ 技術的負債の4象限 by マーチンファウラー https://martinfowler.com/bliki/TechnicalDebtQuadrant.html 01 | 技術的負債ってなんで起きるんだっけ?
9 割れ窓理論 長期間修正されることのない割れた窓が1枚でもあると誰 も建物のことなど気にもかけないような感覚になり、次の 窓が割れ、ゴミが撒き散らかされるようになります。落書 きもされます。そして、ごく短期間で建物に深刻な毀損が 起こり始めます。 01 | 技術的負債ってなんで起きるんだっけ?
02 | いつ解消する?(When)
11 割れた窓を放置しておかないこと 割れた窓(つまり、質の悪いコード・設計)をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 02 | いつ解消する?
12 割れた窓を放置しておかないこと 割れた窓(つまり、質の悪いコード・設計)をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 02 | いつ解消する?
13 割れた窓を放置しておかないこと 割れた窓(つまり、質の悪いコード・設計)をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 いや、すでに無理!! 割れてる窓は1枚どころじゃなく、街全体が 崩壊してるのに全部を修復する時間ないよ 02
| いつ解消する?
14 割れた窓を放置しておかないこと 割れた窓(つまり、質の悪いコード・設計)をそのままに してはいけません。発見と同時に修復するのです。もし正 しく修復するだけの十分な時間がないのであれば、その旨 をわかりやすく明示しておくのです。 はっきり言えるのは、明示したところで ほぼ効果ない。良いコード を書かないと何も解決されない。 悪いコードをコメントアウトしたら機能なくなっちゃうし。
02 | いつ解消する?
じゃあ、いつ解消するか 15 02 | いつ解消する?
正直いうとここ10年で一番ひどいコード。 少し触るだけでバグが出る。 もう辞める... 優秀な業務委託の方 16 02 | いつ解消する?
このままでは昔からいる人が万が一辞めて しまったら、開発スピードは確実に落ちる し、バグも増える。何よりも技術スタック 的にも魅力がなくて優秀なエンジニアを採 用できない。たとえ採用できてもスピード が出せない。 法人開発者リーダー(表) 17 02 |
いつ解消する?
このまま何年も実装していくのはつまらん な。技術者としてこれ続けると終わってい きそうで不安だ。モチベーションあがら ん。 あと法人の機能は、俺じゃなくてもスマ フォ経験値が少ない開発者でも実装できる ようにしたいな。俺、楽になるし。 18 法人開発者リーダー(裏) 02
| いつ解消する?
つまりDX(開発者体験)が著し く低下していると感じたとき • これ以上、このコードは触りたくない • ユーザ体験をよくしたいのにできない 19 02 | いつ解消する?
つまりDX(開発者体験)が著し く低下していると感じたとき 20 改善する意志がある人物 が出てきたとき 02 | いつ解消する?
03 | 誰が判断する(Who)
22 無鉄砲 慎重 意 図 的 無 意 識 設計する時間がないん
だからしょうがない レイヤー化?なにそ れ? 今すぐリリースしないと いけない。あとでどうに かしよう もっとこうすべきだった なぁ 技術的負債の4象限 by マーチンファウラー https://martinfowler.com/bliki/TechnicalDebtQuadrant.html 03 | 誰が判断する?
「毎回、技術者から技術的負債があるから リニューアルで解決しましょう」と言われ てやるんだけど、結局、障害数も変わらな いし、改善された試しがないんだよね 上場会社の副社長 23 03 | 誰が判断する?
改善する意志がある人物が出て きたとき 24 良いコードの知識・経験 がある人が判断する 03 | 誰が判断する?
04 | どうやる?(How)
技術的負債の返済に理解のない 組織の場合(例) プログラマー以外が見ても優先度が上がる ように技術的負債の見せ方を変えればいい 04 | どうやる? 26
27 見える 見えない ポ ジ テ ィ ブ ネ ガ
テ ィ ブ 新機能 バグ アーキテクチャ 技術的負債 バックログの4象限 by フィリップ・クルーシュテン https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw are-architecture/ 04 | どうやる?
28 見える 見えない ポ ジ テ ィ ブ ネ ガ
テ ィ ブ 新機能 バグ アーキテクチャ 技術的負債 バックログの4象限 by フィリップ・クルーシュテン https://philippe.kruchten.com/2013/12/11/the-missing-value-of-softw are-architecture/ 04 | どうやる?
技術的負債の返済に理解がある 組織の場合 やればいい。 モジュール分割/依存度や 結合度と凝集度の知識は必要 29 04 | どうやる?
とはいえ、ビジネス止められないので 少しづつ解消していく必要がある 30 04 | どうやる?
最初に手を付けるべき解消箇所 それは依存性の方向性を決めること • レイヤードアーキテクチャとマルチモ ジュール化は必須 • 既存のアーキテクチャに縛られない方 がうまくいく -> 旧はlegacyに突っ込む
31 04 | どうやる?
32 • ポイントは古いコードはすべて legacyに突っ込むこと(できない場合はappモジュール) • ui -> UIに関連する全て。Activity,Fragment,ViewModel。ViewModelは全くViewに依存させない • infrastructures
-> 永続レイヤー。HttpやDBにアクセスする • domains -> ビジネスロジック, ValueObject, EntityなどDDDの考えを取り入れた • 明確な役割のあるレイヤーで分割することで依存させるライブラリを変える • コンパイラーに任せる 04 | どうやる?
33 • 依存性逆転を容易にしたいので DI導入(Dagger Hilt) • 非同期処理はCoroutines Flow • StateFlowで状態管理
04 | どうやる?
34 legacyモジュール domainモジュール 古いコードに依存 させないため 依存性逆転の原則が段階的技術的負債の解消に何故いいのか 04 | どうやる?
35 legacyモジュール domainモジュール 依存性逆転の原則が段階的技術的負債の解消に何故いいのか
36 新しいコードを汚いコードに依 存させずに古いコードを使える たとえば・・・ • 新アーキのActivityから旧アーキの Activityに遷移可能 • 新アーキは汚いコードに汚染されない 結果
ストラングラーパターンで旧 コードを新しくする 大きめのリファクタリングをする場合に旧 コードに影響を与えずに新コードをmaster にマージしていく 37 04 | どうやる?
38 Push受信時のクラス 旧 MyFcmListenerService -> 新 FirebaseMessagingService に書き換えたい 04 |
どうやる?
39 新 Push受信クラスのテストが終わった段階で本番に繋げる 04 | どうやる?
40 新しいコードをmasterに入れる ので、旧コードの変更にも一緒 に追随できる 別ブランチにあるわけでもなく、コメント アウトしてるわけではなく、本番コードに 旧も新のコードも存在するので、両方とも コンパイラーが動き、既存の動作を確認し ながら修正できる 結果
Utilsクラス/Staticメソッドだ らけの解消方法 責務にあったクラスを作成する DDDでいうところのValue Objectを作成す る Kotllinの拡張関数で置き換え 41 04 |
どうやる?
42 Value Objectの例 04 | どうやる?
43 細かな処理の責務が明確になる / ドメインロジックが見えてくる 特にValue Objectの場合は、その型のまま 扱える。プリミティブ型、たとえば、 Stringで引数に渡っていくより、型安全に 使える 結果
Repositoryで実装を隠蔽するこ とによる負債の解消方法 • キャッシュ・アプリ内DB・APIのどこか ら取得するかの意識が必要問題 • 同期?非同期? • 非同期処理がコールバックインター フェイスを利用している問題
44 04 | どうやる?
1. SharedPreference / Realm / Roomなどは全てInfrastruturesのDaoに移動する。 2. Daoはinternalにし、外部からはRepository経由でしかアクセスできないようにする 3. HttpClientも外部からはRepository経由でしかアクセスできないようにする
4. キャッシュ機構はRepositoryに持たせる 5. 全ての戻り値はFlowにする 6. 扱う側は、キャッシュなのかAPIなのかはわからないが同じインターフェイスでアクセスす るだけ 方法 04 | どうやる?
46 余計なロジックが排除される、 必要データが取れないなどのエ ラーがなくなる キャッシュは同期、APIは非同期とやるから 余計なロジックが必要になる。 全てFlowで対応し、Repositoryに隠蔽した ことでシンプルに利用できる 結果
状態変化の管理が難しい問題の 解決 シングルトンクラスだらけで、それが状態 を持っていて、手続き的に処理している。 ほぼそれってグローバル変数。 いろんな箇所で情報を保持し、更新するか ら複雑になる 47 04 |
どうやる?
48 Single Source of Truth と Observer 04 | どうやる?
49 コードを深く読み込まなくとも データを把握できる。値の変更 が勝手に反映される データが一つのクラスにまとまっていて、 変更箇所もカプセル化されるので、デバッ グが容易。 結果
Viewのロジックが複雑問題の解 決 カスタムViewが複雑すぎる。再利用性がな い。 原因は、 • スタンプ結合(巨大な構造体が渡され ている) • ビジネスロジックがViewにある
50 04 | どうやる?
51 • DataBindingを使ってる場合は、ほと んどの場合カスタム Viewは不要 • <include>だけで十分 • Viewにはロジックを持たせず、外か ら渡す
• Composeの場合も外からロジックや データを渡す 04 | どうやる?
52 単体テスト可能な部分と不要な 部分を分けることができる (Humble Objectパターン) テスト可能なViewModelに処理を持ってこ れるので、品質・生産性向上に寄与できる 結果
05 | 大事なこと
技術的負債の解消をすることで ・・・ 負債を解消した箇所(uiモジュール以降)と 解消前(legacyモジュール)での生産性の 差は、昔からいるメンバーで1.5倍以上違 う。 昔からいるメンバーはコードの属人化知識 があるため、新人の場合は10倍以上ありそ う。 54
05 | 大事なこと
55 • 技術的負債の解消で、生産性は必ず上がる • 意思と知識があれば、技術的負債の解消は絶 対できるよ • ただし、組織の文化は大事。(意思を実現し やすいかどうか) •
文化が寛容でなくとも技術的負債を別の問題 として見える化すると進めやすいよ
ご清聴ありがとうございました 56