摘要：我的學(xué)習(xí)路線入門入門沒啥好說的，會(huì)基本編碼，基本的開發(fā)結(jié)構(gòu)通常指，呵呵噠，類與對(duì)象，就差不多了，可以說是入門了。在這些已有基礎(chǔ)，我們需要學(xué)習(xí)并且還需要學(xué)會(huì)各種推陳出新，這樣才可以讓自己讓他人走得更遠(yuǎn)。

PHP 入門沒啥好說的，會(huì)基本編碼，基本的開發(fā)結(jié)構(gòu)(通常指MVC，呵呵噠)，類與對(duì)象，就差不多了，可以說是入門了。

寫 PHP 最多目前無非就是 OOP，面向?qū)ο螅f時(shí)遲那時(shí)快。不開玩笑地說，與我共事的某些前輩是連 OOP 都搞不清的，這里我就不多說了。

其實(shí)不是說一定要會(huì)，要去理解 OOP，只是如果你理解這個(gè)玩意，對(duì)于你后面的工作已經(jīng)學(xué)習(xí)會(huì)非常的有好處。

其實(shí)面向?qū)ο笠矝]有那么復(fù)雜，只要理解一點(diǎn)，單一職責(zé)，其實(shí)就是一個(gè)對(duì)象越簡(jiǎn)單越好。

也就是說，是自己該做就由自己做，不該由自己做的就不要自己做。

老梗了，所謂 MVC 很多人會(huì)說 Model, View, Controller, 其實(shí)這樣說沒錯(cuò)的，只是這樣說不會(huì)讓你更好地理解結(jié)構(gòu)以及擴(kuò)展性。

MVC 我當(dāng)前的理解是：調(diào)用(度)，也很簡(jiǎn)單，其他框架也差不多這個(gè)原理，當(dāng)然每個(gè)框架的實(shí)現(xiàn)方式都不一樣。

基本流程：

+--------------+      +-----------+      +--------------+                  +--------------+
|              |  ----+  request  +----> |              |  ------------>   |              |
|              |      +-----------+      |              |                  |              |
|   Request    |                         | Route Match  |                  |    Handle    |
|              |      +-----------+      |              |   +----------+   |              |
|              | <----+ Response  +----- |              | <-+ Response +-- |              |
+--------------+      +-----------+      +--------------+   +----------+   +--------------+

大致列了下最基礎(chǔ)的框架底層原理，實(shí)際上咱們開發(fā)中 90% 接觸的只是在 Handle 處的工作，至于 Request、 Match、 Route 等基礎(chǔ)的對(duì)象或者數(shù)據(jù)，框架早已經(jīng)封裝好了，也無需過度糾結(jié)和頭疼這方面的事情，先要把業(yè)務(wù)功能處理好，并且容錯(cuò)處理好即可。

簡(jiǎn)單總結(jié)一句話：知其然而不知其所以然。

進(jìn)階這個(gè)真是個(gè)頭疼的問題，啥叫進(jìn)階，我的理解是，做一些之前沒有做過的(指本領(lǐng)域：PHP)，例如：設(shè)計(jì)模式，SPL，緩存設(shè)計(jì)(Cache)，研究框架，開發(fā)規(guī)范，單元測(cè)試，行為驅(qū)動(dòng)開發(fā)，組件(包括自己著手開發(fā)的)，Composer 等等的東西，都可以理解為進(jìn)階。

框架推薦:

Symfony

Laravel

Yaf

PHP 開發(fā)規(guī)范(PSR):

PHP FIG

PHPUnit & TDD/BDD:

PHPUnit

PHP spec

設(shè)計(jì)模式：

設(shè)計(jì)模式

SPL:

PHP SPL

Composer:

Composer

歡迎補(bǔ)充

