開發經驗 - PHP 求使用架構開發的一些經驗

看完了Scholer的《現在寫 PHP，你應該知道這些》，才清楚開發中，工作使用的架構和自己喜歡的架構時可以區分開的。因為我之前用架構開發，資料庫設計，後台，前台，每次一個新項目的開始都要重新做一次資料庫設計，網頁的頁面，開發週期長，老闆覺得這樣不好，說需要開發一個CMS，提高程式的重用性。目前選擇架構時，我擔心的是:

1. 客人的伺服器版本可能還是使用5.3.x版本

2. 假如客人伺服器版本是PHP5.3.X，用yii2或者Laravel 4.2 開發的項目，在客人的伺服器中不能使用

目前我在Yii2和Laravel 4.2這兩個架構之間徘徊，因為這兩個要求的PHP版本都是5.4 或者之上，所以我自己不敢實打實的去學習其中的一個架構。Thinkphp目前考慮以後不再使用，因為這是我目前使用的，只是想跳出TP。

因為我目前只清楚資料庫的RBAC,USER表的設計，背景RBAC是可以重用的，相應的功能，我要根據項目的實際功能進行重新code一次。

希望有朋友可以告訴我一些開發的建議，在使用架構時，我應如何提高程式的重用性，避免一個新的項目開始，資料庫設計，後台，前台都減少相應的重複操作。

第一次提問，廢話有點多，還請你不吝賜教。

回複內容：

看完了Scholer的《現在寫 PHP，你應該知道這些》，才清楚開發中，工作使用的架構和自己喜歡的架構時可以區分開的。因為我之前用架構開發，資料庫設計，後台，前台，每次一個新項目的開始都要重新做一次資料庫設計，網頁的頁面，開發週期長，老闆覺得這樣不好，說需要開發一個CMS，提高程式的重用性。目前選擇架構時，我擔心的是:

1. 客人的伺服器版本可能還是使用5.3.x版本

2. 假如客人伺服器版本是PHP5.3.X，用yii2或者Laravel 4.2 開發的項目，在客人的伺服器中不能使用

目前我在Yii2和Laravel 4.2這兩個架構之間徘徊，因為這兩個要求的PHP版本都是5.4 或者之上，所以我自己不敢實打實的去學習其中的一個架構。Thinkphp目前考慮以後不再使用，因為這是我目前使用的，只是想跳出TP。

因為我目前只清楚資料庫的RBAC,USER表的設計，背景RBAC是可以重用的，相應的功能，我要根據項目的實際功能進行重新code一次。

希望有朋友可以告訴我一些開發的建議，在使用架構時，我應如何提高程式的重用性，避免一個新的項目開始，資料庫設計，後台，前台都減少相應的重複操作。

第一次提問，廢話有點多，還請你不吝賜教。

怎麼說呢…… 其實當時寫這個 是跟一個朋友討論問題，他問我能不能把一些東西組件化、熱拔插這種，我說可以啊…… 試試composer…… 很偶然很偶然，我弄這麼個標題純屬無意……但是這種標題似乎都帶有些爆炸性……

其實我的初衷是想說明一件事情：PHP 在變化，可以選擇的也多，不要還拿 wordpress、或者某些基於 PHP4 時代的架構的眼光來看待。

之前很多人都看過 phptherightway，也有人翻譯過《Modern PHP》這本書，其實我的觀點和作者是一致的：PHP 在變化，從事這一行，是否你也考慮一下改變自己？

就像我們以前常用 PHPMailer 來發郵件，現在 很多架構裡整合的 卻是 swiftmailer。如果你用過 Laravel，不防研究一下 vendor 下的每個依賴項目？每個依賴項目的作者還做過什麼別的有意思的東西？

當然我這麼講，也是因為我自己也會搞搞伺服器上的事情，所以一直也不在乎客戶提供什麼，因為這些我都可控，在乎的都是我想要做什麼。

我想做什麼，這也是我選擇什麼、喜歡什麼的原因。這是一份工作，但不僅僅是完成任務，我可以有自己的喜好，自己的選擇，也能從中獲得樂趣。所以我傾向於多瞭解，選擇最合適的。這個『合適』包括項目成熟度等級、易用程度、學習成本、維護周期等等。

上面這些是在扯背景，再說下你的問題吧。

重用

