※ twitter上でnot foundの場合は適当なパラメータつけたURLにしてください。 https://www.slideshare.net/sasezaki/php-qa2019-200006092?p PHPカンファレンス2019のスライドです https://fortee.jp/phpcon-2019/proposal/01abf927-eb46-4708-95a1-ae05b9ac2bcf

1. このPHP QAツールが
すごい！2019
PHP Conference Japan 2019
sasezaki
Dec 01, 2019

2. なぜQAツール？

3. 「うーん、このコードは、うんこ！」

4. 「コードの評価に、
測定・判定基準を示せない
ということでしょうか？」
「うーん、このコードは、うんこ！」

5. 「 言い換えで現実から
目を背けるな！」
「うーん、このコードは、いかｎ！」

6. 経済産業省『システム及びソフトウェア品質の見える化、確保及び向上のためのガイド』より
https://www.meti.go.jp/policy/it_policy/softseibi/metrics/product_metrics.pdf
今回の発表では主に内部品質に係る
QAツールの話をします

7. アジェンダ
 PHP QAツールの歩み
 CI/CD利用の浸透とともに注目を集めるQAツールの
歩みをふりかえり、昨今の事情を鑑みます
 PHP QAツール最前線
 QAツールのリスト紹介
 堅牢なコードのための、静的解析・コーディングスタン
ダード検査・リファクタリングツールについて深堀りし
ます
 QA ツールの段階的適用
 サンプルコードを例にQAツールを段階的に適用していき
ます
 まとめ

8. 品質を評価するには、判定するツールの力
が必要です。
だから、PHP QAツールの全容とこれまで
の歩みを振り返りましょう。

9. PHP QAツールの歩み
brief history around PHP QA tool

10. ~2007
xUnit、 コーディングスタンダード、 メトリクス、
そしてCIへの礎が築かれた時期

11.  phpt
 PHPUnit 2001
 phing 2002
 Hudson(のちのJenkins) 2005
 phpUnderControl + CruiseControl
 lime, simpletest
 PHP_CodeSniffer
~ 2007

12. 2008~2011
RAD、エンタープライズアーキテクト の時代と
ともに複雑化するプロジェクトへの模索の時期

13. 2008 ~ 2011 PHPSpec 2008
 PHP 5.3 2009
 PHPMD 2010
 Mockery 2010 0.6.0
 travis ci PHPサポート 2011
 『REAL-WORLD SOLUTIONS FOR DEVELOPING HIGH-
QUALITY PHP FRAMEWORKS AND APPLICATIONS』2011
 php-project-wizard
 PHPUnit, phpcs , phpmd, phploc などを導入するためのプロジェクトセット
 Behat 2011 1.0.0
 composer 2011
 php-cs-fixer 2012

14. 2012~2015
アサーションやコードジェネレートへの
折り合いが落着き、
安定なパッケージ・品質測定への
開発に歩み始めた時期

15. 2012 ~ 2015 nikic/php-parser 2012 (0.9.0)
 Trismegiste/Mondrian 2013 ダイアグラム
 PHPVisualDebt 2014 騒動
 php7cc Compatibility Checker 2015
 scrutinizer-ci 2013 頃 PHP CI SaaSの先駆け
 ラスマスが各OSSにPull Request 2013
 Roave Security Advisories 2014 ~
 phpcs-calisthenics-rules 2014 1.0.0
2012年のプレゼン「Object Calisthenics Applied to PHP」を経てのルール
 phpbench 2015
 PHP 7.0 2015 Dec
Found using static analyzer: hhvm --hphp -t analyze

16. QA ツールの分類 ※Qafooの2016年スライドに基づく
実現したいこと ツール名
コーディングスタイルのチェ
ック
PHP_CodeSniffer
コードメトリクスの計測 PHPLOC
冗長化したコードの検出 PHP Copy/Paste
Detector （PHPCPD）
複雑度と結合度のチェック PHP Depend
潜在的なバグの検出 PHP Mess Detector
（PHPMD）
ソフトウェア層（コントローラなど）
の依存関係をチェック
Deptrac
https://qafoo.com/talks/16_10_internation_php_conference_automating_architecture_constraint_checks.pdf
https://developers.gnavi.co.jp/entry/ipc2016-report3

17. 2016~
AST を 軸に、静的解析による
堅牢なコード構築の時代

