本文來自medium----原文連接; 歡迎做客咱們的php&Laravel學習羣:109256050
這是我天天對本身說的話。像不少人同樣,我不會像TDD所建議的那樣測試個人代碼。我如今在使用測試,在過去的半年裏一直這樣作,前面還有很長的路要走。php
我是在處理複雜的遺留項目時決定學習測試。代碼是如此的脆弱和僵硬,以致於一旦咱們添加一些代碼就會破壞它。新的特徵?實現和破壞某事!修復錯誤?新建另外一個。程序員
這是一個大問題,並讓我開始嘗試測試。編程
第一個工具是PHPUnit。如官方網站所述架構
PHPUnit是PHP的面向程序員的測試框架。這是單元測試框架xUnit架構實例。框架
因此,PHPUnit是幫助您建立您的項目的測試框架,單元測試。它提供了幾個函數來測試代碼的結果,並生成與這些測試結果相同的良好輸出。函數
自從我開始思考測試、閱讀、和於人交談測試,我發現了另外一個偉大的工具,它是對之前那些單元的測試工做的補充,它就是Behat,這是一個BDD的PHP框架。工具
BDD(行爲驅動開發)是一個來自TDD(測試驅動開發)的開發過程。這些縮寫詞如今並不重要,重要的是你可使用更天然的語言來講明你的測試,這種語言對於非技術人員也能夠理解它。單元測試
這種語言被稱爲Gherkin,是用來描述被測試的預期的行爲。使用Gherkin看起來像這樣學習
在這些描述背後,每當描述於phpDoc中的指定的方法有正則模式匹配相應的php代碼就會被調用,經過SDK、應用程序或Web系統,這些代碼實現了這些步驟,模擬真實的用戶將作的測試
使用Behat工做是如此順利。在一切正確配置以後,您開始編寫測試一個特性的全部可能場景。一旦你運行behat,它給你全部你應該添加到您的PHP環境類的方法模版以便實施場景的每一步
以後,您開始編寫每一步的實際代碼,並繼續重複這個循環。
在經歷一個半小時的配置和閱讀文檔後,你能夠開始使用Behat,到最後你看到的都是php代碼而後你就已經知道了怎麼編寫它
持續集成(CI)是一個過程——一種作某事的方法,而這一點對於咱們的軟件工程師來講,就是創造軟件。
簡單地說,它是將小代碼塊(也許天天幾回)不斷的整合到代碼庫中的行爲。代碼將被測試而且沒有異常。CI幫助您自動化應用程序的構建、測試和部署。
經過幾回點擊,你能夠經過Travis CI集成你的GitHub項目,每次推送到倉庫後會運行你以寫好的PHPUnit和Behat測試,這些測試告訴你最後實現的特色是否準備好,是否要合併。除此以外,您還可使用Travis CI將代碼部署到生產環境和暫存。
經過一個被良好規範的程序實現一個良好的工做流程是極好的,Travis CI能夠幫助你作這項工做。遵循這個好的開始,發現對軟件開發過程的思考是多麼有趣,而不只僅是代碼自己。
若是你之前不知道PSR是什麼,那麼如今你應該去了解了。實際上PSR表明PHP Standard Recommendation(PHP規範推薦),PHP-FIG建議使用它們。PHP—FIG是一個成員來自最大的PHP項目、框架和CMS系統的一個組織,它致力於對語言的將來、生態系統的思考和討論應被遵循的PHP規範
很長一段時間以來PHP都沒有編碼風格。我沒有那麼老,但每次我看到別人的項目或庫時,它們的風格都不一樣。有時把括號放在一個位置,有時把它放在下一行,用不一樣的方法來處理長長的一行代碼,還有其餘風格和喜愛的組合。真是一團糟。
PHP—FIG作許多其餘的工做,但提出一個統一的代碼,他們說:「讓咱們中止操心代碼風格,讓咱們每一個人都遵循同一個標準,並開始思考創造偉大的軟件」。如今,每當你查看某人的代碼時,你只會操心它是如何工做的,而不是研究格式、結構。
在文章的最後,一共有9種被接受的PSRs爲解決常見問題的推薦解決方案。但若是你不知道這些標準的話,以PSR-1和psr-2做爲起點。
這些標準提出了現代PHP編碼風格。請務必在開始使用以前閱讀它們。不要認爲在編寫代碼時你會記住全部的代碼,這是一個過程,但爲了讓你肯定你使用的規範,有一些工具能夠幫助你完成它。
PHP CodeSniffer是一種工具,你能夠在Packagist上找到它,使用Composer安裝它。我不認爲這個庫名稱是最好的選擇,由於它包含兩種不一樣的工具,分別是phpcbf PHPCs。
Phpcs代碼嗅探器,它會掃描你的整個代碼,查找與配置的編碼標準不符的代碼部分。
您能夠經過PHPCs使用多種編碼標準你甚至能夠建立你本身的標準。在代碼掃描結束,PHPCs列出不遵循標準的代碼片斷。真是太好用了。
如今,如何修改全部的錯誤的代碼片斷?你能夠打開全部的文件,更改代碼,運行PHPCs直到看到錯誤不顯示出來,並重覆上述過程。這樣會很無聊。
爲了解決這一問題,PHPcodesniffer的一個稱爲phpcbf的工具發揮做用了,或成爲PHP代碼美化工具。它在不破壞你的代碼的前提下盡力修復全部的錯誤使之符合相同的代碼規範。
試着養成習慣,在push你的代碼到你的倉庫以前使用phpcs和phpcbf檢查代碼,這將保證你所寫的代碼都符合規範,一旦有人喜歡你的項目並想貢獻時,他們閱讀起代碼來毫無問題。
我不想花太多的時間討論框架,下面有一個好的框架,各有優缺點,就我而言,我不喜歡使用這些封裝來全部東西的大框架。我喜歡須要什麼就使用什麼。
若是你須要一個HTTP 客戶端,好比Guzzle。若是你須要你個模版引擎好比Twig。若是你須要一個路由器。找到適合你的組建並使用他們,將他們組合起來構建你本身的應用。
Symfony爲這個概念作了不少,你可使用這整個框架做爲一個項目,也能夠像上面所述使用任何你須要的組建。
然而,每當我須要使用框架來寫應用,我一般會選擇微型框架。它們真的很小,近提供最基礎的組件,而且十分的容易定製。
個人微型框架選擇是Slimframework,我認爲你們都應該去試試它。
順便提一下,對於剛學編程的人來講,我真的建議在採用框架和使用前,你應該試着創建一個你本身的框架。這將讓你對這整個的工做機制有個總體的瞭解。並讓你在之後採用大型框架時更容易理解。
讓咱們以一組連接表來結束這篇文章,對於我來講,這些組件和工具和庫就表明來現代PHP的偉大思想:
我知道這個標題確實很自負,在這裏我真正想說的是PHP正在進步,它的生態系統一樣也在進步(可能更快)。