- Ques_staff
- 1791
- 0
- 0
- 0
hagevvashiさんにバトンタッチ 過去のQuesでも「食べログソフトウェアテスト自動化デザインパターン」も発表して頂きました #ques
2022-09-29 19:18:34PRマージ数 1.28倍! 【Four key metrics】Deployment frequency エリートに分類! #ques
2022-09-29 19:20:42PRマージする = リリースというようなパイプライン組んでいるんだ。なるほどそれは Elite に属せそうな開発スタイルだ #ques
2022-09-29 19:22:14障害率 PRリバート率 減少! 【Four key metrics】Change failure rate エリートに属している! #ques
2022-09-29 19:22:32さらなる変化の機会のため、探索的な分析 リードタイム ハイの中を推移していて、エリートへの改善の可能性がある! 絶賛テスト自動化取り組み中 #ques
2022-09-29 19:24:36ん、テストからリリースまでのリードタイムが1日以上あるのに、なんでPRマージ数をリリース数とみなして Four keys と比較しているの? #ques
2022-09-29 19:25:46ご存知、食べログ 16年目のサービス、Railsになってから14年経過 ・密結合、低凝集→保守性が低い ・分散されたモノリス ・独立してそうで独立してないRailsアプリ群 #ques
2022-09-29 19:32:57お掃除が必要 散らかった部屋をいきなり分けられない いらないものを捨てて、ホコリとり 巨大なシステムなので全体を満遍なくお掃除するとメリットが得られる時期が遅くなる →優先順位を決める #ques
2022-09-29 19:36:02スコアリングするためのメトリクスを検討 ・ビジネス的重要性 ・案件の数→コードの更新回数 ・コードの見通し改善効果 ・難易度 ・実行されない=デッドコードの量 ・多いほど効果が大きい ・多いほど難易度が高い #ques
2022-09-29 19:38:30デッドコード量 Coverage で、production環境で実際に実行されたコードを計測して算出 oneshot_lines カバレッジモード #ques
2022-09-29 19:39:53サブシステム単位でメトリクスをプロット 更新回数とデッドコード行数には強い相関が見える 外れ値もあるので、擬似相関とも考えにくい ビジネス的重要性を最重視して選定 #ques
2022-09-29 19:42:41