提示：本文約三千字。
    經(jīng)過(guò)三個(gè)月時(shí)間，終于完成了我的第二個(gè)項(xiàng)目，先簡(jiǎn)要概括下，該項(xiàng)目是個(gè)“b2c”的商城，b2c 指唯品會(huì)、小米商城這種商家-客戶的模式，像京東、淘寶這種做平臺(tái)的叫 C2C（我猜這個(gè) 2 可能是取的 to 和 two 的諧音？），C2C 目前已被京東、淘寶、拼多多占據(jù)了絕大部分市場(chǎng)份額，所以做 C2C 意義不大，而且 C2C 的復(fù)雜度要遠(yuǎn)超 b2c，不適合我個(gè)人來(lái)做。項(xiàng)目的前端樣式主要仿照小米商城，當(dāng)然只是仿照了其樣式，內(nèi)部邏輯應(yīng)該是完全不同的，后臺(tái)管理系統(tǒng)的樣式很常見(jiàn)，主要參考了這個(gè)開(kāi)源項(xiàng)目：https://gitee.com/hnjihai/jshop_mall
    其實(shí)該項(xiàng)目做到一半時(shí)，我發(fā)現(xiàn)“商城”并不適合作為個(gè)人項(xiàng)目來(lái)開(kāi)發(fā)，因?yàn)樗暮诵氖巧唐?，而商品這個(gè)東西通常要包含很多素材，而收集這些素材是屬于程序之外的事情，弄這些素材真的很麻煩，我是從小米商城上扒的資源，再添加到我自己的數(shù)據(jù)庫(kù)中，過(guò)程花費(fèi)了我四五天時(shí)間，當(dāng)時(shí)我就想，如果是做個(gè)“論壇”就不會(huì)有這個(gè)麻煩。
   上次提到，寫(xiě)項(xiàng)目主要是難在設(shè)計(jì)“系統(tǒng)模型”這種宏觀層面上的東西，這次項(xiàng)目更加深了我的這個(gè)觀點(diǎn)。一般來(lái)說(shuō)，“系統(tǒng)模型”既要能靈活適應(yīng)“需求”的不斷變化，同時(shí)也要能很好的滿足當(dāng)前需求，光做到這點(diǎn)就很難，起碼對(duì)我來(lái)說(shuō)很難，比如這次我埋頭設(shè)計(jì)了十天的模型，到最后還是漏洞百出，別說(shuō)滿足變化的“需求”了，即使是當(dāng)前需求都滿足的很勉強(qiáng)，當(dāng)然很大程度上是因?yàn)槲以谶@方面本身就缺乏經(jīng)驗(yàn)，算上上次的新聞?wù)?，這也只是我第二次設(shè)計(jì)一個(gè)項(xiàng)目，而且這次的 b2c 商城在規(guī)模上要比上次的新聞?wù)痉撕脦妆?，?nèi)部邏輯也有很大不同，所以我確實(shí)是缺乏經(jīng)驗(yàn)。但就問(wèn)題本身來(lái)說(shuō)，我還是覺(jué)得相當(dāng)有難度，你得考慮的非常非常全面，稍不注意就會(huì)出現(xiàn)紕漏，要知道這個(gè)“考慮”是建立在你還沒(méi)做的基礎(chǔ)上的，你需要在沒(méi)做時(shí)就考慮到整個(gè)項(xiàng)目的方方面面、邊邊角角，即要想到“該有什么”，又要想到“該如何組合、協(xié)調(diào)”它們，還要想到“某個(gè)部位具體的技術(shù)細(xì)節(jié)”，甚至想到如果以后要加入一些東西，該在哪里預(yù)留位置？寫(xiě)項(xiàng)目就是要解決這個(gè)大而復(fù)雜的問(wèn)題，它的局部難度往往不高，甚至很簡(jiǎn)單，但是要想把它的整體做好，就很難，非常難。
    基于上次做項(xiàng)目的經(jīng)驗(yàn)，這次我是本著先設(shè)計(jì)，再實(shí)現(xiàn)的原則做的，其實(shí)想想寫(xiě)程序都是這么回事，把你腦海中想的東西用編程語(yǔ)言精確的表達(dá)出來(lái)，如果你腦海中沒(méi)東西，那自然也無(wú)從寫(xiě)起，或者寫(xiě)出來(lái)一坨屎。我首先花了十天時(shí)間進(jìn)行抽象層的設(shè)計(jì)，這十天也包括查相關(guān)信息，因?yàn)槲覄傞_(kāi)始對(duì)如何實(shí)現(xiàn)一個(gè)商城是一無(wú)所知的，甚至不知道 b2c 和 c2c 是啥，我設(shè)計(jì)抽象層的步驟主要分確定需求、設(shè)計(jì)業(yè)務(wù)流程、設(shè)計(jì)數(shù)據(jù)庫(kù)、設(shè)計(jì)權(quán)限系統(tǒng)這四步，具體過(guò)程的話，主要還是參照現(xiàn)有的商城，比如淘寶、小米商城這些，思考下我寫(xiě)的商城該有什么功能，這樣需求就確定下來(lái)了，接著業(yè)務(wù)邏輯也一樣，然后是數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)是個(gè)重頭戲，要思考該用什么樣的內(nèi)部邏輯來(lái)管理這些數(shù)據(jù)，怎樣設(shè)計(jì)才能更便于實(shí)現(xiàn)需求，這也是個(gè)很棘手的事情，我十天時(shí)間主要就花在設(shè)計(jì)它上了，那時(shí)候整天開(kāi)著 xmind 不停畫(huà)腦圖，不停的改來(lái)改去，最后實(shí)在改不動(dòng)了才慢慢確定下來(lái)。
    雖然這次項(xiàng)目我遵循了上次總結(jié)出的原則，先設(shè)計(jì)，再實(shí)現(xiàn)，實(shí)現(xiàn)時(shí)先做基本框架，然后層層遞進(jìn)，不過(guò)現(xiàn)在我覺(jué)得這樣也不對(duì)，因?yàn)檫@樣做時(shí)，前期設(shè)計(jì)時(shí)是完全依靠想象來(lái)進(jìn)行的，沒(méi)有先寫(xiě)哪怕一點(diǎn)代碼，這就造成很多局部的設(shè)計(jì)與實(shí)際情況很不貼切，甚至存在很多遺漏，導(dǎo)致在設(shè)計(jì)模型時(shí)不能充分考慮到需求的細(xì)節(jié)，比如這次項(xiàng)目中的首頁(yè)輪播圖、商品類展示推薦圖、展示到首頁(yè)的商品類，以及后來(lái)的優(yōu)惠券、退貨、售后等模塊，它們要么是沒(méi)有被集成到后臺(tái)管理界面上，要么是由于數(shù)據(jù)庫(kù)設(shè)計(jì)缺陷導(dǎo)致幾乎做不出來(lái)，沒(méi)集成到頁(yè)面上的就需要在源碼里臨時(shí)添加，很麻煩，而屬于數(shù)據(jù)庫(kù)缺陷的就只能砍掉，除非對(duì)整個(gè)項(xiàng)目進(jìn)行大規(guī)模改動(dòng)。經(jīng)過(guò)思考總結(jié)后，我發(fā)現(xiàn)讓前期設(shè)計(jì)與前端頁(yè)面編寫(xiě)同步進(jìn)行才是更好的選擇，因?yàn)橹痪帉?xiě)頁(yè)面模版并不需要多少數(shù)據(jù)支撐，想改也是很快的，而頁(yè)面模板卻能比較具體的反映出實(shí)際需求到底有哪些，這對(duì)前期設(shè)計(jì)的幫助我覺(jué)得是很大的，這點(diǎn)我這樣直接說(shuō)，沒(méi)做過(guò)項(xiàng)目的同學(xué)可能不是很好理解，這里我只能建議你先做一個(gè)項(xiàng)目感受一下。
    接下來(lái)是技術(shù)方面，項(xiàng)目應(yīng)用到的技術(shù)是 Sass、JQuery、ThinkPhp，起初我還打算用 Bootstrap，但正式開(kāi)工后我發(fā)現(xiàn)它非常難用，Bootstrap 會(huì)私自加很多全局樣式，導(dǎo)致樣式混亂，可以說(shuō)就是個(gè)攪屎棍，所以我便棄用了。項(xiàng)目生成視圖的方式主要仍然是字符串拼接，沒(méi)怎么用到 tp 的模板引擎，只是將頁(yè)面主體結(jié)構(gòu)用 tp 的模版引擎 fetch() 出來(lái)，之后再在前端發(fā) ajax 請(qǐng)求過(guò)來(lái)，后臺(tái)把頁(yè)面各個(gè)局部位置的 html 拼接后再發(fā)送過(guò)去。我不用模版引擎主要是因?yàn)橄埠脝?wèn)題，而且如今通過(guò)虛擬 DOM 在前端進(jìn)行渲染的方式已經(jīng)越來(lái)越流行了，虛擬 DOM 實(shí)現(xiàn)了徹底的前后端分離，所以我覺(jué)得自己沒(méi)有必要非去使用模板引擎，我在學(xué)習(xí)時(shí)也跳過(guò)了 tp5 的模板語(yǔ)法。代碼方面，秉承我的一貫作風(fēng)，整個(gè)項(xiàng)目沒(méi)有套用任何現(xiàn)成模版，前后端都是我自己一點(diǎn)點(diǎn)寫(xiě)出來(lái)的，引用的插件共兩個(gè)，一個(gè)美化滾動(dòng)條，另一個(gè)是 eCharts，剩下的大概有十幾個(gè)效果，以及常用函數(shù)都是我自己動(dòng)手封裝實(shí)現(xiàn)的，目前還沒(méi)整理，初步估計(jì)應(yīng)該能整理出個(gè)一千多行吧。
    代碼編寫(xiě)上，我踩了個(gè)比較大的坑，由于對(duì) MVC 不熟悉（畢竟用框架做項(xiàng)目我還是第一次），我對(duì)在什么情況下使用 model 沒(méi)什么概念，起初我一味的在控制器中使用 Db，因?yàn)橹岸际怯妹嫦蜻^(guò)程的方式寫(xiě)原生 php，業(yè)務(wù)邏輯都是直接調(diào) PDO 操作數(shù)據(jù)庫(kù)，所以即便學(xué)了 tp5，也只是知道有 model 這么個(gè)東西，但并不知道具體是在什么情況下去使用它，所以我起初寫(xiě)項(xiàng)目時(shí)一直在用 Db 類，然而寫(xiě)了大概半個(gè)月后我發(fā)現(xiàn)自己經(jīng)常要用到 cv 大法（復(fù)制粘貼），因?yàn)槲医?jīng)常需要在不同的控制器內(nèi)對(duì)同一數(shù)據(jù)表中取出的數(shù)據(jù)進(jìn)行相同的操作，我意識(shí)到這會(huì)造成大量的代碼冗余，代碼冗余的缺點(diǎn)顯而易見(jiàn) —— 維護(hù)性差、可讀性差、難以迭代，要解決這個(gè)問(wèn)題，只有多進(jìn)行一些封裝，但用函數(shù)封裝顯然不是個(gè)好辦法，不同數(shù)據(jù)表進(jìn)行操作時(shí)的邏輯不同，如果為每個(gè)數(shù)據(jù)表的每個(gè)操作都單獨(dú)封裝個(gè)函數(shù)，光函數(shù)命名都?jí)蛭翌^疼的了。那怎樣才能基于數(shù)據(jù)表、具有封裝性，又不用頭疼命名呢？可以說(shuō)答案已經(jīng)呼之欲出了，當(dāng)然是使用 model，你可以為每個(gè)你經(jīng)常要操作的數(shù)據(jù)表單獨(dú)封裝一個(gè) model，需要時(shí)直接調(diào)用數(shù)據(jù)表所對(duì)應(yīng)的 model 的對(duì)應(yīng)操作即可，非常方便。