設(shè)計(jì)模式，一個(gè)在軟件設(shè)計(jì)中占有重要角色的課程，而我們又不得不去了解。而對(duì)于設(shè)計(jì)模式來說，很多人是抗拒的，因?yàn)樗推胀ǖ拈_發(fā)者有著不一樣的思維方式，一個(gè)很明顯的提升就是: 設(shè)計(jì)，而設(shè)計(jì)應(yīng)該是根據(jù)發(fā)展的變化而變化，業(yè)務(wù)的變化而變化，模式也一樣，不會(huì)是永恒不變的。唯一不變的是，基礎(chǔ)，這些技巧與思維少不了的是需要良好的基礎(chǔ)。

所以說，基礎(chǔ)是多么重要的，任何一切的一切都是建立與基礎(chǔ)之上，這叫積累。如同蓋樓。

在這些已有基礎(chǔ)，我們需要學(xué)習(xí)并且還需要學(xué)會(huì)各種推陳出新，這樣才可以讓自己讓他人走得更遠(yuǎn)。

設(shè)計(jì)模式學(xué)習(xí)推薦: 設(shè)計(jì)模式

當(dāng)今互聯(lián)網(wǎng)，每秒鐘都是錢，能節(jié)省的，絕對(duì)不能浪費(fèi)，而且節(jié)省還可以一定地提高服務(wù)的質(zhì)量。

一般我們說的資源是:

內(nèi)存

帶寬

磁盤

CPU

而這些之間其實(shí)是有一定的關(guān)聯(lián)的，和代碼質(zhì)量和容錯(cuò)機(jī)制也有一定關(guān)系。

上述每一個(gè)都很重要，決定著你的服務(wù)質(zhì)量。

能少占用內(nèi)存就少占用內(nèi)存，圖片、媒體資源能壓縮就壓縮，減少無用的存儲(chǔ)，降低代碼的復(fù)雜度。

比較常見的是: file_get_contents，connection，有時(shí)候我們會(huì)很自然地遺忘這里其實(shí)會(huì)有一定幾率出現(xiàn)超時(shí)，最嚴(yán)重的就是造成服務(wù)無響應(yīng)，如下代碼:

file_get_contents("https://www.google.com/");

這代碼分分鐘被打，活生生將程序毀了。

如果發(fā)生超時(shí)，會(huì)占用大量 CPU，嚴(yán)重可能會(huì)導(dǎo)致服務(wù)無響應(yīng)，危害極大。

容錯(cuò)是每個(gè)開發(fā)者在開發(fā)過程中必須要考慮的地方，沒有代碼沒有 “八阿哥”，總會(huì)有意外的地方，做好容錯(cuò)可以最大程度地減少對(duì)用戶的傷害以及可以有效提高在出錯(cuò)時(shí)的用戶體驗(yàn)。百利而無一害。

日志，一個(gè)很容易被無視而又非常非常重要的環(huán)節(jié)，可以說，這一環(huán)節(jié)比你做的任何一個(gè)地方的業(yè)務(wù)代碼都要重要。

日志的好處:

記錄，跟蹤

調(diào)試

恢復(fù)

分析

調(diào)優(yōu)

等等...

好處有好多，但在我們開發(fā)者當(dāng)中，其日志最重要的功能之一就是，記錄問題，調(diào)試代碼，優(yōu)化架構(gòu)。

不得不說日志的重要性，請(qǐng)你好好重視這一個(gè)容易被忽略的環(huán)節(jié)。

而日志的設(shè)計(jì)需要考慮性能，不能因?yàn)槿罩径绊懛?wù)質(zhì)量哦。所以在日的環(huán)節(jié)在完整性和效率上要做好權(quán)衡。

緩存必須是針對(duì)業(yè)務(wù)情況而設(shè)計(jì)，不能生搬硬套。大公司的不一定適合你，開源方案也不一定不適合你，一定要找到自己合適的方案。

而在緩存設(shè)計(jì)方面，我個(gè)人推薦這一系列的文章: 緩存使用與設(shè)計(jì)

通俗簡(jiǎn)單地說，緩存的目的是為了提高服務(wù)的響應(yīng)速度以及質(zhì)量，不能因?yàn)榫彺娴奶砑佣鴮?dǎo)致服務(wù)異常。

