ひまプロリスナー的負債脱却のアプローチ

ひまプロリスナー的負債 脱却のアプローチ 技術負債との戦いの記録 1

自己紹介 HN: kobayashi yabako(@yabakobayashi) ● ● ● ● 動画配信事業を行っている企業のWebエンジニア Go/TypeScript/AndroidJava GCP/オンプレ やらかし記事に定評があります 2

• https://twitter.com/yabakobayashi

中級エンジニアを目指している皆 さん。 技術的負債と戦ってますか。 3

負債好きですか？ 4

今回は私が経験した小さいプロ ダクトを例にして、負債へのアプ ローチ方法を紹介します。 5

アジェンダ 1. 2. 3. 4. 発端 技術的負債とは 実際のケース 詳細 6

発端 ● ● ● 自社ECサイトからECサイト紹介サービスに提供している商品データが存在 データに関して、一部の商品が不足していると連絡 実際にデータを作っているバッチを調査 ● ● ● ● ● ● 商品A 商品B 商品C 商品D 商品E 不足 商品F ● ● ● ● ● ● 商品A 商品B 商品C 商品D 商品E 商品F 7

発端 ● 調査したところ単純なロジック間違いだったことが発覚 ○ ifの判定が逆だった(ひどい) たったこれだけに凄い時間がかかった (2日半ぐらい) 8

発端 ● なぜ時間がかかったのか？ ○ 初めて触るプロダクトだったから？ ○ 私個人の技術力が低いから？ 技術的負債があるプロダクトだから 9

発端 どこに問題があったか ● ● ● ● ● ● ● ● CI(自動テスト)がない ○ そもそもテストができない(UTもない) Deploy(Build)が冗長的 ローカル実行ができない(デバッグできない) いまは使われていないnpmライブラリ サポート切れが近いランタイム環境 ○ それによって動かなくなるコード インテリセンスが効かないコード 実際は使ってないロジック ○ ファイル単位で使ってなかったりする コードの書き方にばらつきがある 10

負債の宝石箱や〜 11

技術的負債とは 技術的負債（英語 : technical debt）、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間 がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の 手直しの暗黙のコストを反映したものである。 — wikiから抜粋 状態 負債の範囲 ● 動いているけどメンテできない (されてない) ● なぜ動いてるのか分からない ● 範囲は多岐に渡る ○ API ○ アーキテクチャ ○ コード ● 基本的にソフトウェアに対する改善・拡張の要求は継続する ○ 要求に応えられなくなった時から劣化、破損リスクが膨らむ 技術的負債 12

技術的負債とは 負債はどういう時に貯まるか ● ● 外部要因 ○ リソース不足 ○ 厳しい納期 ○ 要件の変更 内部要因 ○ 適切な設計不足 ○ ベストプラクティスの理解不足 ○ プロダクト理解不足 ■ ドキュメント不足 上記要因により、一時的なソリューションや迅速な実装の選択し、適切 な設計やコーディングの標準に則っていない負債が蓄積する 13

技術的負債とは 負債があるとどんな問題があるのか ● ● 新機能を速度を維持し安全に追加できない ○ 破壊的な変更を一気に導入したり、リスクがでかい ○ アドホックに変更をいれてしまう ■ さらに負債を増やしてしまう 誰もメンテができなくなる ○ どこのに問題があるか特定が複雑になる ○ 障害が発生した際にリカバリが困難 ■ 大体運用でカバーしてしまうが、後に同様な障害が発生しても解決し た要員がいない場合がある 14

技術的負債とは なんで直さないのか ● ● ● 安定しているから ○ いわゆる枯れている状態や機能追加がないもの ○ ただしこれは依存がメンテナンスされていたり、不具合が安全に修正できる 状態であること 何が起こるか分からないから ○ だれも知らない 木こりのジレンマ ○ リソースない 15

どこから手をつけるか？ 16

実際のケース 問題の再掲 ● ● ● ● ● ● ● ● CI(自動テスト)がない ○ そもそもテストができない(UTもない) Deploy(Build)が冗長的 ローカル実行ができない(デバッグできない) いまは使われていないnpmライブラリ サポート切れが近いランタイム環境 ○ それによって動かなくなるコード インテリセンスが効かないコード 実際は使ってないロジック ○ ファイル単位で使ってなかったりする コードの書き方にばらつきがある 17

実際のケース ※Lambdaの実行時間(15m)に収まらないため自分をループ実行している 18