18. 2016~ exakat May 2015 v-0.2.0
 phan Dec 2015 0.1
 DeptracApr 2016 プロジェクトでのレイヤ構造をルール化
 phpstan July 2016 0.1.0
 localheinz/phpstan-rules Nov 2018 0.1.0
 phpstan-exception-rules Jun 2018 0.1.0
 psalm Nov 2016 0.1.0
 roave/you-are-using-it-wrong May 2019 1.0.0
 dePHPend Oct 2016 0.1.0
 phpmnd Magic Number Detector Apr 2017 1.0.0
 rector July 2017
 Infection もとはトークンベースのhumbug July 2017 0.1.0
 Roave Backward Compatibility Check May 2018 1.0.0

19. 2019年末 PHPを取り巻く状況
PHP 7 前提での型宣言/静的解析時代
ただし、phan/psalmでの型アノテーション・ジェネリク
ス※後述 が広く普及・サポートされている訳ではない
多言語での現状
JS … flowtype、そしてTypeScript
Python … PEP 484 mypy
Ruby … Sorbet, Ruby3 型定義ファイル
…SaaSでの冪等なデプロイ、ならびに
PHP 8 でのpreloadを前提とした
ビルド時代に・・・まだなってはいない

20. 高度に解析できる土台を手に入れ、
堅牢なコードを構築する枠組みは
すぐそこにある!
我々は悲しみを減らせることができる!

21. > 静的解析の実行に対して
"ある程度でのあきらめが肝心"

22. > 静的解析の実行に対して
"ある程度でのあきらめが肝心"
あきらめが早すぎる！

23. みなさん、今のPHP QAツールの
ポテンシャルを探索してないのでは
？

24. 品質を評価するには、判定するツールの力が必要です。
だから、PHP QAツールの全容とこれまでの歩みを振り返りま
しょう。
しかし、現在では出来合いの解析ツールの
セットアップなどに留まり、近年のPHPに
おける解析検査の可能性を把握できてはい
ないではないでしょうか？

25. PHP QAツール最前線
Awesome PHP QA tools beyond
2019

26. QA ツールのリスト
jakzal/toolbox
静的解析Dockerイメージ集
jakzal/phpqaのベース
phpqa.io
※ 継続的検査SaaS の類(SymfonyInsight、PrettyCIなど)や、
デバッガー・プロファイラー・サンプラー(TidewaysやPHPSpyなど)は
上記に掲載ありません。

28. QA適用場面のレイヤーを
どのように捉え、
ツールを吊り上げるべきか？

29. QA 高品質化への依存関係ピラミッド
IPC - Aggressive PHP Quality Assurance in 2019 | Marco Pivetta
https://www.youtube.com/watch?v=8rdTSYljts4

30. IPC - Aggressive PHP Quality Assurance in 2019 | Marco Pivetta
https://www.youtube.com/watch?v=8rdTSYljts4
QA 高品質化への依存関係ピラミッド

31. システム要件 を満たし、
静的解析でエラーとならないコードにし、
テストとミューテーション解析で要件を満たしていることを試験し、
安定性が崩れていないかを確認し、
最新化を常に行えるようにして、セキュリティを担保し、
 Dockerなど
 依存性の確認 (maglnet/composer-require-checker など )
 phan, PHPStan とプラグイン(no-floaters), psalm など
 PHPUnit、Behat、CodeCeption などなど
 Infection
 roave/backward-compatibility-check
 roave/security-advisories
 Dependabot

32. システム要件 をcomposer-require-checkerであぶりだす

34. 堅牢なコードのためのコード解析を掘る
• コーディングスタンダードチェッ
ク
• リファクタリングツール
• 静的解析ツール

35. 厳密なコーディング規約
により腐臭を取り除く
slevomat/coding-standard
https://github.com/slevomat/coding-standard
 コードの振る舞いを安全となるように倒す
 declare(strict_types = 1)の強制や、if文内でのアサイン禁止 …など
 デッドコードの検出
 利用されないパラメータ、クラスのインポートのuse 、 …など
 一貫したコードフォーマットルール
利用しているプロジェクト
https://packagist.org/packages/slevomat/coding-standard/dependents
・doctrine/coding-standard
・cakephp/cakephp-codesniffer
・zendframework/zend-coding-standard :develop
…など

36. slevomat/coding-standardでの検出例
一貫したフォーマットルール違反を検出する
「意味のない三項演算子を禁止したい！」

