#phpmd

[hikariru]

GrumPHPでコードの治安を守りたい

Qiitaさんからお引っ越しです。

GrumPHPとは

commit前にテスト走行やlintなどのタスクを自動実行してくれるcomposerプラグインです。 皆さんおなじみのPHPUnit、PHPCS、PHPMDだけでなくPHPSpecやBehatにも対応しているため、気軽にコードの治安を維持することができます。

（品質って単語を使うとQA界隈の怖い人たちに怒られそうなのであえてふんわりした言葉を使ってます。）

使い方

1. 依存パッケージに追加

composer require --dev phpro/grumphp

2. grumphp.ymlを書く

私が普段使ってるgrumphp.ymlを置いときます。 書き方は公式のドキュメントが充実しているので割愛します。

3. git hookを追加

下記コマンドを叩くと.git/以下にpre-commitとcommit-msgが追加されます。 あとはいつものようにgit commitするだけ！

./vendor/bin/grumphp git:init

4. OKなとき

おじさんのもっさりした笑顔と共にcommitされます。

5. NGなとき

怒られてcommitできません。こわい。

pros

チームで同じhookを簡単にシェアできる

チームのリポジトリにgrumphp.ymlをチェックインすれば、チーム内で同じタスクを走行してからコミットできるようになるため治安のレベルを揃えやすくなります。

cons

チームでGrumPHPの導入を提案したいのは山々なのですが 下記の壁があって今のところ一人で使うにとどめています。。。

Vagrantとの連携がちょっと面倒

hooks_preset: vagrantとgrumphp.ymlに記述すればgit:init時にVagrant用のhookが生成されます。 しかし、生成されるスクリプトは現在のディレクトリにVagrantfileがある前提のものなので、もし作業ディレクトリ外にあるVagrantを利用している場合にはhookを直接書き換えなくてはいけません。 このあたりもう少し個々人の環境に合わせたカスタマイズがしやすくなるといいですね。

長期間にわたって多くの人が開発・保守していくコードなので、 チームみんなでコツコツと(でも楽ちんに)治安改善に取り組んでいけたらいいなあと思っています。

[sideci-blog]

keeping a watchdog in the PHP repository(using PHPMD, PHP_CodeSniffer)

These days more people are trying to follow the coding rules. The coding style is also illustrated in details in PHP: The Right Way. Regarding PHP, our codes are all verified by the service called SideCI and when it finds code style violation, it comments (bark out) in PullRequest. (※This is our service.) This service makes PHP_CodeSniffer and PHP Mess Detector(PHPMD) verify the repository.…

View On WordPress

[yuji0602]

# 概要 最近何かと[Atom](https://atom.io/)の話題が出てくるので、Atomを利用し始めました。 Atom上でphpmdの結果を表示するプラグインを利用してみます。 # 前提条件 MacにてAtomを利用し...

久しぶりにQiitaに投稿した。 phpmdがあるととても助かる。

http://qiita.com/yuji0602/items/5496de46f798178a4371

[php-belfast]

Meetup #1 - PHP QA by @DragonBe

Last Thursday saw the very first PHP Belfast Meeting. Hosted by SimplyZesty and sponsored by 31 Interactive.

We were very lucky to have PHPBelenelux's Michelangelo Van Dam present to deliver a first rate presentation on PHP Quality Assurance tools.

Why Bother?

The talk started with the obvious question Why Bother with QA? and of course the most obvious answer is protection. Protecting your code, protecting your clients business and protecting your own business/reputation. But It's also about esteem, you feel better knowing your code is better. It's also about saving, yes saving time. Because broken code doesn't needs maintenance.  It's about providing continuous reporting on code/build state and producing nice graphs with green colours for managers.

The topics list included

Version Control

Documenting

Testing

Measuring

Automating

Team

I'm not about to go over everything covered, it would simply take too long. But let me just pull out a couple of highlights.

Source Control

The first step is to implement Source Control. The decision on which SCM tool to choose is arbitrarily up to you, the user/company/team leader... but choose one, learn it and make sure your team uses it too.

Git is flavour of the month but you can just as easily use Mercurial or even Bazaar as well as the older, and  well known Subversion.

Unit Testing

The next step is to start unit testing. Without unit testing, You can't know that your code is good. Michelangelo covered unit testing in some depth with excellent examples and thankfully, an example application that is available for download for you to play with and start writing your own unit tests.

If you've never dipped your toe in the water with unitTesting, see the links at the end of this post, download the application and have a go.

Automation

"Computers are great at repetitive tasks"

Anything that you do more than once should be automated. Automation can cover many topics and tools, from running your phpUnit tests to deployment and monitoring code health.

Start small, start with your tests or even a single test and work your way up. Using a build tool like Phing  you can run a batch of commands, and eventually using a continuous integration server such as Jenkins you can automatically run and re-run these scripts over and over again.

There was of course much more to it that this short synopsis, and you are encouraged to have a look at the slides at for more detail.

As Michelangelo said at the start. It doesn't matter where you start with QA, so long as you do start. Don't necessarily Identify a weakness to be protected. Instead, try to identify the most important part of your application, and work on protecting that.

And keep watching, who knows when we get another visit from Michelangelo, and by then, you better have your code... up to code.

Links

The Slides from Michelangelo's talk are online at:  http://www.slideshare.net/DragonBe/workshop-quality-assurance-for-php-projects-phpbelfast 

Unit testing example application http://github.com/DragonBe/zftest <-- Go on Fork it and have a go!

QA Tools:-

Git: http://git-scm.com/

PHP Documentor: http://www.phpdoc.org/

PHPDepend: http://pdepend.org/

PHP Copy Paste Detector: https://github.com/sebastianbergmann/phpcpd

PHP Mess Detector: http://phpmd.org/

Mantis bug tracker: http://www.mantisbt.org/

Phing : http://www.phing.info/

Jenkins Continuous Integration: http://jenkins-ci.org/

If you'd like to hear more from Michelangelo, consider attending PHP Benelux's annual conference, Jan 25-26 2014. More details at http://phpbenelux.com/ 

Finally, if you would like to attend the next meet, or your would like to sponsor a meet, go on over to the Google group or get in touch via email [email protected]