品質が高いコードって何？Rev2.1

by ICKX

Slide 1

Slide 1 text

“品質”

Slide 2

Slide 2 text

• • • • スタッフエンジニア PHPエンジニア • PHP続けて20年 • 自転車アマチュア無線 • TYRELL IVE • ICOM • VERTICAL STRIKE ENDLESS CHALLENGE • HTTPS://QIITA.COM/WAKABADOU/ITEMS/84B48CA12F25FB2FB69C

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

宣伝 PHPERKAIGI2021 PHPでCSVを安心して扱うために FW3/STREAMS そのまま直接

Slide 5

Slide 5 text

メソッドで種類を指定し、ファイルパスとZIP内のパスを記述するだけでOK CSVの設定はふつう！！注意！！foreachを使用しないストリームのため巻き戻しができずここだけ定石から外れる

Slide 6

Slide 6 text

宣伝２ TRYNAMEFROM 昨日 PUTRAITS/ENUMS

Slide 7

Slide 7 text

必要なファイルと特性、インターフェースを設定するだけ簡単に名前から引けるようになります内部でキャッシュを持っているので、実行効率的にも安心です

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

「“品質”が高い」

Slide 10

Slide 10 text

Slide 11

Slide 11 text

それら “だけ”だったらば

Slide 12

Slide 12 text

「“品質”が高い」とは言えません

Slide 13

Slide 13 text

そもそも “品質” とは何でしょうか？

Slide 14

Slide 14 text

“品質” “対象”に“本来備わっている特性”の集まりが“要求事項”を満たす“程度” ISO 9000 (JIS Q 9000:2015)

Slide 15

Slide 15 text

ISO 25000で定義される “ソフトウェアの品質”では明示された条件下で使用するとき、明示的ニーズ又は暗黙のニーズを満たすためのソフトウェア製品の能力 ISO/IEC 25000:2014 (JIS X 25000:2017) 他にも色々あるので興味が出たら調べてみてね • 品質管理 ISO/IEC 25000 • 品質モデル ISO/IEC 25010 • 品質測定 ISO/IEC 25022 • 品質測定 ISO/IEC 25023 • 品質要求 ISO/IEC 25030 • 品質評価 ISO/IEC 25040

Slide 16

Slide 16 text

“品質” “先んじて定められた要求事項”に対して “どの程度、要求を満たしているか”が“品質”です。

Slide 17

Slide 17 text

“品質” “要求を満たしていること”

Slide 18

Slide 18 text

“品質” • 不具合発生件数が少ない・ゼロ • XUNITツールを整備・継続的に運用 • 開発フェーズを用意 • 自動でテストさせている • テストを実施している • プロセス・テストなどの技法を用意・実施している • 高機能・多機能である • 多くの人が使っている・好印象を持っているものを使用している • 新しい・最新の技術・概念を使用しているそもそも下二つはただの教条主義なんで論外なんですけどね ※教条主義：権威者が述べた事を、その精神を深くも理解せず、杓子定規に振りまわす態度。

Slide 19

Slide 19 text

“要求事項” “機能”

Slide 20

Slide 20 text

“多機能” “高機能” • “品質” 定義本来備わっている“特性”の集まりが要求事項を満たす程度」 • “特性” “特性” “備わっているものの働きが優れていること”

Slide 21

Slide 21 text

“高機能” “品質” • “QUALITY” • “高QUALITY” “低QUALITY” • 写真として低機能写真として高機能 • ここだけでの使い勝手の良し悪しは品質ではない • JPEGファイルフォーマット仕様を満たしているどちらの写真でもJPEGとして適当な品質を達成出来ています

Slide 22

Slide 22 text

“要求事項”

Slide 23

Slide 23 text

“要求事項” “ニーズ又は期待” “明示されている、通常暗黙のうちに了解されている” “義務として要求されている”

Slide 24

Slide 24 text

“要求事項” • 認識しうる、考えうるもの全て • 製品、人、資源、変換率、プロジェクト計画、将来の組織状態、サービス、プロセス、組織、システムなど、物質的なもの、非物質的なものの何れかも問いません。 • ISMS (JIS Q 27001) • ISMSの取得とは情報セキュリティマネジメントシステムとして定めたプロセスがISMSの求める要求事項を満たし、認証機関から認定を取得した事を示します。

Slide 25

Slide 25 text

“高品質”

Slide 26

Slide 26 text

“高品質” • “定められた要求事項”に対して“要求を満たしている”ことです。 • 超過でも未満でもなりません。 • めっぽう忘れられがちですが、未満だけでなく、超過もダメです。

Slide 27

Slide 27 text

“高品質”

Slide 28

Slide 28 text

例えば業務上のレイヤごとに要求を明確化しそれを達成する • 例えば、自社サービスなら次の5レイヤが手を出しやすいです • 企画要求 • 設計要求 • 製造要求 • サービス要求 • あたり前要求 • それぞれ、前レイヤが定める要求に依存して、自身の要求が定まります