再說(shuō)說(shuō)我在前后端交互方面總結(jié)的經(jīng)驗(yàn)，前端給后端傳數(shù)據(jù)分為四種情況，如果數(shù)據(jù)量很小且不敏感，比如就一兩個(gè)字段，而且字段的值也很簡(jiǎn)單，那就直接用 get 傳輸，如果字段比較多，數(shù)據(jù)量比較復(fù)雜或敏感，那就用 post 傳輸，如果需要在傳輸時(shí)維持?jǐn)?shù)據(jù)的結(jié)構(gòu)不變，比如你傳個(gè)對(duì)象或多維數(shù)組給后端，那就把數(shù)據(jù)轉(zhuǎn)換為 json 格式再傳輸，另外，如果需要通過(guò) ajax 發(fā)送文件給后臺(tái)，就需要使用 FormData 對(duì)象。它的用法很簡(jiǎn)單，直接將 form 節(jié)點(diǎn)傳遞給 FormData()，再用 xhr（我用 jq 封裝過(guò)的 ajax 會(huì)報(bào)錯(cuò)，所以只好換原生的 xhr 了） 的 send() 發(fā)送即可，如果還需要添加其它值，可以用 FormData.append() 為 formdata 對(duì)象添加 key/value。
最后，記幾個(gè)遇到的小坑：
1、form 內(nèi)的控件的 name 不能為 style，否則 form 本身的 style 屬性會(huì)被覆蓋，導(dǎo)致你無(wú)法通過(guò) style 屬性更改 form 的標(biāo)簽內(nèi)嵌 css，進(jìn)而也會(huì)導(dǎo)致 jq 的 css() 方法失效。


2、mysql 建表時(shí)字段名不能為 key，否則會(huì)報(bào)語(yǔ)法錯(cuò)誤。


3、thinkphp 5.0 內(nèi)控制器的方法名不能為 result，否則會(huì)報(bào)錯(cuò)。


4、json 不支持關(guān)聯(lián)數(shù)組，json 只支持簡(jiǎn)單值、對(duì)象、以數(shù)字為下標(biāo)的數(shù)組，所以 php 的關(guān)聯(lián)數(shù)組不能直接轉(zhuǎn)為 json 格式的字符串。


5、與路徑相關(guān)的東西千萬(wàn)不要加中文字符，比如文件，這次我就遇到 php 的 move_uploaded_file() 不支持中文路徑。