モバイルアプリの技術的負債 みんなで学ぶ Lunch LT から学んだこと
モバイルアプリのオンライン勉強会に参加しました。この勉強会は日中開催で参加しやすかったです。そこから学んだことを整理するための記録です。
5つのモバイルアプリの事例から話がありました。最初のアプリの話は聞けなかったので載せれていません。真似してみたいと思った項目のまとめです。
まとめ
強制する仕組みを用意する
チームを分割してリファクタリングに集中できるようにする
コード自体は債務であることを意識する
リファクタリングに難易度ポイントを設定する
各項目の詳細をアプリごとに整理します。
NewsPicks
強制する仕組みを用意することを軸に次のような取り組みをしており、取り入れたいと思いました。
レイヤーを分けて依存の方向を強制する
古いコードをどうしても使いたい時は Adapter パターンを利用する
テストを強制する
レイヤーを分けて依存の方向を強制する
モジュールを分割して古いコードを直接参照できないように強制する。
古いコードをどうしても使いたい時は Adapter パターンを利用する
新しいアーキテクチャから古いコードを利用するときに新しいアーキテクチャに合わせたインタフェースを用意し、古いコードをそのインタフェースに準拠させる。これにより、古いコードのロジックだけ利用して、インタフェースを整理することができる。
テストを強制する
Danger を利用してテストなしでは PR をマージできないようにしてしまう。
Chatwork
認知負荷を軽減するためにチーム分割をスライドのような構成に変更。チームトポロジーにおける、システムの構成はチームの構成に依存するのを活用し、目指すシステムの形に合わせて、チームを編成したところが面白いと感じた。
ユーザに対する価値提供をプラットフォームチームが意識せずにストリームアラインドチームに対して有効な改善を続けることができるか疑問がある。このあたりはチームトポロジーの本を読んだら詳しく理解できるかもしれないので読もうと思った。
スタディサプリ
今のトレンドを取り入れることも新たな負債を取り込むことになる
書籍「Google のソフトウェアエンジニアリング」で「コード自体は債務である」と強調されていたことを改めて実感する
楽天ラクマ
リファクタリングに難易度ポイントを設定し、ポイント消化率を計測できるようにしている。機能開発におけるストーリーポイントのようなものを振り分けておくのは、今のチームでリファクタリングがどれくらいの速度で進むのか計測もできるようになり、見込みやリファクタリングの方針の指標にもなる。
おわりに
技術的負債という言葉はなくしたい気持ちがある。コード自体は債務であると捉えると、全ては技術的負債となってしまうし、事実そうだ。リファクタリングポイントとして、すべてのコードに対して重みを計上するのが正確で、それが一定の閾値を超えたら、あるいは増加傾向にあるなら、リファクタリングをする。技術的負債とワンワードで塊として捉えるのではなく、問題を区切って数値として測れるようにしたいと思いました。
この勉強会の雰囲気は Togetter にもまとめられています。
この記事が気に入ったらサポートをしてみませんか？