我們平時(shí)開發(fā)接觸不同的開發(fā)工具，操作，甚至是監(jiān)控，那么他們其中的原理，你又理解么？

其實(shí)我們每天接觸的東西都有它的實(shí)現(xiàn)原理，算法等等的東西，但我們一直都在使用，并沒有很好地去理解他們當(dāng)中的奧秘。時(shí)候有空去接觸一下了。

首先，開發(fā)，編碼我覺得就是將現(xiàn)實(shí)生活搬到互聯(lián)網(wǎng)中，我舉個(gè)例子:

為什么人訪問量上來了，咱們就要擴(kuò)容，去擴(kuò)展呢？原理很簡(jiǎn)單，看看咱們超市里面的收銀臺(tái)就知道了。咱們超市里面所有收銀臺(tái)不是每天每個(gè)位置都有人的，根據(jù)人流(流量)動(dòng)態(tài)擴(kuò)容，而且有些收一臺(tái)的一個(gè)位置上設(shè)置有兩個(gè)人(多線程/多進(jìn)程，看個(gè)人理解)，這個(gè)設(shè)計(jì)挺妙的。當(dāng)人一多，就會(huì)開多各個(gè)位置收銀臺(tái)，和增加人手。那他是怎么知道人多的呢？也很簡(jiǎn)單，就是經(jīng)理(Manager/Master進(jìn)程或者是運(yùn)維，看理解)，他知道，內(nèi)部調(diào)度安排人手。

大致舉了這么一個(gè)例子來說明擴(kuò)展的原理。

回到正題: 框架

相信大家都有接觸過很多不同的框架，CI, TP, Symfony, Yii, Laravel, Slim等等，最深刻，最相似的地方在哪里呢？可能有些沒有，但是，有一點(diǎn)可以肯定的，就是，都是有一系列 Http 封裝，Route 處理。因?yàn)檫@兩是靈魂，剩下的是不是業(yè)務(wù)和結(jié)構(gòu)。

剩下的就是考驗(yàn)框架代碼質(zhì)量的時(shí)候了，這里有一系列的框架，有的輕量，有的重量，有的靈活，有的高效。其實(shí)說到這里很多朋友都大概了解框架的運(yùn)行原理。

我看過Symfony、Laravel、CI、Silex和ThinkPHP的代碼，當(dāng)然很粗略地看看。里面實(shí)現(xiàn)的大部分代碼都是將各個(gè)處理模塊 “粘合” 一起，也就是 "Bridge"。

大致流程圖:

   +----------+           +-------------+                      +------------+                          
   |          |           |             |                      |            |                          
   |  Client  |---------->| Application |--------------------->|   Start    |                          
   |          |           |             |                      |            |                          
   +----------+           +-------------+                      +------------+                          
         ^                                                            |                                
         |                                                            |                                
         |                                                            v                                
         |                         +-------------+             +-------------+                         
         |                         |             |             |             |                         
         |                         |  Container  |------------>|  Bootstrap  |-----+                   
         |                         |             |             |             |     |                   
         |                         +-------------+             +-------------+     |                   
         |                                ^                                        |     +------------+
         |                        +-------+--------+                               |     |            |
         |                        |                |                               +---->|  Request   |
         |                  +-----------+    +-----------+                               |            |
         |                  |           |    |           |                               +------------+
         |                  |   Route   |    |  Service  |                                      |      
         |                  |           |    |           |                                      |      
+----------------+          +-----------+    +-----------+       +-------------+                |      
|                |                                               |             |                |      
|    Response    |                                               | Dispatcher  |                |      
|                |<----------------------------------------------|             |<---------------+      
|                |                                               |             |                       
+----------------+                                               +-------------+                       
                                                                        ^                              
                                                                        |                              
                                                                        +--------------+               
                                                                        |              |               
                                                                        |              v               
                                                                        |        +----------+          
                                                                        |        |          |          
                                                                        +--------|Controller|          
                                                                                 |          |          
                                                                                 +----------+          

