偶然和一位資深的朋友聊起一些有關(guān)程序員如何學(xué)習(xí)的話題, 想想也許我們所思考的問題, 也許正好是很多想做程序或想學(xué)程序的人的迷霧, 于是順手就把它寫下來, 期望能夠給正準(zhǔn)備走上程序之路或已經(jīng)在這路上的朋友些許的啟發(fā).文章頗長, 本人一個字一個字碼出來的, 如果您有耐心全部讀完, 希望會對您用.

本文以下所指的程序員, 都是基于BS開發(fā)的web程序員, CS俺不熟^_^

1.整體的學(xué)習(xí)思維

學(xué)習(xí)的思維大致分成兩種, 一種是理科方式的步步為營, 一種是文科方式的高屋建瓴. 這么說起來好像不夠形象, 其實(shí)就像挖一口池塘, 理科學(xué)習(xí)推崇挖一節(jié)推進(jìn)一節(jié)的方式往前挖, 每一節(jié)都是從上挖到底,一節(jié)一節(jié)步步為營, 而文科方式是從整體面上挖一遍, 再整體挖一遍, 一層一層的從上往下挖.

那么問題是, 編程究竟是屬于理科還是文科? 這好像是個不用討論的問題, 當(dāng)然理科嘛.但是,從編程學(xué)習(xí)的知識體系來看, 編程卻未必全如理科般一節(jié)鎖一節(jié), 有時候卻更像是文科的寫文章.這就有了兩種方式的討論, 究竟學(xué)一門編程語言, 是按照縱向一節(jié)一節(jié)推, 還是按照橫向一遍一遍學(xué)?其實(shí), 在我看來, 這里有個區(qū)分:

1.1基礎(chǔ)知識學(xué)習(xí)

從編程語言學(xué)習(xí)的角度來說, 應(yīng)該是按理科學(xué)習(xí)的方式一節(jié)一節(jié)往前推的方式好. 因?yàn)? 這些基礎(chǔ)的理論知識都是環(huán)環(huán)相扣, 而且每個基礎(chǔ)概念理解起來都相對比較簡單, 都是寫固定的思維方式和算法代碼, 但是這之前的每一個簡單的基礎(chǔ)知識都會是后面需要的知識基石, 一步是夾生飯, 后面都都是夾生飯, 再回頭來折騰就費(fèi)事了. 所以, 這需要每一步理解透, 這樣雖然開始慢, 但是隨著基礎(chǔ)概念的牢固掌握, 后面會越來越快.

1.2框架學(xué)習(xí)

當(dāng)基礎(chǔ)知識告一段落的時候, 往往大多數(shù)人是直接往框架學(xué)習(xí)上走, 框架之本質(zhì)其實(shí)就是一個工具, 那么這個工具用整體的方式來學(xué)習(xí), 效果會更好. 為什么這么說呢, 因?yàn)槊恳粋€框架都會采用大量的設(shè)計模式, 如果脫離開框架來專門精研設(shè)計模式, 會發(fā)現(xiàn)學(xué)會了模式基礎(chǔ)還是看不懂框架原理, 而一節(jié)一節(jié)的讀, 太容易被那些抽象但是不影響工具使用的概念困擾住. 但是如果是整體的看一遍框架指南, 對這些模式比如依賴注入, 觀察者模式等等的用法會有直觀的感性認(rèn)識, 雖然還很模糊, 沒關(guān)系, 先拿著手冊整體依樣畫葫蘆的做一遍,看不懂就跳過去,整體看一遍就大致理解一些, 整體的多看幾遍, 等對基礎(chǔ)用法都很熟練了, 再專門來理解核心概念就不那么費(fèi)勁了.

