Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

このPHP QAツールがすごい!2019

1,560 views

Published on

※ 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

Published in: Engineering
  • Be the first to comment

このPHP QAツールがすごい!2019

  1. 1. このPHP QAツールが すごい!2019 PHP Conference Japan 2019 sasezaki Dec 01, 2019
  2. 2. なぜQAツール?
  3. 3. 「うーん、このコードは、うんこ!」
  4. 4. 「コードの評価に、 測定・判定基準を示せない ということでしょうか?」 「うーん、このコードは、うんこ!」
  5. 5. 「 言い換えで現実から 目を背けるな!」 「うーん、このコードは、いかn!」
  6. 6. 経済産業省『システム及びソフトウェア品質の見える化、確保及び向上のためのガイド』より https://www.meti.go.jp/policy/it_policy/softseibi/metrics/product_metrics.pdf 今回の発表では主に内部品質に係る QAツールの話をします
  7. 7. アジェンダ  PHP QAツールの歩み  CI/CD利用の浸透とともに注目を集めるQAツールの 歩みをふりかえり、昨今の事情を鑑みます  PHP QAツール最前線  QAツールのリスト紹介  堅牢なコードのための、静的解析・コーディングスタン ダード検査・リファクタリングツールについて深堀りし ます  QA ツールの段階的適用  サンプルコードを例にQAツールを段階的に適用していき ます  まとめ
  8. 8. 品質を評価するには、判定するツールの力 が必要です。 だから、PHP QAツールの全容とこれまで の歩みを振り返りましょう。
  9. 9. PHP QAツールの歩み brief history around PHP QA tool
  10. 10. ~2007 xUnit、 コーディングスタンダード、 メトリクス、 そしてCIへの礎が築かれた時期
  11. 11.  phpt  PHPUnit 2001  phing 2002  Hudson(のちのJenkins) 2005  phpUnderControl + CruiseControl  lime, simpletest  PHP_CodeSniffer ~ 2007
  12. 12. 2008~2011 RAD、エンタープライズアーキテクト の時代と ともに複雑化するプロジェクトへの模索の時期
  13. 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. 14. 2012~2015 アサーションやコードジェネレートへの 折り合いが落着き、 安定なパッケージ・品質測定への 開発に歩み始めた時期
  15. 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. 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. 17. 2016~ AST を 軸に、静的解析による 堅牢なコード構築の時代
  18. 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. 19. 2019年末 PHPを取り巻く状況 PHP 7 前提での型宣言/静的解析時代 ただし、phan/psalmでの型アノテーション・ジェネリク ス※後述 が広く普及・サポートされている訳ではない 多言語での現状 JS … flowtype、そしてTypeScript Python … PEP 484 mypy Ruby … Sorbet, Ruby3 型定義ファイル …SaaSでの冪等なデプロイ、ならびに PHP 8 でのpreloadを前提とした ビルド時代に・・・まだなってはいない
  20. 20. 高度に解析できる土台を手に入れ、 堅牢なコードを構築する枠組みは すぐそこにある! 我々は悲しみを減らせることができる!
  21. 21. > 静的解析の実行に対して "ある程度でのあきらめが肝心"
  22. 22. > 静的解析の実行に対して "ある程度でのあきらめが肝心" あきらめが早すぎる!
  23. 23. みなさん、今のPHP QAツールの ポテンシャルを探索してないのでは ?
  24. 24. 品質を評価するには、判定するツールの力が必要です。 だから、PHP QAツールの全容とこれまでの歩みを振り返りま しょう。 しかし、現在では出来合いの解析ツールの セットアップなどに留まり、近年のPHPに おける解析検査の可能性を把握できてはい ないではないでしょうか?
  25. 25. PHP QAツール最前線 Awesome PHP QA tools beyond 2019
  26. 26. QA ツールのリスト jakzal/toolbox 静的解析Dockerイメージ集 jakzal/phpqaのベース phpqa.io ※ 継続的検査SaaS の類(SymfonyInsight、PrettyCIなど)や、 デバッガー・プロファイラー・サンプラー(TidewaysやPHPSpyなど)は 上記に掲載ありません。
  27. 27. QA適用場面のレイヤーを どのように捉え、 ツールを吊り上げるべきか?
  28. 28. QA 高品質化への依存関係ピラミッド IPC - Aggressive PHP Quality Assurance in 2019 | Marco Pivetta https://www.youtube.com/watch?v=8rdTSYljts4
  29. 29. IPC - Aggressive PHP Quality Assurance in 2019 | Marco Pivetta https://www.youtube.com/watch?v=8rdTSYljts4 QA 高品質化への依存関係ピラミッド
  30. 30. システム要件 を満たし、 静的解析でエラーとならないコードにし、 テストとミューテーション解析で要件を満たしていることを試験し、 安定性が崩れていないかを確認し、 最新化を常に行えるようにして、セキュリティを担保し、  Dockerなど  依存性の確認 (maglnet/composer-require-checker など )  phan, PHPStan とプラグイン(no-floaters), psalm など  PHPUnit、Behat、CodeCeption などなど  Infection  roave/backward-compatibility-check  roave/security-advisories  Dependabot
  31. 31. システム要件 をcomposer-require-checkerであぶりだす
  32. 32. 堅牢なコードのためのコード解析を掘る • コーディングスタンダードチェッ ク • リファクタリングツール • 静的解析ツール
  33. 33. 厳密なコーディング規約 により腐臭を取り除く 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 …など
  34. 34. slevomat/coding-standardでの検出例 一貫したフォーマットルール違反を検出する 「意味のない三項演算子を禁止したい!」
  35. 35. slevomat/coding-standardでの検出例 一貫したフォーマットルール違反を検出する UselessTernaryOperator sniffによる検出
  36. 36. より良いオブジェクト志向のための美容 により、メンテナンス性・可読性・テスト容易性を上げる 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
  37. 37. リファクタリングを自動化する により、レガシーコードをアップグレードしていく rector https://getrector.org/  PHP 各バージョンアップでのコードベースの変更  PHP 7.4向けのコード変更パッケージも用意  ClosureToArrowFunctionRector など  各フレームワーク・ライブラリでのバージョンアッ プへの追随パッケージ  コード品質・SOLIDに関するリファクタリング ※ コーディングスタンダードの各fixerと被る領域
  38. 38. 型アノテーションを記述する により、詳細な型の制限をもたらし、プログラムを防御する • phan • psalm • PHPStan
  39. 39. 型アノテーションを記述する により、詳細な型の制限をもたらし、プログラムを防御する PHP における型と DocCommentのこれまで 各静的解析ツール導入の前に・・・
  40. 40. PHPにおける型とDoc Commentのこれまで PHP 4 • 名前空間がない • クラス名重複避けのために冗長な 命名により可読性が悪い • アクセス修飾子がない • カプセル化が担保できず、安全に不安が残る 抱えていた問題
  41. 41. PHPにおける型とDoc Commentのあれこれ PHP 5.3 ~ • 引数へのスカラー型宣言が できない • 引数の型が保証されず堅牢にならない 抱えていた問題
  42. 42. PHPにおける型とDoc Commentのあれこれ PHP ~ 7.3 • プロパティの型宣言が できない • やっぱり堅牢さが足りない 抱えていた問題
  43. 43. PHPにおける型とDoc Commentのあれこれ PHP 7.4~
  44. 44. PHPにおける型とDoc Commentのあれこれ statusって設定可能なのは何? optionには何が設定できるの? 残る不安・混乱
  45. 45. 静的解析を始めだすと、PHPに型が 足りないのが改めて認識できる • スカラー値の引数型宣言 7.0 • nullablな型 7.1 • クラスプロパティの型 (typed property) 7.4 • Enum • クラスの可視性 (internal) • イミュータブル (readonly) • ジェネリクス/テンプレート • コールバックへの型づけ • 交差型 、 Union型 8.0 • 連想配列がオブジェクトもどき arrayは嘘 • 純粋ではないリスト arrayは嘘 PHPにおける型とDoc Commentのあれこれ
  46. 46. 型アノテーションを記述する により、詳細な型の制限をもたらし、プログラムを防御する Enum array-shapes
  47. 47. 型アノテーションを記述する により、詳細な型の制限をもたらし、プログラムを防御する phan psalm
  48. 48. PHP でも型検査を行える 異常者に近づけるのが お分かりいただけますでしょうか? https://twitter.com/mizchi/status/1166503910569172992
  49. 49. 自分の利用している ライブラリには、 型アノテーションの記述がないです !! ※ ここで言うライブラリとは、 vendor/google とか vendor/psr とかの 話をしています。
  50. 50. ベンダーライブラリへの型スタブ により静的解析での型アノテーションでのエラーを検出する psalmによるスタブ利用例のご紹介 自分の利用している ライブラリには、 型アノテーションの記述がないです !!
  51. 51. 1.元のコードファイルをコピーします vendor/phpcon2019/shop-mall/PetStoreApi.php stubs/phpcon2019/shop-mall/PetStoreApi.php
  52. 52. 2. 型アノテーションを追加します 3. スタブに追加します。 stubs/phpcon2019/shop-mall/PetStoreApi.php psalm.xml
  53. 53. 4. 完成! 期待されない文字列・ 連想配列への型・必須チェックが行えた!
  54. 54. プラグインとして公開してもらえるとさらに良い https://packagist.org/?type=psalm-plugin
  55. 55. 品質を評価するには、判定するツールの力が必要です。 だから、PHP QAツールの全容とこれまでの歩みを振り返りましょう。 しかし、現在では出来合いの解析ツールのセットアップなどに留まり、近年のPHPに おける解析検査の可能性を把握できてはいないではないでしょうか? 近年のQAツールの発展により、あなたのプロ ジェクトコードをより強固にする土壌は揃って います。 したがって、各QAツールに改善を積み重ねて いきましょう。
  56. 56. QAツールの段階的適用 step by step applying QA tool
  57. 57. サンプルコード:電話番号のチェック https://devblog.thebase.in/entry/2019/06/13/110000 のコードから(一部改変)
  58. 58. サンプルコードに対するテストコード
  59. 59. テスト実行
  60. 60. 数値以外のチェックが できていない カバレッジの確認
  61. 61. アサーションの追加
  62. 62. カバレッジ100%
  63. 63. …そして、バグ判明
  64. 64. 意図しない挙動が発生しうる関数をコーディングスタン ダードで禁止する
  65. 65. phpcs.xml での設定
  66. 66. fail で落ちるのを確認する
  67. 67. プログラムを修正し、 CSチェックにてfailしたものが通るのを確認するとともに テストがパスすることを確認
  68. 68. 「テストケース以外の要件が コーディングされている」
  69. 69. ミューテーション解析で テストケースに漏れがあるのを確認する
  70. 70. infection.log
  71. 71. テストケースを追加し、 テストケースの不足がないことを確認する
  72. 72. …そして、バグ判明
  73. 73. 「ネットからコピペした正規表現ですので、 僕は悪くありません」 「正規表現によるバリデーションでは ^ と $ ではなく A と z を使おう」 https://blog.tokumaru.org/2014/03/z.html
  74. 74. 「特定の目的にそったQAツールが 見当たらないなら 注意するしかないよね?」 「正規表現によるバリデーションでは ^ と $ ではなく A と z を使おう」 https://blog.tokumaru.org/2014/03/z.html
  75. 75. 「目的にあったQAツールがなければ 自作しよう」
  76. 76. 「目的にあったQAツールがなければ 自作しよう」
  77. 77.  自作 PHPStanプラグインの話  自作 Infectionミューテーターの話  自作 PHP_Codesniffer 用 Sniffの話  自作 スタブの話 おまけの自作しましょう話
  78. 78. まとめ
  79. 79. 品質を評価するには、判定するツールの力が必要です。 だから、PHP QAツールの全容とこれまでの歩みを振り 返りましょう。 しかし、現在では出来合いの解析ツールのセットアッ プなどに留まり、近年のPHPにおける解析検査の可能 性を把握できてはいないではないでしょうか? 近年のQAツールの発展により、あなたのプロジェクト コードをより強固にする土壌は揃っています。 したがって、各QAツールに改善を積み重ねると、品質 への不安を減らしていけるのが分かります。 これらにより、開発で真に考えたかった機能の詳細に 立ち向かえていきます。
  80. 80. 今日の主な話は  PHPそのもののアップデートや、開発手法・周 辺のエコツールの発展が行われてきたこと  昨今のQAツールの助力を得て、内部品質を向 上する手助けの土壌が育っていること  解決すべき問題を見極めつつ、QAツールを適 用していきましょう  場合によっては自作も
  81. 81. 小話 「静的解析ツールはどれを使えば良いのか分からない」 どちらも使 えば良いのでは? 「なんで、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用など)おおすぎ 問題
  82. 82. ご清聴ありがとうございました

×