Why to use Scrutinizer

Symfony Meetup #3 で発表したスライドです。
https://symfony.doorkeeper.jp/events/23051

#symfony_meetup

Transcript

1. Why  to  use  Scrutinizer Improve  code  quality  and  find  bugs  before  they  hit   production  with  our  continuous  inspection  platform symfony  meetup  #3  (2015.04.26) @imunew
2. Who  am  I? hitomedia,  inc. Innovation  Div.  Deputy  CTO Motohiro  Imura @imunew
3. What  do  I  do?
4. use  php;
5. 話すこと •  scrutinizer-‐‑‒ciを活⽤用した品質向上 への取り組み •  PHP開発における静的コード解析の 重要性
6. 話さないこと •  symfonyについて •  デプロイについて テストが通ったら⾃自動的に◦◦環境に デプロイ... •  インフラについて いみゅーたぶるいんふらすとらくちゃー
7. scrutinize-‐‑‒ciを導⼊入した きっかけ
8. •  Symfonyもくもく会  #4  を開催しました   -‐‑‒  kseta's  blog http://kseta.hatenablog.jp/entry/2015/02/22/222158 •  ⼊入社当時（2013年年5⽉月頃）、Jenkins +phpcpd、phpmdで社内のコードを静的 解析して遊んでいた http://www.ryuzee.com/contents/blog/3453 http://www.ryuzee.com/contents/blog/3479
9. First  Buildを成功させる までにしたこと
10. •  sign  in  (Log  in  via  Github) •  Add  Repository •  Build  失敗  ＝  Test  Failed – ここで若若⼲干試⾏行行錯誤 – /.scrutinizer.yml  を作成 – 除外ファイルを指定 – テスト実⾏行行前に必要な処理理を記述 – テスト実⾏行行時のコマンドを記述（上書き） – とりあえず、テストを全部成功させる （phpunit.xml  でexclude設定したり）
12. First  Buildが成功した後 にしたこと
13. •  Summary  (Code  Rating,  Coverage)
14. •  Issue
15. •  すぐ修正できる箇所は修正 –  未定義のメンバ変数への代⼊入 –  未使⽤用のコードを削除 •  PHPの⾔言語仕様を再確認 –  selfとstaticの違い private  static  な変数に、static::$hogeと参照すると、 Bugでissueが... •  とにかくRatingに⼀一喜⼀一憂 –  点数が上がるのが楽しい（ゲーミフィケーション）
18. Workflow
19. 1.  作業⽤用ブランチを作成 2.  リモートにpush(空でもOK) 3.  [WIP]  PR作成 4.  push 5.  Scrutinizer-‐‑‒CIのビルド結果を確認 6.  問題なければ、[WIP]を外してレビュー 7.  merge  pull  request
20. scrutinizer-‐‑‒ciを導⼊入して みて変わったこと
21. •  品質が可視化、定量量化された •  ⾃自分達の実⼒力力が分かる •  はっきりとした数値⽬目標を作りやすい •  社内や社外のStakeholderに説明する材料料になる –  全社共有会でRatingを発表 –  お客様とのミーティングにて取り組みを紹介 •  ⼀一定レベルの品質を保てる –  エンジニアが多いチームには特に有効
22. 課題
23. •  scrutinizer-‐‑‒ciでビルドしないと問題がわから ない – php-‐‑‒analyzerを単体でローカルで実⾏行行したい •  issueが多すぎる – issue  filterの検討 •  ローカルではテストが成功するのに、 scrutinizer-‐‑‒ciでテストが失敗する – scrutinizer-‐‑‒ciがどうやってsourceを取ってきてい るか詳細が分からない – ssh  loginさせてほしい
24. あらためて思うところ
25. •  PHPは柔軟＝厳格ではない PHP  is  crazy. HHVM  +  Hack  ==  PHP++   https://www.youtube.com/watch?v=ihJeXNqK9jU
26. •  コードレビューは、バグを検出するためにする のではない –  レビュアーだって間違えるし、完璧ではない –  コードレビューにおいて⼤大事なことは、コードや 設計について議論論や相談をすること •  ソフトウェアがソフトウェアを作る時代では まだない –  ソフトウェアを作るのは⼈人間 –  ⼈人間は間違える –  性悪説に基づいて品質を考える
27. •  まず最初は静的検査ツールを使う IPA  ISEC 　セキュア・プログラミング講座 第2章  脆弱性回避策とソフトウェア開発⼯工程：ソースコードレビュー http://www.ipa.go.jp/security/awareness/vendor/programmingv2/ contents/c103.html
28. •  正しいコーディング、Best  Practiceを チームメンバー全員が理理解することが重 要 •  間違えを出さないのではなく、間違えを 出しにくくする、間違えに早く気付くこ とが重要 •  とにかく、scrutinizer-‐‑‒ci  使いましょう
29. ご清聴ありがとうご ざいました
30. さいごに http://www.amazon.co.jp/dp/4863541686