而框架本身是工具, 對于學(xué)習(xí)工具而言, 實(shí)際的操作就很重要, 因此, 如果沒學(xué)過框架, 可以先簡單的整體了解一個框架的手冊內(nèi)容, 至少粗讀一遍, 讀不懂就找個視頻講解來看一遍整體的用法, 有了整體的了解后, 拿來嘗試按手冊示例代碼做一兩個小項目, 而后, 再回頭整體的看一遍, 總結(jié)出框架的核心知識點(diǎn), 再做以兩個項目, 這樣整體式的一遍一遍學(xué)習(xí), 每學(xué)一遍就會深入一點(diǎn), 做幾個項目, 一個框架的知識就了然于胸了.然有有多余的精力, 再去深入源碼級別, 當(dāng)然, 這個因人而異, 如果你壓根就不想看源碼, 當(dāng)熟練了用法, 那些設(shè)計模式的核心用法和觀念也就有了, 應(yīng)該說, 研究或者不研究源碼, 都不會影響你對某個框架的理解和應(yīng)用了.?

2.程序員學(xué)習(xí)的基本理念

2.1 理解和記憶

沒一種編程語言都會有大量的內(nèi)置函數(shù)或內(nèi)置類, 因此, 記憶這些內(nèi)置功能就顯的很重要, 這跟學(xué)英語背單詞是一個道理, 學(xué)程序不背一些函數(shù)或類的用法, 那么寫起代碼就會感慨書到用時方恨少.?拿電腦來打個比方, 外部你還沒記憶的知識, 當(dāng)作是存放在硬盤上的數(shù)據(jù), 你已經(jīng)記憶下來的知識, 是在內(nèi)存中的數(shù)據(jù),??假如你寫程序的時候總是靠翻手冊或查百度來拼湊代碼, 就好比每一次程序調(diào)用伴隨著大量的IO操作, 時間耽誤在查資料上, 而大腦中真正的邏輯功能還是空閑的, 這樣的開發(fā)效率是很低的.?

但是那么多的函數(shù)名和類名, 而且都是英文額...如果靠強(qiáng)制性的死記硬背, 那真是很讓人頭疼的一件事, 因此, 掌握一套有效的記憶策略就顯得很重要, 其實(shí)記憶策略本身并不是很懸的技術(shù), 只要找對一種方法, 進(jìn)行合理的訓(xùn)練, 就有能力達(dá)到一定的記憶效率.

目前市面上流行的記憶術(shù)最多的也就三大類, 邏輯記憶, 圖像記憶和聲音記憶, 再加一個思維導(dǎo)圖學(xué)習(xí)法.對于程序員這樣需要專門記憶很多名詞的人來說, 花時間訓(xùn)練一套記憶法, 絕對是非常必要的. 而記憶法本身是可以訓(xùn)練的, 這是很正常的事情. 市面上能找到有關(guān)記憶的培訓(xùn)視頻都是在強(qiáng)調(diào)圖像記憶, 但是我強(qiáng)烈不推薦,?這里面有太多市場化的吹噓成分, 因?yàn)樽龀绦騿T的都知道, 計算機(jī)處理圖片和聲音以及影像信息的速度, 遠(yuǎn)遠(yuǎn)沒有處理文字信息來的快, 我相信大腦也是, 圖像能夠很快速的反映, 但是記憶諸如手冊方法這樣的大量信息, 花花綠綠的圖片會讓大腦奔潰. 個人覺得比較合適的記憶方式是邏輯記憶法, 臺灣有一位陳光老師專門研究邏輯記憶法, 還寫了一本書叫<吸英大法>, 里面有一套很有效的邏輯記憶方法, 記憶單詞很管用, 記憶內(nèi)置函數(shù)和內(nèi)置類也很有效果.(里面也說明了, 成人在6歲以后, 圖像記憶能力已經(jīng)衰退, 而讓成人用圖像記憶法, 實(shí)際是一種開倒車的行為, 具體如果您有興趣, 可以把這本電子書找來看看).

