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