Tweet
Tweet

Slide 1

Slide 1 text

Is
 High Quality Software Worth the Cost? ブログ記事読みました！ファンです！！LT(社内)

Slide 2

Slide 2 text

https://twitter.com/t_wada/status/ 1155691342560808965

Slide 3

Slide 3 text

Martin Fowler⽒のエントリーを読んだ話をします https://martinfowler.com/articles/is-quality-worth-cost.html

Slide 4

Slide 4 text

この話の議論と結論 • 議論: • 「質の⾼いコード」を書こうとすると、コスト掛かるよね • 実際の現場では時間が⾜りないよ！ • 結論: • 「よくないコード」は、ソフトの成⻑に従い⽣産性の低下を招く • 「よいコード」は、⽣産性を寧ろ向上させる • 優れたチームはコードの品質を気にしているよ！

Slide 5

Slide 5 text

こんにちは！

Slide 6

Slide 6 text

皆さん！ クオリティを⼈質にとっていますか？ http://shirobako-anime.com/story/21.html

Slide 7

Slide 7 text

お話の前に・・ • 今回「クオリティ」といったら、
 「コードの品質」のことだと思ってください • External Quality: UIとか安定性とか • Internal Quality: アーキテクチャ、設計 ➡ External Qualityは顧客から⾒える部分、
 Internal Qualityは開発者しか⾒えない部分 ͬͪ͜Ͷʂ

Slide 8

Slide 8 text

レベッカと私(例えば) • レベッカと私は、似たようなアプリを作ってい ます • UI的にも提供体験的にも、今は似たようなレベ ルです • レベッカは$10！わたしのは$6 Ͳ͕ͬͪ
 ΄͍͠Ͱ͔͢ʁ

Slide 9

Slide 9 text

レベッカと私(例えば) • もう1点、実は違いがあります！ • レベッカのアプリは、アーキテクチャもしっ かりしていて読みやすいです！ • 私のアプリは・・・まぁ動くんでぇ〜 Ͳ͕ͬͪ
 ΄͍͠Ͱ͔͢ʁ

Slide 10

Slide 10 text

レベッカと私(例えば) • UI、提供体験: External Quality • ソースコードのレベル: Internal Quality • Internal Qualityに価値を感じ、⽀払う⼈はいない ➡ それが
 Is High Quality Software Worth the Cost?
 という議論をもたらす

Slide 11

Slide 11 text

なぜ
 開発者は「クオリティ」を
 考えるべきなのか

Slide 12

Slide 12 text

ソフトウェア開発って • 「ソース」に継ぎ⾜し継ぎ⾜し、やっていく ものですよね • よく「建築」とかに例えられるけど、
 その点において決定的に違いますわな

Slide 13

Slide 13 text

例えば「新規」機能の追加 • まず既存コードやドキュメントを読むでしょ • その上で「⾃分が追加する機能」を
 どう差し込むか？を考えるでしょ • 実際に「そのために適したI/F」とか「データ構 造」を考えるでしょ • さぁ〜て書くかー！

Slide 14

Slide 14 text

ソフトウェア開発
 ≒「読み解く」作業が⼤半

Slide 15

Slide 15 text

例えば「新規」機能の追加 • まず既存コードやドキュメントを読むでしょ • その上で「⾃分が追加する機能」を
 どう差し込むか？を考えるでしょ • 実際に「そのために適したI/F」とか「データ構 造」を考えるでしょ • さぁ〜て書くかー！ ͜ΕΒ͕શͯɺ ʮطଘίʔυʯͷ
 ӨڹԼʹ͋Δ࡞ۀ

Slide 16

Slide 16 text

読まにゃらなんのですが・・ • もつれにもつれたロジック、フロー • 意味不明な変数名 • 巨⼤で関係ないデータ、取り出しにくい構造 • 分割されていないモジュール

Slide 17

Slide 17 text

