優雅導入 PHP CS_Sniffer 至 Legacy 專案
Introduce PHP Linter into legacy project smoothly
目錄
導入工具限制常常會有機會聽到反對的聲音，因為害怕工具造成開發效能降低，雖然這是必然的…
產品的 品質 跟 效率 本身存在著互斥的關係，既有的開發資源中如何在這兩點之間取捨，一樣是開發者每天會面臨的課題。
試著提升團隊的開發品質而導入 Linter 當然也不希望就此影響大家在開發上直接遇到困難，希望採用 漸進式 的方式協助大家慢慢適應 Coding Style 的重視。 全新的專案可以無痛的直接引入，但是 Legacy 專案其實常常令人頭痛或者不想面對，如何優雅的導入呢?
我們選擇使用 PHP CS_Sniffer，接下來告訴大家我們如何讓大家技能開始接受 Coding Style 的規範也能在開發中的效率與之取捨。
本日主角:
coverageChecker
https://github.com/exussum12/coverageChecker
簡述其作法:
步驟拆解
- diff 存成 txt
- phpcs 跑完 export to JSON format
- coverageChecker 會用 1 的 diff 去 Parse 2 警告的內容並顯示
這樣的作法就可以 只針對每次修正的 Diff 作檢查，確保今後提交的程式碼都有受其保護跟檢查。
確實落實 Clean Code 中的童子軍原則
信息
「離開營地前，讓營地比使用前更加乾淨。」
專案整併
Require coverageChecker
composer require squizlabs/php_codesniffer --dev
composer require exussum12/coverage-checker --dev
},
+ "require-dev": {
+ "squizlabs/php_codesniffer": "*",
+ "exussum12/coverage-checker": "^1.0"
+ }
}
串 Makefile 或者將其整進 CI
.PHONY: lint, lint-summary, fix
CS_SNIFF_CONFIG := phpcs.xml
APP_DEFAULT_PATH := application
lint:
@echo "> Check coding style for diff sections only"
@git diff origin/master > diff.txt
@./vendor/bin/phpcs --standard=$(CS_SNIFF_CONFIG) --report=json $(APP_DEFAULT_PATH) > phpcs.json || true
@./vendor/bin/diffFilter --phpcs diff.txt phpcs.json 100
lint-summary:
@./vendor/bin/phpcs --standard=$(CS_SNIFF_CONFIG) --report=summary
fix:
@./vendor/bin/phpcbf --standard=$(CS_SNIFF_CONFIG)
文章系列
- PHP Linter 和 Formater 選擇
- 解密 PHP_CodeSniffer Configuration File
- 優雅導入 PHP CS_Sniffer 至 Legacy 專案