Slide 29

Slide 29 text

5レイヤごとの例 • 企画要求：企画で実現しようとしている特性に対する顧客の要求 • 顧客が想像すらできない、未来にありえる顧客の要求。車や家の広告にある、ライフスタイルの提案などが参考になる。 • 設計要求：企画を実現するために必要な特性の組み合わせの要求 • 新たに必要となる特性の水準や品質に対する要求。 • 製造要求：実装に当たっての達成すべき水準や機能に対する要求 • サービス要求：使い出、設定、サポートなど利用に対する要求 • 当たり前要求：当たり前過ぎて通常、暗黙に了解されている要求 • セキュリティや実行効率、法令要求事項、規制要求事項など • 非機能要件として”見えない化”されがち

Slide 30

Slide 30 text

「あれ？そうなると我々が日ごろ目指している “高品質なコード”って…」

Slide 31

Slide 31 text

そのままでは高品質足りえません。 • 繰り返しになりますが“品質”はまず要求ありきです。 • 経営層から達成すべき要求が提示され、初めて高品質を指向することができます。 • ここは特に重要な点なのですがコードの質の追求は経営課題です。 • 不具合の少ないコード、変化に追従しやすいコード、セキュアなコード。いずれにしても経営層がそれを必要とし要求しない限りは、“品質”の話自体を始めることができません。

Slide 32

Slide 32 text

なるほど！「納期さえ間に合えば良い」が正なんだ…

Slide 33

Slide 33 text

そんな訳はない • 経営層の品質マネジメント自体の質の話になります。 • ISO9001で要求される“顧客重視”の観点が抜け落ちていることになるからです。 • 例えばセキュリティ。 • 顧客は安全にサービスを利用することを暗黙的に要求しているのだから、このご時世においてセキュリティをないがしろにしたリリースは顧客からの要求に応えていないことになる。 • なお、それらを全部判った上であえて対応しないという経営判断もありえます。 • 「人の噂も七十五日、3ヶ月で株価が元に戻るならどうでもよくね？？？」

Slide 34

Slide 34 text

とはいえ弊意思決定層…

Slide 35

Slide 35 text

とはいえ弊意思決定層…

Slide 36

Slide 36 text

“プロセス” “高品質”

Slide 37

Slide 37 text

品質プロセス

Slide 38

Slide 38 text

製品品質コード品質

Slide 39

Slide 39 text

追求すべき品質製品業務

Slide 40

Slide 40 text

品質

Slide 41

Slide 41 text

コード業務品質

Slide 42

Slide 42 text

“業務品質”としてのコード品質

Slide 43

Slide 43 text

コントロール出来る所からはじめよう

Slide 44

Slide 44 text

”識者たる私たち”が定めることの出来る要求 • • セキュアな状態 • セキュアな状態実現するために必要なこと

Slide 45

Slide 45 text

”識者たる私たち”が定めることの出来る要求 • • セキュアな状態 • セキュアな状態実現するために必要なこと • • • • • •

Slide 46

Slide 46 text

”識者たる私たち”が定めることの出来る要求はい、要求が1セットできあがりました。 • • • •

Slide 47

Slide 47 text

これってコードレビューで指摘するようなことなのでは？

Slide 48

Slide 48 text

そうだよ

Slide 49

Slide 49 text

ただし、次の点が変わります予め定められた要求に依り要求の下に統治する

Slide 50

Slide 50 text

ただのガイドラインを止め明確に「する」「してもよい」「してはならない」を要求し要求を満たしているかどうかでコードの品質を測ります

Slide 51

Slide 51 text

個別最適な個人技から定められたプロセスに則った業務遂行へ

Slide 52

Slide 52 text

そしてコードレビューを実施すること自体も業務プロセスとして要求します

Slide 53

Slide 53 text

そうやって要求するプロセスを定義、積み上げる事で業務品質を向上する事が出来ます

Slide 54

Slide 54 text

定義すべき対象指針

Slide 55

Slide 55 text

ISO/IEC 25010 (JIS X 25010) • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Slide 56

Slide 56 text

“高品質”

Slide 57

Slide 57 text

“高品質”を維持する作業の例 • “要求事項”を“治具”にし“公差に収まっているかどうか” で “品質の適合度合いを自動的に測る” • 治具って何 • Jig。加工や組み立ての際、部品や工具の作業位置を指示・誘導するために用いる器具の総称。 • 同一形状の製品ならば高度な熟練技術を用いずとも製品のバラツキを最小限に抑え、迅速に大量生産することを可能にする。 • 公差って何 • 機械工学に代表される工学において許容される差のこと。 • 「公差0.5mmなんで0.3mmくらいおっきくてもOKです！」 • 「公差0mm？現実的なコストで出来る訳ねェだろ！」 • （ランダム性がなけりゃWeb系だと0が当たり前になるんだよなぁ…）

