デブサミ2020「レガシーコードからの脱却」講演メモ #devsumi

登壇者

  • 吉羽 龍太郎 氏
  • アトラクタ
    • 取締役CTO

レガシーコードからの脱却

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者:David Scott Bernstein
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)

  • ITエンジニア本大賞2020(技術書部門)で受賞!
  • 「レガシーコード」というワードをタイトルにつけると書籍は売れるらしいw

レガシーコードとは

  • レガシーコードとは?
    • 綺麗なコードは有用だが、テストがなければレガシーだ
    • 保守または拡張が困難なコード
    • 定義は様々
      • 議論の時はまず共通認識をとるのが大事
    • 理由は問わず、修正・拡張が難しいコード
  • 使われるソフトウェアには変更が必要になる
    • ほぼ80%の開発コストを障害の特定や修正のために使われている
    • 原因は急ぎすぎている、たくさん作ろうとしている、読みやすさより描きやすさを優先している
      • つまり品質を犠牲にしている
      • 品質は検査ではよくならない、最後にテストしても仕方ない
  • やるべきことは問題を作り込まないこと、つまりレガシーコードを作らない
  • ではどうしたらいいか -> 開発プロセスに着目する
  • ソフトウェアを生み出す成果を決める要素
    • 問題設定力
    • 開発力
    • チーム力(組織力)
  • コードだけ綺麗に書いたり、開発プロセスだけちゃんとやっていればよいわけではない
  • レガシーコードを最初から作らないようにするには、具体的にはどうすれば?
  • レガシーコードを作らない9つのプラクティス
    • やり方より先に目的・理由・誰のためかを伝える
    • 小さなバッチ(単位)で作る
    • 継続的に統合する
    • お互い協力し合う
    • CLEANコードを作る
    • まずテストを書く
    • テストでふるまいを例示する
    • 設計は最後に行う
    • レガシーコードをリファクタリングする

ScrumとXPからプラクティスが抽出されている。

やり方より先に目的・理由・誰のためかを伝える

  • 役割の違い
    • プロダクトオーナーの責任
    • 開発チームの責任
  • WhatとHowを分断する
    • 何を欲しいか、なぜ欲しいか(What)は顧客やPOの領域
    • やり方(How)は開発チームの役割
      • 物事のやり方は1つではなく、やり方ごとにトレードオフがある
      • やり方を命じされると代替案が出せなくなる
      • 結果として手続き的なコードになりがち(結果的にオブジェクト指向にならない)
    • 双方が創造的に協調することで無駄が減る
    • 作る上で重要なのはコンテキストを共有すること
  • ユーザーストーリー
    • 何が・何のために・誰のために存在するかを1文で示したもの
    • 機能について会話できるくらいの辛うじて十分なドキュメント(仕様書じゃない
    • 知識はドキィメントではなく、コード(テストも含)にまとめるべき
    • ストーリーが限定的でテスト可能になる(受け入れ基準と自動化)
    • シンプルにまとめて追加はあとで行う
      • ちょっとずつ進めることで良い設計が浮かび上がってくる

小さなバッチで作る

  • 鉄の三角形(Quality, Cost, Deliverly, Scope)
    • 同時に守れるのは2つまでと言われる
    • Qは落とすべきではない
  • QCDSの何を調整するか
    • Q(品質)を下げると、あとで何倍もの時間を使うことがある
    • C(コスト)を調整するとは、すなわち人を増やすことにつながる
      • ただし人を増やしても、オーバーヘッドがあるのでリニアにスケールしない
    • D(時間)を調整してもよいが、多くのビジネスは時間が重要
    • つまり一番調整すべきなのは「スコープ」
      • およそ半分の機能はほとんど使われていない
      • スコープを調整して価値(大事)のあるものが順に進める
  • タイムボックスによるアプローチ
    • 固定の期間の中でタスクに取り組む
      • ex.) 1 week
    • タスクの分割になれるまでは機能しやすい
    • ScrumやXPのやり方
  • 長い期間で大きなウソをつくのではなく、短いイテレーションで小さなウソをつく
  • 同じリズムを刻むことで負担を少なくして、異常に気づく
    • 日々の仕事も同じ
  • リソース効率とプロセス効率
    • 1サイクルのリズムが長くなると、リソース効率化を目指しやすい
      • 並行タスク・役割分担・フェーズが増える
    • 1サイクルのリズムを短くすると、プロセス効率が上がる
      • モブプロ=究極の1個流し
      • いくら人を働かせても、完成しているものが0なら、ビジネス価値はない
      • 難しそうなバックログはモブで、など結構モブを使っている現場は増えている
  • ソフトウェアの評価
    • ソフトウェアの評価は顧客にとっての価値
      • 価値は完成してはじめて価値になる
      • 部分最適化を避ける
    • 効率より効果を重視
  • フィードバックサイクル
    • 小さなバッチの方がフィードバックの回数は増える
      • スプリントレビュー、レトロスペクティブ...
      • 顧客やPOと同席することでフィードバックの回数を増やす
      • そのためにビルドの高速化も大事
    • フィードバックへの対応をサポートする文化が必要
      • 価値やリスクに応じて取捨選択する