composer 無疑就是重用和藉助開源的力量簡化一些繁複的工作的手段。這個理念跟 pip、npm 沒什麼分別。只是概念提出來的比較晚（大概 11年 還是 12 年？），所以現在還沒那麼高的知名度。開發一些組件，放到公有和私人倉庫，composer 和 psr4 幫你解決載入的問題，這不是很好的重用嗎？

架構選擇

laravel 和 yii2 本質上有很多相同，但是設計理念上缺又有非常大的不同，你也可以看看別的一些架構，symfony，phalcon 等等。接觸一個新的東西總是會遇到挑戰的，有成本的，主要還是考慮項目類型（是頁面為主還是 API？和前端的配合等等），怎麼選擇？看收益。如果你看不懂長遠的收益，沒法做出選擇的。

資料庫設計

資料庫設計其實本身是個和 PHP 和架構都無關的問題。如果說扯上關係，不防從兩個方面來想：

1. 預置的資料表/資料關係

2. ORM 或者 Model 操作方式

這個問題講大了可以扯到設計理念、程式碼群組織方式之類的，扯小一點就是：能不能快速上手。

實際開發中，哪怕是設計一個登入註冊的模組，對於某些開發人員來說可能都要很久（有的人也許擅長實現、但並不擅長設計）。所以選擇一些預置了某些基本資料關係的架構可能會容易一點。

至於 ORM 和 Model 這一塊，簡單的例子，Eloquent 的操作方式和 CodeIgniter 肯定是不同的。光是概念都有很多：Active Record、data mapper、DAO（創造概念來描述自己的想法這件事情產生的自豪感也許比內容本身更大）。你要麼不用架構，要麼造個輪子，要麼乖乖的按照架構的思維模式來，因為架構總免不了有一堆整合工具的組合（或者說是最佳實務）。

後台、前台

這個問題其實和前面一段差不多，你大概知道 yii2 有一個什麼 advanced 版本，幫你分一下 frontend、backend 之類的。這個事情做起來困難嗎？不困難。但重要的是什嗎？一個概念、或者叫一個設計吧，還是那句話：有些開發人員擅長實現，但並不擅長設計。後台前台的分離，是搭兩套架構，還是一套架構裡套兩個不同的 app 目錄，還是自己設計一個基於 URI 或者網域名稱區分的，事情的本身並不重要。重要的是實現成本。

其實講了這麼多，我想表述的是什麼呢？就是要有自己的『觀點』、『調研』、『喜好』。然後能嘗試動手『實踐』。工程師不是機器，有自己的喜好才是正常。喜好和工作並不衝突，就像業務和技術並不衝突一樣。想辦法把自己的想法和喜好付諸實踐，用技術帶動業務才是吾輩應該做的事情。

再多扯一點。

PHP 不像前端，現在搞得貌似是蓬勃生機，欣欣向榮，有那麼多流派。但 PHP 也並沒有沉淪，也一直都有傳統觀點：能幹活就行，現代一點的觀點：Composer、PSR，甚至像 symfony 路由都已經寫到注釋裡去了，再高端一點的：C 擴充，PHP 是個架子（此類大神也許對前面的多有不屑）。這本身也是多樣化、靈活性的一種表現。

PHP 不是最好的語言，甚至談不上是好的語言，但好在無數業界前輩（比如鳥哥，比如 nikic，PHP 核心開發，也創造了 FastRoute、PHP-Parser 這些優秀的組件）正努力讓它變好，嘗試他們的勞動成果也是一種貢獻，也許最終你我都會是受益者。

為啥不再使用Thinkphp,想跳出tp 給後面掉坑的人也指條明路

OneThink不就是基於ThinkPHP現成的後台嗎?第三方的還有ThinkCMFX, CoreThink, ShuipFCMS這些.

我覺得你這兩個擔心完全時多餘的，你大可正常使用這兩個架構開發，如果部署時真是客戶的 PHP 只能時 5.3 的，大不了你根據出現的問題，修改這些架構的源碼（都是開源的，沒有後顧之憂），進行 5.3 的適配即可。5.3 到 5.4 的改動並不算多，輕輕鬆鬆可以完成適配。

另外：
ThinkPHP確實存在一些弊端，你早點離開並不是件壞事。我認為ThinkPHP最大的隱患就是沒有支援Psr4的規則，導致基本很難引入體系外的第三方庫。這也就是架構之間程式很難複用的原因。