當(dāng)然, 有句話叫理解的越多, 需要記憶的越少. 記憶是學(xué)習(xí)編程不可缺少的一環(huán), 但是理解每個記憶的概念更為重要, 因?yàn)楹瘮?shù)名或類名可能換一套語言就變了, 但是這其中的邏輯觀念是不會變的, 正如你要截取文字, 可能每套語言的函數(shù)名不同, 但是基本的邏輯都大差不差的就那么回事.其實(shí), 理解的越多, 能記下的就會越多, 同時, 如果你沒理解, 只是先記下了, 那么當(dāng)拿來用的時候, 同樣理解的也會越快.這是一個輔助學(xué)習(xí)的兩個互補(bǔ)工具, 有時候不理解, 記下來就理解了.

2.2 清晰的知識分類

我不會很推崇思維導(dǎo)圖能干什么, 但是拿思維導(dǎo)圖來做思維整理確實(shí)蠻好用. 編程的知識很雜, 而且體系很龐大, 因此清晰的知識分類會顯得很重要, 當(dāng)然, 我不是很建議一開始就來做知識分類, 因?yàn)槲覀€人試過一開始就分類提取一些核心知識, 但是整體的核心知識看完之后, 跟沒學(xué)過一樣, 所有的細(xì)節(jié)都漏了, 開發(fā)的時候還是需要一遍又一遍的翻手冊. 知識分類應(yīng)該是基于對整個知識的熟練掌握之后. 舉個學(xué)習(xí)框架laravel的例子, 假如一開始學(xué)就拿個導(dǎo)圖軟件來畫畫圖圖, 然后畫完的時候感覺很有整體的感覺, 到要拿來用的時候, 還是一腦袋空白, 實(shí)際上什么也沒記住. 而如果對框架知識本身有一定的操作體驗(yàn), 本身的知識細(xì)節(jié)比較清楚的情況下, 歸納和提煉知識會讓記憶量大幅度降低. 比如學(xué)laravel的ORM,一對一,一對多, 多對多, 多態(tài)關(guān)聯(lián), 如果之前都操作的熟練了, 那么幾個類方法一抽出來畫在導(dǎo)圖上, 那一大篇的ORM知識就都記住了.

其實(shí)清晰知識分類的另外一個好處就是, 學(xué)習(xí)的信心會有很大的提升, 假如學(xué)完一個體系的知識, 沒歸納整理之前, 似乎總是感覺盲人摸象, 但是整體整理一遍, 整個知識架構(gòu)會都串起來, 對知識感知的信心就會一下子踏實(shí)起來.

2.3 編程的實(shí)際操作

編程本身是跟實(shí)際操作相關(guān)的學(xué)科, 拋開前面說的理論記憶層面, 也就是說每一個知識點(diǎn), 最終的實(shí)際效果都是能跑在計算機(jī)上得出一個結(jié)果, 因此, 實(shí)際操作就非常重要. 對于編程操作而言, 其核心依舊是一門匠藝, 在實(shí)際操作的訓(xùn)練上, 跟學(xué)書法學(xué)木匠, 本質(zhì)上沒有太大的區(qū)別.

理論上的東西需要取理解和記憶, 操作上的東西就是訓(xùn)練而已.

老祖宗教我們學(xué)書法的時候, 無非是三步走, 臨帖, 背貼, 脫貼. 而程序的操作也是一樣, 一段代碼拿過來, 什么都看不懂, 沒關(guān)系, 找一個編輯器抄一遍總會, 簡單邏輯的代碼在操作的時候抄一遍, 放到解釋器或編譯器上面跑一遍, 結(jié)果出來后說不定就看懂了,? 還沒看懂, 再抄一遍, 原先不理解的, 下一遍就理解了, 就這么回事.一個需求出來不知道怎么想流程, 先stackoverflow上查查看, 有沒有人家寫好的, 拿回來依樣畫葫蘆臨摹就好了, 等臨摹到一定的代碼量, 也就把一些基本的邏輯代碼背下來了, 邏輯過程代碼背的多了, 基本功就扎實(shí)了, 創(chuàng)作就不再是問題.

