資訊專欄INFORMATION COLUMN
摘要：為那些經常出現在控制器或者門臉中的轉發代碼編寫單元測試是很不劃算的事。單元測試也有其成本。最理想的做法就是在持續集成服務器上，每次更改時都運行，從而在無需單元測試的情況下防止此類錯誤的產生。在年開始廣泛使用包管理，單元測試和編碼標準的工具。
PHPStan：無需寫測試就能找到代碼中的 Bug
每當我看到開發人員從 Java 或 C# 等編譯語言切換到 PHP 這樣的解釋語言時解放了生產力后感到很高興。除了這些常規的執行模型（發起、處理請求和結束請求）和更短的反饋環（無需等待編譯器）外，還有一個能解決開發人員日常問題的開源框架生態系統，因此，PHP 是目前來說?web 開發中最流行的語言。
但它有一個缺點。
你會在什么時候發現錯誤?編譯型語言需要在程序運行之前了解每個變量的類型，每個方法的返回類型。這就是為什么編譯器需要確保程序是沒有錯誤的，并且會在源碼中向你指出這些類型的錯誤，比如調用了未定義的方法或者是向某個函數傳遞了錯誤數量的參數。在把應用程序部署到生產環境前，編譯器算是第一道防線。
然而 PHP 就不會這樣了。如果程序出錯，會執行到錯誤的代碼的時候崩潰。在測試 PHP 應用時，不管是自動化測試還是手動測試，開發人員都會花費大量時間去查一些其它編譯型語言不會犯的錯從而減少測試實際業務邏輯的時間。
我想改變這一點。
歡迎來到 PHPStan 的世界現階段 PHP 實踐所產生的代碼庫中，我們可以確定大部分數據的類型，并且轉換為靜態類型的語言，盡管還保留著一些動態語言的特性。人們把現在的 PHP 代碼庫變得跟其他語言一樣更加有趣。面向對象，依賴注入以及設計模式的使用已經變得非常普遍。
這讓我想到了 PHP 的?靜態分析工具，它將替代其他語言的編譯器角色。我花了很多時間研究它，并且已經使用它的各種開發版本來檢查我們的代碼庫超過一年。
它就是?PHPStan, 開源且免費 它目前校驗什么？有關類中涉及的，對象實例， 錯誤/異常捕獲，類型約束以及其他語言結構的存在性。 PHP 照舊不會檢查這些， 但是會展現其中未被使用的代碼。
被調用的方法和函數的存在性和可訪問性。同樣也會檢查他們的參數個數。
方法是否返回了它聲明的返回值類型。
被訪問成員變量的存在性和可見性。它也可指出是否將一個其他的類型的值賦給了既定類型的成員變量。
sprintf/printf 函數基于格式化字符串所應接收的參數個數。
分支和循環范圍中的變量的存在性。
無用的形式指定。例如 (string) "foo" ，以及不同類型變量間的嚴格比較 (=== 和?!==)，因為他們的結果總為 false。
這個清單的內容隨著每次發布都在遞增。但成就 PHPStan 也不會只仰賴此一技之微。
PHPStan 迅疾如飛...它設法一次性檢查整個代碼庫。 它無需多次遍歷代碼。 只需瀏覽您想要分析的代碼，例如 你寫的代碼。它無需解析和分析第三方依賴項。 相反，它使用反射來找出有關你代碼庫中引用的他人代碼的有用信息。
PHPStan 能在一分鐘里檢查我們的代碼庫 (6000 個文件， 600k LOCs) 。它可在一秒內完成自查。
...可擴展性即便當前正在使用靜態類型，開發者也可以合法的使用 PHP 的動態語法特性，例如?get,?set 和 __call 這些魔術方法。它們可以在運行時去定義新屬性和方法。通常，靜態分析都會爆出屬性和方法未定義，但是有一種機制可以告訴引擎如何創建新的屬性和方法。
它得益于對允許用戶擴展的原生 PHP 反射的自定義抽象。更多細節可查看?README 中類反射擴展章節。
某些方法返回的類型取決于它的參數。它可以取決于你傳遞給它的類名，也可能返回與傳遞的對象相同的類的對象。這就是?動態返回類型擴展?的用途。
壓軸語： 如果你想自己出一個 PHPStan 的新的檢查項，?你可以自力更生。可以提出基于特定框架的規則，例如檢查?DQL查詢中引用的實體和字段是否存在，或者你選擇的 MVC 框架中生成的鏈接是否和現存的控制器有關。
選擇規范級別我使用過其他工具，并將之集成進現有的代碼庫中，這種體驗真是往事不堪回首。他們爆出成千上萬的錯誤讓你沒法使用。
取而代之，我回顧如何集成 PHPStan 到剛進入開發階段的代碼庫中。 首個版本的功能不是很強大，這時并未發現多少錯誤。但從集成的角度來看，它還是非常不錯的?---?有空時，我就為它增加新規則，我修復了它在版本庫中找到的錯誤，并將新代碼合并到主分支。我們會使用新版本幾周用來發現其找到的錯誤，并不斷重復這件事。這種逐級增加的規范性的做法在實踐中看來大有裨益，所以我使用 PHPStan 的現有功能來模擬它。
默認情況下，PHPStan 只檢查它確定的代碼---常量，實例化，調用$ this的方法，靜態調用的方法，函數和各種語言結構中的現有類。 通過增加級別（從默認值0到當前值4），您還可以增加它對代碼所做的假設數量以及它檢查的規則數量。
如果內建級別無法滿足你的要求，你同樣也可以自定義規則。
少寫單元測試! (披沙揀金)可能這個建議你聞所未聞。即便是非常細碎的代碼，開發者也不得不編寫單元測試，因為這方面犯錯的幾率都是均等的，例如簡單的拼寫錯誤或者忘記將結果賦值給變量。為那些經常出現在控制器或者門臉中的轉發代碼編寫單元測試是很不劃算的事。
單元測試也有其成本。它們同樣也是代碼，難逃編寫和維護的窠臼。最理想的做法就是在持續集成服務器上，每次更改時都運行 PHPStan，從而在無需單元測試的情況下防止此類錯誤的產生。實現100％的代碼覆蓋率真的很難，并且非常昂貴，但你可以靜態分析100％的代碼。
至于單元測試的重點應當集中在靜態分析代碼難以察覺的，容易出錯的地方。包括：復雜的數據過濾，循環，條件判斷，乘除法包含舍入的計算等。
站在巨人的肩膀上如果不是?Nikita Popov?創建了?PHP Parser。就不會有 PHPStan 的出現。
PHP 在 2016 年開始廣泛使用?包管理，?單元測試?和?編碼標準?的工具。然而到現在也沒有一個廣泛使用的工具，可以在不運行代碼的情況下檢查代碼中的錯誤。所以我創建了一個易于使用，快速，可擴展的版本，既不會對您的代碼有嚴格的要求，你還會從這些檢查中受益。查看?GitHub 倉庫?，了解如何將其集成到您的項目中！
更多文章：https://laravel-china.org/c/t...
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/29635.html
摘要：最近發現自己寫的代碼運行結果總跟自己預想的不一樣，排查時發現大多是語法錯誤，在運行之前錯誤已經種下。最后代碼的語法錯誤，應該在編寫的時候及時發現，盡量減少正式運行時錯誤。 最近發現自己寫的PHP代碼運行結果總跟自己預想的不一樣，排查時發現大多是語法錯誤，在運行之前錯誤已經種下。可能是自己粗心大意，或者說php -l檢測太簡單，不過的確是有一些語法錯誤埋藏得太深（畢竟PHP是動態語言），...
摘要：默認的配置不會檢測任何代碼。參數列表質量檢測包其他有人問，你為什么要這么折磨自己呢其實像類型代碼質量工具，不是僅僅自己拿來玩的，在開發人員略多的技術團隊，可以通過使用它來達到代碼規范一致，如果每個人代碼都不一樣，后果不堪設想。 showImg(https://segmentfault.com/img/bVbtfeF?w=1796&h=724); 前言 我一生的文章都會放在這里，我的博客...
摘要：是一個免費和開源的應用，能夠集成至任何項目中，并收集和展示分析數據。它有沒有任何依賴，支持請求，包括常用開發庫的通用數據采集器和收集器。 DebugBar 是一個免費和開源的應用，能夠集成至任何PHP項目中，并收集和展示分析數據。它有沒有任何依賴，支持Ajax請求，包括常用開發庫的通用數據采集器和收集器。 相信用過Laravel的調試工具的同學，都感到這個工具非常強大好用，極大地提高了...
摘要：比如上面的例子文件文件我們利用做了語法解析檢測，代碼如下報錯哪里類重復了不存在查看該屬性是否存在于父類中原理能就是對解析出來的繼續做分析，但是前人栽樹后人乘涼，這樣的完整工具已經有大神幫我們做好了。 原文：我的個人博客 https://mengkang.net/1356.html 工作了兩三年，技術停滯不前，迷茫沒有方向，不如看下我的直播 PHP 進階之路 （金三銀四跳槽必考，一般人...
摘要：注意本文是我們的性能分析系列的第三篇，點此閱讀性能分析第一篇介紹，或性能分析第二篇深入研究。小的性能提升很可能來自優化，而非緩存。注意此更改已提交到并已獲更新。目前，兩者具備相同的特性，只有一些部分重命名了。 注意:本文是我們的 PHP 性能分析系列的第三篇，點此閱讀?PHP 性能分析第一篇: XHProf & XHGui 介紹?，或??PHP 性能分析第二篇: 深入研究 XHGui...
閱讀 1615·2021-11-22 09:34
閱讀 1698·2019-08-29 16:36
閱讀 2679·2019-08-29 15:43
閱讀 3123·2019-08-29 13:57
閱讀 1307·2019-08-28 18:05
閱讀 1888·2019-08-26 18:26
閱讀 3256·2019-08-26 10:39
閱讀 3469·2019-08-23 18:40
