Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発者が考える品質 / Quality considered by developers
Search
ma310kano
September 13, 2019
Programming
0
260
開発者が考える品質 / Quality considered by developers
ma310kano
September 13, 2019
Tweet
Share
More Decks by ma310kano
See All by ma310kano
オブジェクト指向とDependencyInjection / Object Oriented and Dependency Injection
ma310kano
0
320
Other Decks in Programming
See All in Programming
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
820
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
570
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
1
18k
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
490
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
760
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
730
5つのアンチパターンから学ぶLT設計
narihara
1
170
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
550
Goで作る、開発・CI環境
sin392
0
230
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Facilitating Awesome Meetings
lara
54
6.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Code Reviewing Like a Champion
maltzj
524
40k
Automating Front-end Workflow
addyosmani
1370
200k
Six Lessons from altMBA
skipperchong
28
3.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Transcript
開発者が考える品質 加納 誠人
アジェンダ • 品質とは • 品質を上げる「◦◦◦◦◦」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
品質とは?
ソフトウェア 品質 サービス 品質 情シスが目指すべき品質は、2種類ある サービス品質は、ITサービスマネジメントの領域なので、今回は割愛 そもそも品質とは?
Delivery (納期) Cost (コスト) QCDとは? Quality (品質) Quality を維持するには?
単体テストを書きましょう
単体テスト 最大のメリットは、過去のテストを再利用できること • 過去の品質を維持することができる • デグレーションの防止
テストでは何をすべき? 正しさを証明する。裏を返すと… → 何が正しいかを定義しなければならない 1. 機械的な正しさ(例:無限ループをしない・想定外の値が入らない) 2. 機能要件を達成する 3. 非機能要件をなるべく達成する(達成し続けるには、データ量増大やアクセス過多など、保守する必要がある)
製造 プログラム設計 機能設計 要件定義 単体テスト 結合テスト 総合テスト ユーザテスト V字モデル
V字モデル 製造 プログラム設計 機能設計 要件定義 単体テスト 結合テスト 総合テスト ユーザテスト 設定された値や判定が正しいか
プログラム同士が正しく接合するか 機能が正しく使えるか 要件が正しく達成されているか
「正しさ」をどのように見つけるか? 見つけるのはなかなか難しい • 他人に伝えるには、言葉にする必要がある • ドキュメントに残すには、文章や図にする必要がある よく使っている方法を1つ紹介する
マインドマップ マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用)
マインドマップの例 (非公開)
マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用) マインドマップ 「放射思考」が一番のポイント 放射上に思考を展開することで、思考が狭まりにくい • 1つの項目を一度に深く掘り下げない • 中央から目線を回して順に掘り下げていく
• マップを作ることは手段でしかないので、フォーマットにこだわらない
アジェンダに戻ります
アジェンダ • 品質とは • 品質を上げる「◦◦◦◦◦」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
「単体テスト」ケーススタディ
ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの? 3. TDDをはじめる第一歩
ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの? 3. TDDをはじめる第一歩
ムダな判定を混入させない ループに If 文を含めると組み合わせが大量に発生する 5回のループの場合… 32通り 2 × 2 ×
2 × 2 × 2 =
本当に繰り返す必要があるのか? よくあるケースは、 • 最初だけ処理をスキップする • 最後のみ追加で処理をしたい そんな時は…
ループを分割しよう
ループを分割する LINQ を活用してループを分割する • 最初と2回目以降の場合… First と Skip • 最後のみの場合…
Take と Last Take と Skip を要素がなくなるまで繰り返すことで N件ごとのページングも可能
ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの? 3. TDDをはじめる第一歩
それ、本当に無限なの? 限度がない機能要件や非機能要件は存在するのか? • 1レシートに100万の商品記載がありますか? • メモリが無限のPCが存在しますか? → 存在しない 可能な限り、限度を決める
ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの? 3. TDDをはじめる第一歩
TDDをはじめる第一歩 テスト駆動開発 (TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最 初にテストを書き(これをテストファーストと言う)、そのテストが動作する必要最低限な実装をと りあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。 (Wikipedia より引用) 実際にやってみた結果…
最初にテストが書けない
コードを書く → 正しく作られているか証明する から 正しく作られているか証明する → コードを書く なぜ書けないか? 思考の逆転が必要
アジェンダ • 品質とは • 品質を上げる「単体テスト」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
設計・製造ケーススタディ
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
YAGNIとは? "You ain't gonna need it"、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよい とする、エクストリーム・プログラミングにおける原則である。(Wikipediaより引用) どうしてもコードに書かなければならない場合は…
タスク一覧を活用しよう VisualStudio では、コメントの先頭に下記を付けるとタスク一覧ウィンドウで一覧化してくれる • UNDONE: まだやっていない • TODO: やる必要がある •
HACK: 目的は達成しているが、より良い方法がある UNDONE が書きたくなった時は、単体テストを書く マージまでに TODO を極力減らす → マージする際はその内容が妥当か検討する
チケットで管理しよう チケット駆動開発 (TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS(Bug Tracking System/バグ管理システム)のチケットに割り当てて管理を行う開発スタイル。細かな修 正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリー ム・プログラミングをはじめとするアジャイル開発でも実践されている。(Wikipediaより引用) チケット =
Backlog の課題
ガントチャートの例 (非公開)
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
責務を分ける クラスの責務を分けていれば、 証明する正しさがシンプルになる 「このクラスは◦◦ができていれば、テストOK」と 言葉に変換しやすくなる
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
不変による防止 中身をいつでも変えられるクラスは、 変えたときを想定したテストケースを作成する必要がある 中身が変わらない(=不変)のオブジェクトは、 組み合わせが少なくなる為、テストケースが少なくなる
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
判定のしきい値 判定のしきい値(境界値)を決定する際には、細心の注意を払う 特に次の言葉が出てきたら、注意すること • 以上・以下 • 上回った場合・下回った場合 途中式をローカル変数に代入して、わかりやすくしておくのも手
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
初期値に気を払う 変数に何も設定しない場合、 値型には型に応じた初期値が、参照型には Nothing (null) が設定される。 特に注意が必要な型は、 DateTime 型。 何も設定しない場合、西暦1年1月1日が設定される。
• DateTime? のように Null許容型にする • 引数チェックで DateTime.MinValue と比較する
ケース紹介 1. YAGNIとは? 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5.
初期値に気を払う 6. 符号なし整数
符号なし整数は使わない UInteger 型などの 符号なし整数型 は使用しないこと 20億を越える値を扱う頻度 < 負の値を扱う頻度 UInteger 型で
0 - 1 をすると、4,294,967,295 になる(アンダーフロー) 0付近を想定している処理に、 40億の値が投入したら、どうなりますか?
まとめ
品質ってなんですか?
• 目的によって、求められる品質は異なる • コストや納期とは切り離せない • 何が正しいかを考え、先に証明するテストを書く • 今、必要でないものは追加しない • 設計思想や開発者の意識で底上げすることが可能
ご清聴ありがとうございました