37. slevomat/coding-standardでの検出例
一貫したフォーマットルール違反を検出する
UselessTernaryOperator sniffによる検出

38. より良いオブジェクト志向のための美容
により、メンテナンス性・可読性・テスト容易性を上げる
Object-calisthenics/
phpcs-calisthenics-rules
https://github.com/object-calisthenics/phpcs-calisthenics-rules
『The ThoughtWorks Anthology』で発明された
9つのルールに感化されたwilldurand(Propel, FriendsOfSymfonyのメンテナ)
のブログ記事https://williamdurand.fr/2013/06/03/object-calisthenics/ から
派生したコーディングスタンダードルール
提唱されている9つのルール
 Only One Level Of Indentation Per Method
 Don’t Use The ELSE Keyword else禁止
 Wrap All Primitives And String
 First Class Collections
 One Dot Per Line
 Don’t Abbreviate 短縮禁止
 Keep All Entities Small
 No Classes With More Than Two Instance Variables
 No Getters/Setters/Properties

39. リファクタリングを自動化する
により、レガシーコードをアップグレードしていく
rector
https://getrector.org/
 PHP 各バージョンアップでのコードベースの変更
 PHP 7.4向けのコード変更パッケージも用意
 ClosureToArrowFunctionRector など
 各フレームワーク・ライブラリでのバージョンアッ
プへの追随パッケージ
 コード品質・SOLIDに関するリファクタリング
※ コーディングスタンダードの各fixerと被る領域

40. 型アノテーションを記述する
により、詳細な型の制限をもたらし、プログラムを防御する
• phan
• psalm
• PHPStan

41. 型アノテーションを記述する
により、詳細な型の制限をもたらし、プログラムを防御する
PHP における型と
DocCommentのこれまで
各静的解析ツール導入の前に・・・

42. PHPにおける型とDoc Commentのこれまで
PHP 4
• 名前空間がない
• クラス名重複避けのために冗長な
命名により可読性が悪い
• アクセス修飾子がない
• カプセル化が担保できず、安全に不安が残る
抱えていた問題

43. PHPにおける型とDoc Commentのあれこれ
PHP 5.3 ~
• 引数へのスカラー型宣言が
できない
• 引数の型が保証されず堅牢にならない
抱えていた問題

44. PHPにおける型とDoc Commentのあれこれ
PHP ~ 7.3
• プロパティの型宣言が
できない
• やっぱり堅牢さが足りない
抱えていた問題

45. PHPにおける型とDoc Commentのあれこれ
PHP 7.4~

46. PHPにおける型とDoc Commentのあれこれ
statusって設定可能なのは何？
optionには何が設定できるの？
残る不安・混乱

47. 静的解析を始めだすと、PHPに型が
足りないのが改めて認識できる
• スカラー値の引数型宣言 7.0
• nullablな型 7.1
• クラスプロパティの型 (typed property) 7.4
• Enum
• クラスの可視性 (internal)
• イミュータブル (readonly)
• ジェネリクス/テンプレート
• コールバックへの型づけ
• 交差型 、 Union型 8.0
• 連想配列がオブジェクトもどき arrayは嘘
• 純粋ではないリスト arrayは嘘
PHPにおける型とDoc Commentのあれこれ

48. 型アノテーションを記述する
により、詳細な型の制限をもたらし、プログラムを防御する
Enum
array-shapes

49. 型アノテーションを記述する
により、詳細な型の制限をもたらし、プログラムを防御する
phan
psalm

50. PHP でも型検査を行える
異常者に近づけるのが
お分かりいただけますでしょうか？
https://twitter.com/mizchi/status/1166503910569172992

51. 自分の利用している
ライブラリには、
型アノテーションの記述がないです
！！
※ ここで言うライブラリとは、
vendor/google とか vendor/psr とかの
話をしています。

52. ベンダーライブラリへの型スタブ
により静的解析での型アノテーションでのエラーを検出する
psalmによるスタブ利用例のご紹介
自分の利用している
ライブラリには、
型アノテーションの記述がないです
！！

53. 1.元のコードファイルをコピーします
vendor/phpcon2019/shop-mall/PetStoreApi.php
stubs/phpcon2019/shop-mall/PetStoreApi.php

54. 2. 型アノテーションを追加します
3. スタブに追加します。
stubs/phpcon2019/shop-mall/PetStoreApi.php
psalm.xml