2.4 框架的實(shí)際操作

現(xiàn)在的項目開發(fā)大多是用框架搭積木, 一塊一塊的填空. 框架的本身理念上的知識, 您可以參照前面的學(xué)習(xí), 框架的實(shí)際操作, 實(shí)際上可以把它當(dāng)作一個軟件, 也就是說, 學(xué)一套框架的操作, 本質(zhì)上跟學(xué)Excel沒有太大的區(qū)別. 也就是一個用代碼來操作數(shù)據(jù)相關(guān)的邏輯, 一個用鼠標(biāo)點(diǎn)一點(diǎn)就可以出數(shù)據(jù)結(jié)果的差別;一個前面有前端,后面有數(shù)據(jù)庫, 是為了實(shí)現(xiàn)業(yè)務(wù)邏輯; 一個是界面和數(shù)據(jù)都綁在一起操作而已, 是為了實(shí)現(xiàn)數(shù)據(jù)操作.?

那么學(xué)Excel操作的時候, 很多人都不會是找書本來慢慢一點(diǎn)一點(diǎn)啃出來才能做表格的吧? 大多數(shù)是打開軟件界面, 每個按鈕點(diǎn)一遍過去看效果怎么樣, 不懂再百度問問看, 再實(shí)際操作兩張表, 再不懂翻翻手冊, 那么基礎(chǔ)的操作就這么熟練了, 遇到數(shù)據(jù)高級查詢這些高級應(yīng)用, 再去翻看手冊或是查資料問別人, 掌握原理再操作, 用的熟了, 就是Excel高手了, 而實(shí)際上, 學(xué)會操作Excel的20%就可以完成這個軟件80%的操作, 要再花80%的時間去研究VBA, 那是為Excel20%的應(yīng)用去學(xué)習(xí), 要不要學(xué)?要用到再說^_^

框架操作也可以是這樣, Excel有界面, 框架有手冊嘛, 每本手冊的描述一般都是權(quán)威且清晰的, 對著手冊做, 好比點(diǎn)按鈕. 有些要花80%的時間才能弄懂的(比如翻源碼), 先別去管, 因?yàn)閺膽?yīng)用的角度看, 你可能一輩子都不需要去了解一套框架后面的源碼, 假如真的到要翻源碼的應(yīng)用, 那也可以考慮換一個框架.就像Excel的vba, 我要用到vba的時候, 就直接換Access了, 誰有那么多時間去研究個Excel的編程.

3 .學(xué)習(xí)歷程

一個程序員的學(xué)習(xí)歷程, 大致分為以下三個階段:

3.1 看山是山

這個時候的學(xué)習(xí), 就是針對原生語法上的學(xué)習(xí), 對核心概念再數(shù)據(jù)操作結(jié)果上的理解, 這個階段的理解就是編程就是一門編程語言, 學(xué)C就拿C的if...else..., 用一些prinf寫一些邏輯代碼, 學(xué)python就是python的基礎(chǔ)代碼操作, 能夠?qū)懸粌蓚€小應(yīng)用, 學(xué)PHP能夠做一兩個小網(wǎng)站, 這個時候的概念就是這個語言這樣做可以作出這個東西, 任何東西一拿過來就是先想代碼怎么敲, 函數(shù)用什么, 類庫用哪個......這個階段講究代碼的個性化, 講究思維的抽象化, 也就是我能夠用更精巧的代碼邏輯, 我就更厲害, 以及動不動的設(shè)計模式, 也就是說, 在這個階段就是代碼層面的代碼, 沒別的.