當(dāng)你了解了這些流程以及所需的組建，用先用的組件的話都是可以很方便地組合出自己想要的框架。

其實(shí)我這里希望更多的初學(xué)者多看看 ThinkPHP 的代碼，然后也看看其他開源框架的代碼，你會(huì)發(fā)現(xiàn)，除了 ThinkPHP 之外，你還可以發(fā)現(xiàn)更多新奇好玩的東西。

最終其實(shí)還是離不開自己動(dòng)手開發(fā)一個(gè)。

具體框架開發(fā)系列我會(huì)找個(gè)時(shí)間與大家分享。框架的理解可謂到一段落，下次我會(huì)分享我對(duì)其他服務(wù)器的理解。

來到這個(gè)階段的，應(yīng)該始終有一個(gè)意識(shí)：服務(wù)質(zhì)量高于一切，就是不能因?yàn)樘砑臃?wù)而影響原有的服務(wù)

簡(jiǎn)單總結(jié)一下。大量動(dòng)手實(shí)踐自己的猜想，分析自己做過的項(xiàng)目并且優(yōu)化自己覺得不足的地方。

總結(jié): 知其然并且知其所以然。

我相信經(jīng)過九九八十一難，能來到這個(gè)模式的人已經(jīng)不多了。我自己還是菜鳥，不敢在這里胡說，這里會(huì)記錄我所有的 PHP 底層學(xué)習(xí)的經(jīng)過，這里的故事，我想我等不到下一個(gè)故事了。

Unix 環(huán)境高級(jí)編程

tcp/ip 網(wǎng)絡(luò)編程

PHP 擴(kuò)展開發(fā)

頸椎病康復(fù)指南

活著

為什么要理解并學(xué)習(xí)這一方面的知識(shí)？若果你是一名有追求的 PHP 開發(fā)者，最終還是應(yīng)該將精力落入到 “系統(tǒng)” 處，因?yàn)檎嬲幚?PHP 程序的，正正是 “系統(tǒng)”，如何可以讓自己的 PHP 做得更好，如何可以讓自己的服務(wù)做的更好，如何可以讓后端支持更加強(qiáng)大，靈活，高效，你就應(yīng)該關(guān)注到底層系統(tǒng)的實(shí)現(xiàn)當(dāng)中，但平時(shí)也不要忘了 PHP 的開發(fā)規(guī)范。

此處的文章和筆記，我將會(huì)在以后的 Unix 學(xué)習(xí)一系列當(dāng)中給大家呈現(xiàn)。

在日常生活中，Http 已經(jīng)離不開大家了，從平時(shí)打開應(yīng)用，打開瀏覽器，搜索，都是需要使用 Http，應(yīng)該沒有比這個(gè)接觸更多了吧。但是里面的奧秘你又知道多少？沒關(guān)系，和我一起探索 TCP/IP 的奧秘吧。

文章和筆記，以后會(huì)在 TCP/IP 章節(jié)中給大家呈現(xiàn).

學(xué)習(xí)擴(kuò)展開發(fā)和學(xué)習(xí) PHP 是一樣一樣的，根據(jù) PHP 手冊(cè)上的流程...

語言參考

基本語法

類型

變量

常量

表達(dá)式

運(yùn)算符

流程控制

函數(shù)

類與對(duì)象

命名空間

Errors

異常處理

生成器

引用的解釋

預(yù)定義變量

預(yù)定義異常

預(yù)定義接口

上下文（Context）選項(xiàng)和參數(shù)

支持的協(xié)議和封裝協(xié)議

看到這里應(yīng)該要懂得舉一反三的了，后面的看你們的造化了......

此處的文章和筆記，我將會(huì)在以后的 PHP 擴(kuò)展開發(fā) 學(xué)習(xí)一系列當(dāng)中給大家呈現(xiàn)。

我目前已經(jīng)開始做了: http://blog.fastdlabs.com/tag...