フィードバックによって価値を高めていく

CLEANコードを作る

  • 品質は検査では上がらない
  • よくないコードの特徴
    • 重複コード、長すぎるコード、巨大なクラス、長すぎるパラメーターリスト...
  • よくない例をあげるとキリがないので、模範になるパターンを覚える
  • CLEANコードとは?
    • Cohesive (凝集性)
      • それぞれの部品は1つのことだけ扱い、1つに集中する
      • 理解もバグも見つけるのが簡単
    • Loosely Coupled (疎結合)
      • オブジェクト間の関係を明確な意図を持った状態に保つ
      • テストや再利用、拡張が簡単
    • Encapsulated (カプセル化)
      • 何をやっているかに名前をつけて、どう動くかは隠す
      • あとから変更するのが簡単
    • Assertive (断定的)
      • 好奇心旺盛を避ける
    • Non redundant (非冗長)
      • 同じことを繰り返さない(DRY原則)
      • バグ修正・変更は1箇所で1回だけすればよい
  • よいソフトウェアの土台となる5つのこと
  • これらを意識するとテストしやすくなる
  • CLEANとテストでバグ発見の時期をシフトレフトする
    • 設計の段階でバグを見つければ5分で修正できる
    • テストの段階だと修正に1日、、、本番リリース後だと数日、、、
    • そうならないようになるべく早期からテスト可能な状態にする
  • 明日のベロシティのために、今日品質を上げる
    • 速度は日々の積み重ねでしか早くならない
    • CLEANコードは理解しやすく取り組みやすい
    • 結果として総所有コストが下がる、逆の状態が技術的負債
  • すばやく働くということは「きれいに働く」ということ
  • これって"5S"だった
    • 整理、整頓、清掃、清潔、躾

レガシーコードからの脱却まとめ

  • 使われるソフトウェアは変更が必要になるので、コードは変更可能になるように書くべき
  • プロダクトオーナーは、目的、必要な理由、誰のためのものかが伝わるようにする
  • 要求は意味のある小さな単位にして重要なものから作る
  • 開発チームは小さなバッチで作っていく、作るときはPOと協力する
  • コードはTDDで書く、テストはふるまいを例示、テストも含めてCLEANを満たすように作る
  • できあがったものは1つずつ統合していき、常にデプロイ可能な状態にする
  • 1度作ったら終わりではなく、必要に応じて設計やコードを見直す、良い設計は創発する、子のときテストがあることが重要

今日伝えたかった最重要なこと

「他にも本には色々書いてあるので買ってね」

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者:David Scott Bernstein
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)

あわせて読みたい