今年もDevelopers Summit 2020に参加してきたので参加したセッションのメモを備忘録的に残しておこうと思います。 event.shoeisha.jp
講演資料など全体的な情報はここでまとめてくれています。 codezine.jp
セッション情報
テストといえばの@t_wadaさんのセッション
セッション資料はこちら
荒ぶる四天王があらわれた
与えられた時間に対してやるべきことが多い場合、 大体の場合、品質を犠牲にする
短期的には効果があるかもしれないが、中期的には逆効果、長期的には致命傷になる
そもそもここでいう「品質」とは
- 品質とは誰かにとっての価値である
狩野モデル
- 当たり前品質
- 一元的品質
- 魅力品質
見える品質と見えない品質
- 犠牲になる品質はおおむね内部品質である
どのような「内部品質」を犠牲にささげたのか
特に保守性を犠牲にしている
- テスト容易性、理解容易性、変更容易性の3つに分けられる
「あとでクリーンにすればいいよ。先に市場に出さなければ」はあとでクリーンになることはない→市場からのプレッシャーが半端ないから→そして崩壊が始まる
動くコードを触るなという荒んだコードになる
爆弾処理のようなリリース
保守性の低さはひとつひとつの変更に余計な時間がかかる癌となっていく
ではスピードを落とせば保守性が上がるのか
くそコードを書く人は十分時間があってもくそコードを書いてくる
技術力のない人が時間をかけてコードを書いても技術力以上のものはできない
つまり保守性とスピードはトレードオフでない
品質アップはコストアップかダウンか
- コストと品質を天秤にかける
- 品質アップ=コストアップ説とコストダウン説がどちらか議論されている
品質を向上することで手戻りをなくすことができる=「実質無料」
品質は制御変数ではない
- 品質によってプロジェクトのスピードは変わらない
- 長期的にも、短期てきにも事実は崩壊したコードを書くほうがクリーンなコードを書くほうが常に遅い
コードの品質を犠牲にしたからでなく、コードの品質を高く保っていたからこと早い
- 品質劣化はリードタイムの増価につながる
- リードタイムが長いと仮説検証プロセスが回らない
最近の品質指標
- リードタイム
- デプロイ頻度
- MTTR(平均修復時間)
- 変更失敗率
質とスピートはトレードオフ的なものではなく、片方を犠牲にすると知らぬうちにもう一つも犠牲にしている
どうやって個人の質をあげるのか
- 判断力を身に着けるためには、自分で設計したシステムを長い間メンテナンスすることである。
内部品質への投資の損益分岐点はいつ来るか
テスト自動化の損益分岐点は4回
- およそ4回で主導テストと自動かされたテストのコストが逆転する
A Philosopy of software desigｎ
内部品質への投資の損益分岐点は一か月以内に現れれる。
荒ぶる四天王があらわれた
短期的には効果があるかもしれないが、中期的には一か月後には逆転される、長期的には致命傷になる
答えはスコープを削るorリリース日を延期する
ではスピードと質は何とトレードオフなのか
スピード⇔教育、学習、調査の時間