実際のケース 注意事項 ● ● いきなりデカい変更をかけてはいけない ○ そもそも負債は普通の変更すらリスクなので、甘く見てはいけない ○ その変更は誰がGoの判断を下すのか ■ 管理者が全ての変更が妥当か見切れるのか ○ テストが大変になるのもこのパターン ○ デカい変更をかけれるタイミングもあるので見極める それが本当にプロダクトのためになっているのか判断する ○ 開発・運用の工数に見合ってるか ○ Howに囚われてはいけない 19

実際のケース 負債脱却の心得 1. 2. 3. 4. 技術的負債には、一度にすべてに取り組むのではなく、段階的に対処 影響の大きい領域に焦点を当て、反復的に改善 自動テストを採用して、回帰の問題を早期に発見し、安全なリファクタリングを行 チームと協力して、継続的な改善の文化を構築 20

実際のケース 今回のプロダクトの場合、インフラレベルの変更やビジネスロジックのリファクタリング はかけず 1. 2. 3. バージョン更新 ○ ランタイム環境のサポートが切れそうだったため CI/CD( & 開発環境) ○ テスト追加 ■ 不要コード整理 ■ インターフェースの追加 ○ パッケージ管理導入 ○ フォーマッター、リンター導入 ドキュメントの見直し の順で行っている 21

詳細 バージョンの更新 python及び各種ライブラリ 理由 ● 手法 本来はバージョンを 1つずつ上げるべ きだが、今回は Lamdbaのランタイム 環境に依存しているので、そこまで一 気に上げた。事前用意したテストケー スで問題が表出するか確認。 ● 古いバージョンを使うことはいつ爆発す るか分からない爆弾を持っているような もの ○ 少なくとも外部に露出している部 分は祈りに近い ○ だからといって新しいバージョン が安全という訳でもないが。。。 今後、改善を行う際の妨げになる可能 性がある 22

詳細 CI/CD 自動テストの導入 理由 ● 手法 テストは1から作成(つら)。手下ビリで ないロジックにガッツリ手を入れるとリ スクが跳ね上がるので、 ITレベルから になった。 また外部サービス (Slack通知など)は インターフェースを追加して隠蔽。 ● CIがないと変更による破損が検出でき ない ○ そもそも用意されてないと誰もテ ストを書かない デプロイの仕組みが複雑 (手作業がある など)だと、デプロイの度に手順の正当 性を確認しなければならない ○ デプロイが億劫になるので、何度 も確認したくない 23

詳細 ドキュメント見直し DesignDocの導入 理由 ● 手法 元々のドキュメントが無いに等しかっ たので、GoogleのDesignDocから拝 借し作成。文化構築にもなるので、 フォーマットを決めてしまう。 ● コードやシステムのドキュメンテーション が不十分だと、新しい開発者がプロジェ クトに参加する際に理解が難しくなる ○ そして技術負債へ。。。 個人的にはドキュメントを書かないのは エンジニアのよくない文化だと思う ○ とはいえ文書は生モノなのでケー スバイケースではある 24

結果 ● ● ● ある程度、安全にデプロイすることができるようになった ○ カバレッジとしては 90% ○ Googleでは、60% が「許容できる」、 75% が「賞賛に値する」、 90% が「模範的」 であるというガイドラインらしい ■ 頑張って100%にしても品質が担保されるわけではない フォーマッターやリンターによりコードのバラツキを最小限にできた ○ これらは既存影響が軽微なので、安心して導入できる 新しくジョインした人がスムーズにプロダクト理解できるようになった 25

• https://testing.googleblog.com/2020/08/code-coverage-best-practices.html

感想 ● ● ● 着手が遅くてもやらないよりやった方がいい リリースされている 全てのプロダクトに対して 判断する必要があると感じた ○ 今回はかなり裁量を与えられていたのでスムーズにできたが、ない場合はもっ と段階を踏んだほうがいい 技術的負債を毛嫌いせず、どのように解消するかを考えると自身の成長につながる 最初のコードを出荷することは、借金をするようなものだ。少々の借金は、書き換えによって速やかに返済される限り、 開発を加速させる。危険なのは、その負債が返済されないときだ。正しいとは言えないコードのために費やされた 1分 1秒が、その負債の利息としてカウントされるのである。オブジェクト指向であろうと なかろうと、統合されていない実装 の負債の負荷によって、エンジニアリング組織全体が停止してしまう可能性があるのだ。 - 1992年、ワード・カニンガム 26

Appendix 導入した技術 CI ● ● ● ● プラットフォーム: CircleCI ビルドツール: serverless + python-requirements ライブラリ: pytest + moto カバレッジレポート: pytest-cov 27

Appendix 導入した技術 開発環境 ● ● ● パッケージ管理: poetry フォーマッター: black + isort リンター: flake8 + black + isort 28

ご静聴ありがとうございました 29