在這個階段其實(shí)是很難對底層的實(shí)現(xiàn)原理有深刻的認(rèn)識的, 即使認(rèn)識, 也僅是在某些教科書的描述性的理解. 但是值的一提的是, 現(xiàn)在有些的企業(yè)面試卻頗為無聊, 企業(yè)面試一般會出一些很艱深的原理性和底層性的知識, 來考一些面試基礎(chǔ)崗位的程序員, 而實(shí)際上要對那些面試的知識真的認(rèn)識的很深刻, 那他真的不需要靠面試找工作. 這挺諷刺, 但是現(xiàn)實(shí)就是這樣, 所以就會有很多的培訓(xùn)機(jī)構(gòu)專門應(yīng)對這些面試考試題目做一些強(qiáng)化, 盡管這個時候, 能答對題目, 不代表程序員的層次就上去了, 只是這些題目會做對. 當(dāng)然, 這也無可厚非, 每個人都要謀口飯吃嘛.

3.2 看山不是山

當(dāng)學(xué)完基礎(chǔ)知識的應(yīng)用之后, 大多數(shù)程序員都開始了框架生涯, 后端的要搭個界面, bootstrap就來了, 要做個前端SPA應(yīng)用, vue或react就來了,高大上一些的, angular就湊上去了, 后端TP, laravel, django, spring, 爬蟲的Scrapy, 各種各樣五花八門的框架搭建應(yīng)用, 這個時候, 語言的隔閡就很小了, 比如angular是用typescript寫的, 但是就是只會javascript的程序員, 稍稍翻一翻ts的文檔, 套著框架開發(fā)也沒問題, 我做PHP的, 稍稍翻下python的基礎(chǔ)語法, 也能用django寫項目, 我做python的, 看了下php寫爬蟲也沒問題, 好像基礎(chǔ)編程語言的隔閡越來越小, 也就是語言本身的特性幾乎都轉(zhuǎn)化為了設(shè)計模式層面的思維, 好像說,基礎(chǔ)語言我只要看懂語法就可以了, 其他的都是框架層面的概念, 前端不管是react還是angular, 反正語法都差不多, 也都有rxjs的東西, 那么就是玩大而泛之的概念, 開始充斥各種模式的概念:單例,觀察者,裝飾器,依賴注入, 控制反轉(zhuǎn).......

在這個階段, 好像采用的編程語言是什么壓根就不是太所謂, 重要的是框架要好用, 好用就叫他優(yōu)雅, 不好用就是坑, 而采用這些框架的終極目的, 就是快速搭建應(yīng)用, 來項目了, 來單子了, 拿個框架, 快速上手, 配上數(shù)據(jù)庫, 配上CURD的業(yè)務(wù)邏輯, 一個項目快速上線, 中大型項目用中大型適應(yīng)的好修改好維護(hù)框架, 小型項目用高性能框架.......一切皆框架, 剩下的, github上找車輪, 要驗(yàn)證碼的, 有! kaptcha, 要全文索引, 有! Elasticsearch, 在框架的前提下, 綁上一堆車輪子, 然后項目就快速上線跑起來了.

這好像也沒什么, 也是大多數(shù)程序員的宿命, 或者說是大多數(shù)程序員的技術(shù)終點(diǎn)(因?yàn)樾枰偻伦? 要么不寫程序了, 要么就寫特高級沒市場的程序了, 總之再下去是大多數(shù)程序員不會走的路). 寫程序就是謀條活路, 有人付錢的程序才是好程序, 其他的, 我們大多數(shù)人管不了那么多.應(yīng)該說,? 有了這個層面的最大量的群體, 才會有各式各樣配合這個群體的構(gòu)建工具出現(xiàn),都是幾個命令快速搭建, 因?yàn)槿后w最多, 所以討論的也最多, 同時, 這個層面也最復(fù)雜, 各式各樣的工具讓人暈頭轉(zhuǎn)向, 各式各樣高達(dá)上的名詞讓人摸不到邊, 猿生如此..........^_^

3.3 看山還是山

當(dāng)然, 還是有人走"少有人走的路",??這里的少有人, 不是程序員轉(zhuǎn)管理的高級, 而是真正技術(shù)上的高級. 依然有人會抵達(dá)程序員成佛作祖的境界, 這個階段我不太敢多寫, 因?yàn)? 我達(dá)不到. 所以, 這一小段, 是見過豬跑卻沒吃過豬肉的人寫的關(guān)于豬的傳說, 未必正確, 您蠻看看就好.

