摘要：這大概是我沒有及早使用，或多數(shù)開發(fā)者流連現(xiàn)狀造成的。它就是，一個的框架。行為驅動開發(fā)是來自測試驅動開發(fā)的開發(fā)過程。簡單的說，它就是經(jīng)常可能一天幾次將小塊代碼整合進基礎代碼當中的行為。
這是一篇社區(qū)協(xié)同翻譯的文章，已完成翻譯，更多信息請點擊?協(xié)同翻譯介紹?。
文章的標題真是自命不凡，不是嗎？是的，雖然我們使用 PHP 工作很多年，但是我們能夠說出哪些是最佳實踐和最好的工具嗎？我不能，但是我將要去這么做。
我看到開發(fā)者們使用 PHP 工作的方式正在發(fā)生真正的變化，不僅因為 PHP 新的版本和自身逐步的完善，讓 PHP 語言發(fā)生了巨大變化，變得更加成熟和健壯，更重要的是整個生態(tài)系統(tǒng)也在不斷地改變。
為了使代碼更優(yōu)雅和更易于理解，人們創(chuàng)造了新的工具、庫、框架和文章，定義了新的設計模式。一些人還在思考如何讓工作（和開發(fā)者的生活）變得更具生產(chǎn)力，更簡潔和更有趣。
我不是一個新趨勢的早期追隨者，實際上，我只會在一個新工具有了社區(qū)和我認為它能改善我的工作后才會去使用它。我經(jīng)常做的僅僅是嘗試采用最佳實踐來寫代碼。
所以，我花了一段時間以后才開始使用 Composer 和 PHPUnit 等工具。大約一年以前，我才向這些閃亮的新事物敞開了心扉。
先是 PSR，然后是 Composer，PHPUnit，Travis-ci 等其他幾個庫和令人驚奇的工具。我甚至已經(jīng)開始使用 IDE 了（Vim FTW，但是配置了 XDebug 的 PHPStorm 才是一個明智的工作環(huán)境）！
什么是現(xiàn)代化？
作者：?Karen Roe?(Flickr) [CC BY 2.0 (http://creativecommons.org/li...)]
網(wǎng)上有大量的文章說 PHP 多么可怕，從事 PHP 編碼工作會讓你的生活多么糟糕，語言是多么丑陋以及你能想到的任何其他東西！
如果你打算使用遺留代碼，可能你的生活不會太好，但是如果你有機會參與一個新的項目并且能夠使用所有的新工具，那么你將會看到我要講的這個新的 PHP 。
我每天都會用 PHP 處理一些問題，但是人們無法關注語言、社區(qū)以及生態(tài)系統(tǒng)所發(fā)生的變化 。雖然還有很長的路要走，但是 PHP 領域的事情正在變得越來越成熟。
我開始為我工作的公司創(chuàng)建一個內部 API 的 SDK，例如一個寵物項目，并且決定遵循最佳實踐。大部分事件我已經(jīng)在做了，但是我在做某些事情的時候做了一些改變。這些改變以及我去年學到的知識是本文的主題，我稱之為現(xiàn)代化 PHP 。
我們從工作流程開始
如我所說，我剛剛使用 IDE 沒有多久，但是自從用上了 IDE ，我就喜歡上了。PHPStorm 是軟件中的頂級杰作。它將會是我的第一個也是此后唯一一個 IDE 。它是我的首次嘗試，它好到我沒有必要再去嘗試其他的IDE。
集成的 XDebug 簡直完美，還有 PHP 命名空間解析、 composer 、git 、代碼自動補全、代碼生成、代碼重構。讓我說三天三夜都說不完。
我不認為你必須使用 IDE ，實際上，這完全是個人觀點。你需要使用諸如此類的符合你的需求的，例如：Vim 、Atom 、Emacs 、Bracket 、NetBeans 、 PHPStorm 、Eclipse ，等等。很重要的兩點是生產(chǎn)力與人體工學。你的 IDE 或文本編輯器必須是協(xié)助你工作的，而不是拖累你。
然而，對于我來說，很重要的一點是對于調試功能的集成。寫一個大型項目（其實小項目也一樣）你需要一個很好的調試工具。讓我們忘掉那些var_dump和print_r。你需要在代碼運行時設置變量的值、分析堆棧、設置斷點。 這些才是至關重要的，它們使得開發(fā)和重構更加容易。
我甚至不知道是否還有其他的選擇，XDebug 擁有你所需要的一切。你現(xiàn)在有時間嗎？如果你還沒有做過這些事情，請花一點時間安裝 XDebug 并把它整合到你的 IDE 里吧。從現(xiàn)在開始使用正確的工具來調試你的代碼。
另一個我想讓你引起注意的工具是 Github?？梢詫懸淮笃恼聛斫榻B Git 和 Github 有多棒，以及你為什么必須開始使用版本控制來管理你的代碼，但此處我想為你展示另一個原因。
這里的重點就是 integration （GitHub Integration，譯者注）。
Github 中還整合了其他幾個工具，并且你應該開始使用它們。在持續(xù)化集成過程中，這些工具可以為你生成數(shù)據(jù)，跑測試，跑任務，在你的工作流中為你做各種各樣的事情。Integration 是你開始使用 Github 的一個很好的理由，其他的事情都可以暫時靠邊站。
依賴管理
現(xiàn)代 PHP 生態(tài)的另一點就是依賴管理，Composer 也由此而生。
Composer 已經(jīng)5歲了，但大規(guī)模應用還是近兩年的事。這大概是我沒有及早使用，或多數(shù) PHP 開發(fā)者流連現(xiàn)狀造成的。
它是 Packagist 的終端，而 Packagist 是 PHP 包的倉庫，由 PHP 庫、項目以及工具組成，源碼保存在 Github （或 BitBucket 等）。
本文談及的所有第三方庫，都可以輕松地添加到你的項目中。
$ composer require package_vendor/package_name
要是不知道第三方庫的名稱，可以使用 search?查找。
$ composer search package_name
Composer 是管理依賴的不二之選，但絕不僅于此。不妨花點時間安裝 Composer，閱讀其?文檔。
處理得當?shù)拿钚薪缑?/b>
我真的愿意嘗試快速使用 CLI 界面的想法。對我而言，最偉大的 REPL 工具是?IPython。該工具可自動完成你的代碼，讓你輕松定義函數(shù)，悠閑地訪問文檔，還有其他的多個驚艷的特性。對我們不利的是，該工具用于 Python 而非 PHP。
PHP 世界里有種稱之為 “互動模式” 的東西，可以通過終端工具訪問，只需鍵入以下代碼：
$ php -a
Interactive mode enabled
php >
本場景中即處于互動模式，能著手一些東西的測試。該模式很管用，不過太不直觀了。我還是賣力地嘗試了幾次，由于我知道 IPython 的本事，因此令我根本不會繼續(xù)用這個模式。
幸運的是，存在一款全新酷炫的 CLI (命令行界面) 工具，名叫 Psysh。 Psysh 是一款令人驚艷的工具，充滿了引人注目的特性，可以全局安裝，也可使用 composer 按項目安裝。
對我而言最棒的 Psysh 特性就是內嵌文檔功能。直接查詢一個PHP函數(shù)的文檔而無須跑到 Php.net 網(wǎng)站上，簡直棒極了。 缺點是你在享用所有功能前還必須完成幾件事。
該工具安裝完畢后，為正確運行就要輸入以下命令（我這里用的是 Debian ，未必適合所有人) ：
$ apt-get install php7.1-sqlite3
$ mkdir /usr/local/share/psysh
$ wget -o /usr/local/share/psysh/php_manual.sqlite
第一條命令并不是強制性的并且如果你已經(jīng)安裝了 Sqlite 你可以跳過這一步。第二個命令創(chuàng)建目錄來存儲文檔而第三條命令下載并將文檔保存到先前創(chuàng)建的目錄中。記住，所有這些命令都必須以 root 身份運行。
現(xiàn)在你有了這些：
psysh 指令文檔說明的截圖，顯示關于 json_decode 的信息。
點擊此鏈接前往 Psysh?了解更多關于這個炫酷的工具。
你應該開始測試
這是我每天對自己說的咒語。像很多人一樣，我沒有按照 TDD 的建議去測試代碼。我現(xiàn)在已經(jīng)養(yǎng)成測試習慣，并且已經(jīng)持續(xù)了半年，然而還有很長的路要走。
當我面對一個復雜的遺留項目時，我決定學習測試。那個項目代碼如此奇葩，以至于任何時間我添加一些代碼都會出問題。 用新特性? 實現(xiàn)功能和制造問題！修改一個bug? 還是創(chuàng)建一個新的吧。
那是一個大問題，我在另一篇，并且是我開始嘗試使用測試。
我想推薦的第一個工具是?PHPUnit。 正如官網(wǎng)展示的：
PHPUnit 是一個面向程序員的PHP測試框架
PHPUnit 是一個實例 xUnit 架構的單元測試框架
所以，PHPUnit 是一個為你的項目生成統(tǒng)一測試的框架，它會提供一些函數(shù)去測試你的代碼并且有漂亮的結果輸出。
自從我開始考慮測試，閱讀和與人交談它，我發(fā)現(xiàn)另一個很棒的工具，它會補充你在這些統(tǒng)一測試中的工作。它就是 Behat，一個 PHP 的 BDD 框架。
BDD（行為驅動開發(fā)）是來自 TDD（測試驅動開發(fā)）的開發(fā)過程。這些縮略詞現(xiàn)在不重要，重要的是您可以使用更自然的語言來指定您的測試，這是非技術人員可以理解的語言。
這個語言被稱為 Gherkin，用于描述正在測試的預期行為，使用 Gherkin的測試描述，如下所示：
在這些行后面有 PHP 代碼，只有在該方法的 PhpDoc 中指定的行和正則表達式之間存在匹配，就會調用該代碼。該代碼使用你的 SDK、應用程序或者 web 系統(tǒng)實現(xiàn)這些步驟以及真正的用戶將執(zhí)行的操作
Behat 的工作流程十分流暢。在一切正確配置之后，你就可以開始編寫測試功能的所有可能方案。當你首次運行 Behat 時，它會提供你所有那些你應該添加到 PHP Context 類中的方法模板以便實現(xiàn)場景中的每一個步驟。
在那之后，你就可以為每一個步驟編寫實際代碼并重復此循環(huán)。
為每一個步驟編寫 PHP 代碼
運行測試
如果一切正常，為其它步驟編寫 PHP 代碼
如果有地方出了問題，修復它
在配置和閱讀文檔半小時后，你可以準備使用 Behat，到最后你會發(fā)現(xiàn)全都是 PHP 代碼并且已經(jīng)發(fā)現(xiàn)你已經(jīng)知道如果使用它編程。
持續(xù)集成
持續(xù)集成（ CI ） 是一個過程，它提供一個為軟件工程師創(chuàng)建軟件的一個方法。
簡單的說，它就是經(jīng)常（可能一天幾次）將小塊代碼整合進基礎代碼當中的行為。代碼已經(jīng)測試過且不會出現(xiàn)突發(fā)情況。CI 幫我我們自動構建，測試和部署到我們的應用中。
只要幾次點擊，就可以將你的 Github 的項目集成到 Travis CI 中之后你每次將代碼推送到倉庫，它會運行你創(chuàng)建的 PHPUnit 和 Behat 文件，并告訴你最近的功能是否已經(jīng)準備，或沒有，或將要被合并。除此之外，你可以使用 Travis CI 將你的代碼部署到生產(chǎn)環(huán)境中運行。
通過一個明確定義的工作流程來完成工作流程是非常好的，Travis CI 可以幫助我們完成這個工作。閱讀這篇 ?Getting started ，了解軟件開發(fā)過程是如此有趣而并不僅僅是代碼本身。
遵循 PSR-1 和?PSR-2
如果你還聽說過 PSR ，那你應該馬上去了解。實際上，PSR 是 PHP Standard Recommendations 的簡寫，是由?PHP-FIG?(PHP Framework Interop Group) 推出的。PHP-FIG 是由一些大的 PHP 項目、框架、CMS的成員組成的組織，旨在思考這門語言的未來、生態(tài)，討論語言中應遵循的標準。
很長一段時間以來，PHP 沒有編碼風格之說。我的年紀還不是很大，但是每一次我看別人的項目或庫的時候，它們都使用不同的編碼風格。有時候花括號在這個位置，有時候它又在下一行，一個長行的處理方式也會有好幾種，各種不同的編碼風格和喜好混合在一起，一團糟。
PHP-FIG 做了很多的工作，通過推出統(tǒng)一的編碼規(guī)范，他們好像在說：“不要再糾結編碼風格了，讓我們所有人都遵循一個標準，然后重心都集中于好軟件的制作上吧”?，F(xiàn)在，無論什么時候你想閱讀某人的代碼時，你只需要關心代碼是如何運行的就可以了，而不用再指責他的代碼風格和結構了。
截止至此篇文章發(fā)布，已經(jīng)有9個達成共識的 PSR 標準推出，為一般問題提供了通用解決方案。如果你還不知道這些標準，就從 PSR-1?和?PSR-2 開始吧。
這些標準提出了現(xiàn)代 PHP 的編碼風格，確保你已經(jīng)讀過并已經(jīng)開始使用它們了。別想著你能在寫代碼的時候全部想著它們，這是一個漫長的過程，但是你應該知道，有一些工具可以輔助你使用和記住它們。
PHP CodeSniffer?就是一個你能在 Packagist 上找到并使用 Composer 安裝的工具。我認為這個庫的名字并不是很理想，因為它實際上包含了兩個工具， phpcs 和 phpcbf。
Phpcs 用于代碼風格檢測，它會全面掃描你的代碼，找出那些不符合已經(jīng)配置好的編碼規(guī)范的部分。
你可以使用 phpcs 內置的很多種編碼規(guī)范，也可以自定義編碼規(guī)范。在掃描的最后，它會為你列出不符合編碼規(guī)范的代碼片段，非常棒。
那么，怎么才能把錯誤改正呢？你可以打開每一個文件，改代碼，再運行 phpcs ，看看是否還有錯誤，然后重復這個過程。非常無聊。
為了解決這個問題，PHP CodeSniffer 提供了另一個工具，叫做 phpcbf 或 PHP Code Beautifier。在同一套編碼規(guī)范設置下，運行 phpcbf，它就會在不破壞你的代碼的前提下，盡最大努力為你改正所有的錯誤。
試著建立在代碼提交之前運行 phpcs 和 phpcbf 的習慣，這將會保證你所有的代碼都符合編碼規(guī)范，如果有人喜歡你的工具（或工程）并且想貢獻代碼，他們在閱讀你的代碼時將不會有任何阻礙。
框架
我不打算花費太多的時間來討論框架，現(xiàn)在已經(jīng)有一些不錯的框架了，或流行或小眾。個人而言，更傾向于不使用那些內置所有功能的重型框架，我的想法是，你僅僅選擇你需要的那個就好了。
如果你需要一個 HTTP 客戶端，你可以使用 Guzzle。如果你需要使用模板引擎，那么你可以使用 Twig。如果你需要一個路由，那么找一個能夠滿足你需求的組件并使用它就好了。將這些組件組裝起來，打造你自己的應用吧。
Symfony?框架沿著這個方向已經(jīng)做了很偉大的工作。你可以為你的項目使用整個框架，或者僅僅選擇并使用你想要使用的一部分。就是那么的簡單。
然而，無論何時我想使用框架來完成一個應用時，我總會從為被稱為微框架的那些框架中選擇一個。它們真的很輕，僅僅提供基本的功能，易于定制化，并且可以方便的讓它來適應你的項目架構。
我選擇的微框架是?Slimframework?，我覺得你應該讀一讀它。對于處理小型項目，它真的很簡單，但是對于較大的項目，使用它就有些復雜了。
順便向正準備編程的同學們說一下，我真心覺得，在你選擇一個框架并打算一直使用它之前，你應該動手創(chuàng)造一個屬于你自己的框架。這會讓你理解框架的運行機制，并且能更快地適應大型框架。
現(xiàn)代PHP工具包
讓我們用一系列工具包來結束文章。 對我來說，這些組件、工具和庫描繪了現(xiàn)代PHP的樣子：
Slimframework： 一個很好、很酷的小型框架
Symfony：一個由很多優(yōu)秀、可重用組件構成的重量級框架
Guzzle:：可以很簡單容易發(fā)起HTTP請求的客戶端
PHPUnit： 一個測試框架
Behat： 行為驅動的測試框架
PHPCS/CBF：代碼規(guī)范、美化工具
Faker：生成測試數(shù)據(jù)的庫
Psysh: 充滿令人驚訝的交互式控制臺
Composer：依賴管理，且有著其他很多有用的特性
Packagist：PHP包倉庫
Twig: 模板引擎
我知道，文章的標題真的有些狂妄。其實我想要說的是PHP正在進化，PHP生態(tài)圈也在以同樣（也許更快）的速度進步。
討論請前往：https://laravel-china.org/top...
