開発者が考える品質 / Quality considered by developers

Transcript

1. 開発者が考える品質 加納 誠人
2. アジェンダ • 品質とは • 品質を上げる「◦◦◦◦◦」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
3. 品質とは？
4. ソフトウェア 品質 サービス 品質 情シスが目指すべき品質は、2種類ある サービス品質は、ITサービスマネジメントの領域なので、今回は割愛 そもそも品質とは？
5. Delivery (納期) Cost （コスト) QCDとは？ Quality （品質） Quality を維持するには？
6. 単体テストを書きましょう
7. 単体テスト 最大のメリットは、過去のテストを再利用できること • 過去の品質を維持することができる • デグレーションの防止
8. テストでは何をすべき？ 正しさを証明する。裏を返すと… → 何が正しいかを定義しなければならない 1. 機械的な正しさ（例：無限ループをしない・想定外の値が入らない） 2. 機能要件を達成する 3. 非機能要件をなるべく達成する（達成し続けるには、データ量増大やアクセス過多など、保守する必要がある）
9. 製造 プログラム設計 機能設計 要件定義 単体テスト 結合テスト 総合テスト ユーザテスト V字モデル
10. V字モデル 製造 プログラム設計 機能設計 要件定義 単体テスト 結合テスト 総合テスト ユーザテスト 設定された値や判定が正しいか プログラム同士が正しく接合するか 機能が正しく使えるか 要件が正しく達成されているか
11. 「正しさ」をどのように見つけるか？ 見つけるのはなかなか難しい • 他人に伝えるには、言葉にする必要がある • ドキュメントに残すには、文章や図にする必要がある よく使っている方法を1つ紹介する
12. マインドマップ マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用)
13. マインドマップの例 (非公開)
14. マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用) マインドマップ 「放射思考」が一番のポイント 放射上に思考を展開することで、思考が狭まりにくい • 1つの項目を一度に深く掘り下げない • 中央から目線を回して順に掘り下げていく • マップを作ることは手段でしかないので、フォーマットにこだわらない
15. アジェンダに戻ります
16. アジェンダ • 品質とは • 品質を上げる「◦◦◦◦◦」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
17. 「単体テスト」ケーススタディ
18. ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの？ 3. TDDをはじめる第一歩
19. ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの？ 3. TDDをはじめる第一歩
20. ムダな判定を混入させない ループに If 文を含めると組み合わせが大量に発生する 5回のループの場合… 32通り 2 × 2 × 2 × 2 × 2 ＝
21. 本当に繰り返す必要があるのか？ よくあるケースは、 • 最初だけ処理をスキップする • 最後のみ追加で処理をしたい そんな時は…
22. ループを分割しよう
23. ループを分割する LINQ を活用してループを分割する • 最初と2回目以降の場合… First と Skip • 最後のみの場合… Take と Last Take と Skip を要素がなくなるまで繰り返すことで N件ごとのページングも可能
24. ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの？ 3. TDDをはじめる第一歩
25. それ、本当に無限なの？ 限度がない機能要件や非機能要件は存在するのか？ • 1レシートに100万の商品記載がありますか？ • メモリが無限のPCが存在しますか？ → 存在しない 　 可能な限り、限度を決める
26. ケース紹介 1. ムダな判定を混入させない 2. それ、本当に無限なの？ 3. TDDをはじめる第一歩
27. TDDをはじめる第一歩 テスト駆動開発 (TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最 初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をと りあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。 (Wikipedia より引用) 実際にやってみた結果…
28. 最初にテストが書けない
29. コードを書く → 正しく作られているか証明する から 正しく作られているか証明する → コードを書く なぜ書けないか？ 思考の逆転が必要
30. アジェンダ • 品質とは • 品質を上げる「単体テスト」ケーススタディ • 品質を上げる「◦◦・◦◦」ケーススタディ
31. 設計・製造ケーススタディ
32. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
33. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
34. YAGNIとは？ "You ain't gonna need it"、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよい とする、エクストリーム・プログラミングにおける原則である。(Wikipediaより引用) どうしてもコードに書かなければならない場合は…
35. タスク一覧を活用しよう VisualStudio では、コメントの先頭に下記を付けるとタスク一覧ウィンドウで一覧化してくれる • UNDONE: まだやっていない • TODO: やる必要がある • HACK: 目的は達成しているが、より良い方法がある UNDONE が書きたくなった時は、単体テストを書く マージまでに TODO を極力減らす → マージする際はその内容が妥当か検討する
36. チケットで管理しよう チケット駆動開発 (TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル。細かな修 正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリー ム・プログラミングをはじめとするアジャイル開発でも実践されている。(Wikipediaより引用) チケット ＝ Backlog の課題
37. ガントチャートの例 (非公開)
38. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
39. 責務を分ける クラスの責務を分けていれば、 証明する正しさがシンプルになる 「このクラスは◦◦ができていれば、テストOK」と 言葉に変換しやすくなる
40. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
41. 不変による防止 中身をいつでも変えられるクラスは、 変えたときを想定したテストケースを作成する必要がある 中身が変わらない(＝不変)のオブジェクトは、 組み合わせが少なくなる為、テストケースが少なくなる
42. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
43. 判定のしきい値 判定のしきい値(境界値)を決定する際には、細心の注意を払う 特に次の言葉が出てきたら、注意すること • 以上・以下 • 上回った場合・下回った場合 途中式をローカル変数に代入して、わかりやすくしておくのも手
44. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
45. 初期値に気を払う 変数に何も設定しない場合、 値型には型に応じた初期値が、参照型には Nothing (null) が設定される。 特に注意が必要な型は、 DateTime 型。 何も設定しない場合、西暦1年1月1日が設定される。 • DateTime? のように Null許容型にする • 引数チェックで DateTime.MinValue と比較する
46. ケース紹介 1. YAGNIとは？ 2. 責務を分ける 3. 不変による防止 4. 判定のしきい値 5. 初期値に気を払う 6. 符号なし整数
47. 符号なし整数は使わない UInteger 型などの 符号なし整数型 は使用しないこと 20億を越える値を扱う頻度 ＜ 負の値を扱う頻度 UInteger 型で 0 - 1 をすると、4,294,967,295 になる(アンダーフロー) 0付近を想定している処理に、 40億の値が投入したら、どうなりますか？
48. まとめ
49. 品質ってなんですか？
50. • 目的によって、求められる品質は異なる • コストや納期とは切り離せない • 何が正しいかを考え、先に証明するテストを書く • 今、必要でないものは追加しない • 設計思想や開発者の意識で底上げすることが可能
51. ご清聴ありがとうございました