其實(shí), 當(dāng)把一兩套框架玩到出神入化的境界, 就會回歸到原生層面去看底層的代碼, 會去深入的研究底層的邏輯, 會仔細(xì)去比較沒種數(shù)據(jù)庫查詢的性能差距,? 一路追到框架的原生設(shè)計, 或是SQL, 甚至是解釋器, 這是進(jìn)入看山還是山的必經(jīng)之路.?

而在這個境界里, 會更重要的回歸到語言本質(zhì)上面, 當(dāng)然, 什么編程語言會不會用已經(jīng)不是問題, 那關(guān)鍵的考量是為什么要用這個語言, 這個語言的這些特性在將來會出現(xiàn)什么問題, 比如angular1.0和2.0, 用js和ts的考量, 用什么場景可以用什么模式, 性能追求還是效率追求....等等等等, 而這個境界上, 其實(shí)還是一門編程語言本身的特性, 繞老繞去, 繞不過動態(tài)類型?靜態(tài)類型? 接口? 線程? 進(jìn)程? 弱類型強(qiáng)類型? 而真正精道的, 也還是回歸到語言本身的實(shí)現(xiàn)原理上.

當(dāng)然, 這個境界所專注的, 已經(jīng)不是在于一門語言的howTo, 而是why! 就是很多面試題里的概念, 當(dāng)然, 是這些考題背后真正的運(yùn)作機(jī)理以及這些機(jī)理會產(chǎn)生的影響了.

4.關(guān)于web的一些框架的題外話

4.1 前端框架

傳統(tǒng)的基礎(chǔ)HTML+JS+CSS咱就不說了, 說點(diǎn)看山不是山的吧...

Bootstrap不用說, 幾乎是每個前端人員的入門ABC, 但是我說的是, 如果一個后端要用Bootstrap, 好歹先了稍微學(xué)下less嘛, 雖然懶得看整個bootstrap的源代碼, 好歹把variables.less的變量用法看一遍, 再按照BS首頁的入門提示自己編譯一下源碼, 這樣也不至于一個BS界面寫出來, 怎么看就怎么像BS.

jQuery有即將被angular還是react的哪個SPA框架KO的傳說, 不過傳說終歸是傳說, Angular6要入門前的一堆肥肥的概念就會把很多人擋在門外, react就更不用說, 加上rxjs那些異步概念, jQuery看看揚(yáng)言要替換它的對手笑笑說, "還早", 所以,沒別的說的, 這還是值的學(xué)的,而且很多場合, 用它最方便.

然后就是前端的三個典型了, vue, react, angular, 當(dāng)然, 學(xué)會其中一套, 另外兩個也就容易學(xué), 其實(shí)玩到項目層面上, 都差不多.其實(shí)前端框架, 無非就是把后端框架的模板處理和路由功能拿過來強(qiáng)化一番而已, 單純web而言, 我個人并沒有覺得有很多優(yōu)勢, 但是手機(jī)端的混合式開發(fā), 這些框架就好用的多.?

vue文檔的開發(fā)者比較聰明, 它的文檔比較容易帶你入坑(前端框架,一入前端深似坑啊), vue文檔怕嚇壞我們這些沒膽的寶寶, 特意把構(gòu)建工具這些放到最后面, 先用熟悉的jQuery方式把人"拐賣"進(jìn)入它的圈子, 然后, 告訴你小寶寶別怕, 我很簡單易學(xué)好用, 但是到組件化應(yīng)用的時候, 整體難度上其實(shí)和另外兩個差距不大,沒辦法, 它要完成這些事, 要做成一個前端框架, 路由, 服務(wù)器通信,組件間通信這些技術(shù)它一個也沒法更簡單, 做SPA就是這樣的嘛, 能開發(fā)這些框架的人都是人精, 它沒理由在同等功能上做的更簡單, 不過vue的文檔對入門更友好一些, 它的文檔也是"漸進(jìn)式"文檔.?