55. 4. 完成！
期待されない文字列・
連想配列への型・必須チェックが行えた！

56. プラグインとして公開してもらえるとさらに良い
https://packagist.org/?type=psalm-plugin

57. 品質を評価するには、判定するツールの力が必要です。
だから、PHP QAツールの全容とこれまでの歩みを振り返りましょう。
しかし、現在では出来合いの解析ツールのセットアップなどに留まり、近年のPHPに
おける解析検査の可能性を把握できてはいないではないでしょうか？
近年のQAツールの発展により、あなたのプロ
ジェクトコードをより強固にする土壌は揃って
います。
したがって、各QAツールに改善を積み重ねて
いきましょう。

58. QAツールの段階的適用
step by step
applying QA
tool

59. サンプルコード：電話番号のチェック
https://devblog.thebase.in/entry/2019/06/13/110000 のコードから（一部改変）

60. サンプルコードに対するテストコード

61. テスト実行

62. 数値以外のチェックが
できていない
カバレッジの確認

63. アサーションの追加

64. カバレッジ100%

65. …そして、バグ判明

66. 意図しない挙動が発生しうる関数をコーディングスタン
ダードで禁止する

67. phpcs.xml での設定

68. fail で落ちるのを確認する

69. プログラムを修正し、
CSチェックにてfailしたものが通るのを確認するとともに
テストがパスすることを確認

70. 「テストケース以外の要件が
コーディングされている」

71. ミューテーション解析で
テストケースに漏れがあるのを確認する

73. infection.log

74. テストケースを追加し、
テストケースの不足がないことを確認する

75. …そして、バグ判明

76. 「ネットからコピペした正規表現ですので、
僕は悪くありません」
「正規表現によるバリデーションでは ^ と $ ではなく A と z を使おう」
https://blog.tokumaru.org/2014/03/z.html

77. 「特定の目的にそったQAツールが
見当たらないなら
注意するしかないよね？」
「正規表現によるバリデーションでは ^ と $ ではなく A と z を使おう」
https://blog.tokumaru.org/2014/03/z.html

78. 「目的にあったQAツールがなければ
自作しよう」

79. 「目的にあったQAツールがなければ
自作しよう」

80.  自作 PHPStanプラグインの話
 自作 Infectionミューテーターの話
 自作 PHP_Codesniffer 用 Sniffの話
 自作 スタブの話
おまけの自作しましょう話

81. まとめ

82. 品質を評価するには、判定するツールの力が必要です。
だから、PHP QAツールの全容とこれまでの歩みを振り
返りましょう。
しかし、現在では出来合いの解析ツールのセットアッ
プなどに留まり、近年のPHPにおける解析検査の可能
性を把握できてはいないではないでしょうか？
近年のQAツールの発展により、あなたのプロジェクト
コードをより強固にする土壌は揃っています。
したがって、各QAツールに改善を積み重ねると、品質
への不安を減らしていけるのが分かります。
これらにより、開発で真に考えたかった機能の詳細に
立ち向かえていきます。

83. 今日の主な話は
 PHPそのもののアップデートや、開発手法・周
辺のエコツールの発展が行われてきたこと
 昨今のQAツールの助力を得て、内部品質を向
上する手助けの土壌が育っていること
 解決すべき問題を見極めつつ、QAツールを適
用していきましょう
 場合によっては自作も

84. 小話
「静的解析ツールはどれを使えば良いのか分からない」 どちらも使
えば良いのでは？
「なんで、PHPStormの話しなかったの？」VS CodeよりLSP サポート
が手厚ければ・・
型アノテーションからPHPStormのメタ作れるといいですね。
PHPのコードがPHPのコードから生成されるようになったので、静的
解析が一貫性が来る時代になりましたね！（arginfoがstubから生成で、
過去のprotoから変更で）
PHPStanのプラグインのほうが作るのが楽で、コード規約っぽいけど
PHPStanプラグインになってるの、どう？(クラスにfinal宣言とか)
特定のメソッド呼び出しを禁止する方法は、いくつかそれっぽいの
(php-ast-to-xml、phpstan-forbidden-method-calls-rule、phinder)浮かぶのでで
すが、検討したところ、まあ
エラーハンドリングの話は深いので、thecodingmachine/safe はまた次
回・・
アノテーションの種類（アサーション・ORM・API用など）おおすぎ
問題

85. ご清聴ありがとうございました