クオリティが低いと • 該当コードを探し出すのに時間がかかり・・・ • その内部処理を読み解くのに時間がかかり・・・ • 既存コードに影響を与えない修正に時間がかかり・・・ • (それでもバグを出しやすくて)・・・ • もしエンバグしたら、「追加作業」で時間がかかり・・・ • デバッグしてコードを理解するのには時間がかかり・・・ • 原因究明後に「正しい修正」をするのに時間がかかり・・・

Slide 18

Slide 18 text

クオリティが低いと • 該当コードを探し出すのに時間がかかり・・・ • その内部処理を読み解くのに時間がかかり・・・ • 既存コードに影響を与えない修正に時間がかかり・・・ • (それでもバグを出しやすくて)・・・ • もしエンバグしたら、「追加作業」で時間がかかり・・・ • デバッグしてコードを理解するのには時間がかかり・・・ • 原因究明後に「正しい修正」をするのに時間がかかり・・・ ᶃ
 ࣮૷Ͱ࣌ؒ͘͏͠ ᶄ
 ͔͚࣌ؒͯ΋
 ʮବ໨ʯ͕ͪͩ͠ ᶅ
 ᶃͰ͔͔ͬͨ࣌ؒBHBJO

Slide 19

Slide 19 text

クオリティが低い事で負のサイクルに。
 その負は、更に次の負を呼び込み、
 どんどん加速していく・・・・

Slide 20

Slide 20 text

その後のレベッカと私(例えば) • レベッカは継続的に新機能を提供していきました • 私は・・・
 ちょっとした機能修正ですら迂闊に⼿を出せない 状況に。 • ユーザーがどちらを選択するかは⾃明。
 レベッカは更に競争⼒を増し(もっと価格上げても ⼤丈夫かも！)、私は撤退を余儀なく・・・

Slide 21

Slide 21 text

開発スピードと
 クオリティへの(投資)の関係

Slide 22

Slide 22 text

࣮૷͞Εͨྦྷܭػೳ਺ 1+ͷ׆ಈظؒ 「コードが成⻑していったときに、いじるのが どのくらい⼤変か？」を⽰した概念図

Slide 23

Slide 23 text

࣮૷͞Εͨྦྷܭػೳ਺ 1+ͷ׆ಈظؒ 最初は「低クオリティ」がスピードに乗ってい るようにみえる

Slide 24

Slide 24 text

࣮૷͞Εͨྦྷܭػೳ਺ 1+ͷ׆ಈظؒ 中⻑期的には、低クオリティのPJは成⻑が鈍化し ている。⼀⽅で⾼クオリティのPJは⽣産性が失わ れない

Slide 25

Slide 25 text

࣮૷͞Εͨྦྷܭػೳ਺ 1+ͷ׆ಈظؒ 「クオリティを捨てて得られるリード」が⽣じて いるのは、本当に⼀瞬・・・”意外と”すぐ追いつ かれる。

Slide 26

Slide 26 text

低クオリティvs⾼クオリティ • 低クオリティのコードは、未来のメンバーの 「やらなければいけないことを増やす」。 • 読む苦労、エンバグするリスク • ⾼クオリティのコードは、未来のメンバーの 「やりたいことを⼿助けする」。 • 先⾏したコードを活⽤できる！ ෆຯ͍ɺߴ͍ɺ஗͍ ඒຯ͍ɺ͍҆ɺૣ͍

Slide 27

Slide 27 text

よいチーム、悪いチーム

Slide 28

Slide 28 text

どんなチームでも • 「品質に気を遣っていこうな！」は⼤事 • が、優秀なチームが気をつけていたとしても
 「嫌なコード(cruft)」は⽣まれちゃう • そこで放ったらかしにしないのが良いチーム！ • それが「成⻑速度を維持する」のにつながる

Slide 29

Slide 29 text

キッチンの⽐喩 • キッチンが汚れてるまま、料理ってできる？ • 気持ちよくないよね・・ • それでも放ったらかしていると・・ • 汚れが乾いてこびり付き、掃除⼤変！ • 次の料理も引き続き嫌な気分！！

Slide 30

Slide 30 text

まとめ

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

めっちゃ便利だった・・ https://qiita.com/wtetsu/items/c43232c6c44918e977c9