angula6呢, 由于采用的是typescript, 大多數(shù)人沒學(xué)過, 得重新學(xué)了. 當(dāng)然有些ES6的基礎(chǔ)的話,更容易理解, 其實(shí)無論是ES6,還是typescript,或是python,甚至最新的java11, 感覺都在向統(tǒng)一方向進(jìn)化, 語言特性也越來趨于相似.所以學(xué)新的ts倒也還不是事兒,關(guān)鍵是angular6自身框架設(shè)計中的核心概念, 依賴注入,控制反轉(zhuǎn), 組件編程等等概念學(xué)起來還是有一定難度的, 操作也挺繁瑣的. 我個人覺得, angular6最大的問題還是輪子太少, 每個組件都得自己編樣式, 都得自己寫邏輯, 別人寫好可用的東東不多, 比如我要做個后臺, github上的adminlte拿過來隨便改改我就用了, 用angular一個個重寫, 寫到哪年去.那除非說我后臺用API框架或者用框架提供API,數(shù)據(jù)都給前端處理, 這還是值的考慮的, 畢竟要是用jQuery操作DOM再加上數(shù)據(jù), 那得搞死人.

react沒用過, 正打算學(xué), 有學(xué)過的朋友歡迎留言討論下.

當(dāng)然, 前端這些框架, 就少不了幾個構(gòu)建工具了, gulp, webpack, 哦,還不能少了NPM這個前端的革命性命令行工具,網(wǎng)上這些工具的視頻教程一抓一大把, 我就不一一贅述了.

4.2后端框架

后端框架典型的, python系列的django, PHP系列的laravel, thinkPHP和phalcon, java和.net的我不熟悉,就不說了, 說點(diǎn)我熟悉的.

其實(shí)一套后端框架所要做的事情也基本類似, 處理路由, 數(shù)據(jù), 視圖, 但是在框架的易用性上考量, laravel應(yīng)該是這些后端web框架的佼佼者(github的星星數(shù)量可見一斑),django好用的地方是它自帶了一個通用性很高的后臺管理系統(tǒng), 在這個基礎(chǔ)上, 做后臺可以免去不少工作, 但是路由傳參的時候還是依賴于ORM找到的id, 不如laravel的模型綁定來的方便, 至于其他方面, 其實(shí)每個框架都差不多, 只是我一般用python來寫爬蟲和做服務(wù)器腳本, 不太喜歡用python的web框架,? phalcon的好處是原理性的文檔非常全面, 最新的phalcon7在易用性上有很大的提升, thinkPHP除了文檔注釋是中文的, 好像沒有找到可圈可點(diǎn)的地方.這些框架綜合考量的話, 我個人比較推崇laravel, 它的ORM,路由處理,模板處理,驗(yàn)證機(jī)制以及第三方可引用的庫之間的銜接都做的非常到位,只要按照手冊的規(guī)則, 目前沒有發(fā)現(xiàn)有什么坑, 代碼比較人性化, 不過如果要從性能上考量的話, phalcon不可多得, 因?yàn)檫@個框架單純用C寫, 所以概念的描述會非常到位, 文檔很不錯.

當(dāng)然, 說道這些框架, php的構(gòu)建工具composer不得不提一下, 其實(shí)也沒啥提的, 反正我常用的composer命令不會超過5個, 自己看手冊咯.............

5.最后

最后不得不說, 寫的很晚了,困了,想睡覺^_^............

其實(shí)本文的焦點(diǎn)應(yīng)該在如何學(xué)習(xí)上再深入一些, 只是寫著寫著, 好像有點(diǎn)跑題, 扯一些題外話, 只是自己使用一些框架的觀點(diǎn), 未必完全正確, 您姑且讀之, 也歡迎您指正.