Slide 58

Slide 58 text

“治具”として見るXUNIT • PHPUNITをはじめとしたXUNITツール群は “治具”として活用することができます。 • プログラマが受けた要求を元に仕様をテストケースとして起こし、要求する枠内に収まっていればOK => まさに“治具” • 冪等性もあるので、なんどでも簡単に実施可能 => まさに“治具” • この観点でXUNITを見れば、だいぶテストケースも設計しやすくなります。

Slide 59

Slide 59 text

XUNIT どこまでやるべき

Slide 60

Slide 60 text

徹底要求をテストコード

Slide 61

Slide 61 text

ごくふつうのテストコードでは？

Slide 62

Slide 62 text

あれ？そうなると境界値テストなどのテスト技法は…？

Slide 63

Slide 63 text

まず先に要求ありきです要求に対して適切な技法として境界値テストが選択されるという順番になります

Slide 64

Slide 64 text

品質が高いコードとは要求を満たしているコード

Slide 65

Slide 65 text

• ツールを使っている KPIを設定しているだけ言わない • 品質とは要求を満たしていること • • プロセス構築 • 品質はプロセスに宿る • • コードの品質の話業務品質として話をまとめよう

Slide 66

Slide 66 text

つまりどういうことだってばよ!?

Slide 67

Slide 67 text

抽象的すぎて判らんなんもわからん

Slide 68

Slide 68 text

ですよね

Slide 69

Slide 69 text

業務品質向上の結果コード品質が向上する

Slide 70

Slide 70 text

• • 特性 • 定数 • 静的プロパティ • プロパティ • 静的抽象メソッド • 抽象メソッド • 静的メソッド • コンストラクタ • メソッド • マジックメソッド • それぞれの要素内では可視性に基づき次の順に配列されていること • public • protected • private

Slide 71

Slide 71 text

• • コード解釈される時間、読まれる時間の方が長い • 読むタイミングで読みやすくするのではなくすでに読みやすくなっていること • • 上記要求要求 • クラスの特性を示す要素を先 • 安定している要素を先 • 少ない手間で呼び出される早いタイミングで呼び出される •

Slide 72

Slide 72 text

PHP-CS-FIXERを JIGとして使う要求を満たしているかどうか簡単に知る

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

要求をすべて満足しているこのコードの品質は高い

Slide 75

Slide 75 text

FIXも自動でやらせてしまえ常にだれでも要求を満足した品質の高いコード

Slide 76

Slide 76 text

Q:あれ？じゃあPSR-12に準拠しろってのは？ A:”正しく”要求だよ

Slide 77

Slide 77 text

先に紹介したライブラリ「」でも実施しているのでご興味がありましたら見てみてください src配下に3ファイルしかないので、だいぶ感覚をつかみやすいはずです

Slide 78

Slide 78 text

製品品質として見た現場向けの話は？

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

TACDDDは日付ユーティリティサービスとして DATETIMEUTILITYSERVICEを持ちます。今回はこのクラスが持つ CREATENEXTWORKINGDATEメソッドで解説します。

Slide 81

Slide 81 text

翌営業日を計算して返すメソッド CREATENEXTWORKINGDATE 用語算出基準とする年月日指定日日曜日休日として指定された場合の土曜日指定された祝日休日休日を除く日営業日指定日を基準として指定日を含む最も近い休日ではない日翌営業日翌営業日を算出するために、その時点で扱っている日対象日翌営業日が翌月の場合でも良しとすること月跨ぎ

Slide 82

Slide 82 text

翌営業日を計算して返すメソッド CREATENEXTWORKINGDATE • 要求事項 • 指定日を元に翌営業日を算出し返す事 • 入出力値は¥DateTimeImmutableとすること • 対象日が休日の場合、後ろ倒しして判定すること • 月跨ぎ不許可かつ月末休日の場合、前倒しすること • 次の三つの設定を1グループとして複数グループ扱えること • 土曜日を一律に休日・営業日として設定できること • リストとして与えた祝日を休日として設定できること • 月跨ぎの許可・不許可を設定できること

Slide 83

Slide 83 text

治具として使うXUNIT • 先の要求を満足できているかを繰り返し確認するために XUNITを使います。 • 今回のケースではPHPUnitを使います。 • まずは入力に対しての出力の要求を明示しましょう。

Slide 84

Slide 84 text

要求の明示 • この例では特に次の要求を満足していることの確認が期待できます • 対象日が休日の場合、後ろ倒しして判定すること • 月跨ぎ不許可かつ月末休日の場合、前倒しすること期待値の明示期待値の明示指定日指定日

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

期待値要求として意識的に明示的に

Slide 87

Slide 87 text

期待値要求

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

第三者検証がないものテストですらない自分書いて実行確認テストな訳ないだろ