三思而后行

　　當(dāng)你被自己的想法激起心中豪情的時(shí)候，一定要按下心情，冷靜的思考一下，思考點(diǎn)包括以下幾個(gè)部分：

　　這個(gè)Web項(xiàng)目所需要的知識(shí)和能力是否在自己所掌握的范圍內(nèi)，這個(gè)是技術(shù)前提，如果項(xiàng)目本身技術(shù)復(fù)雜度過(guò)高，那么你在開(kāi)發(fā)的時(shí)候所面對(duì)的壓力就非常大，而且挫敗感也很高，項(xiàng)目很容易夭折。

　　項(xiàng)目的需求能否清晰描繪，這一點(diǎn)非常重要，因?yàn)橹挥心隳芗?xì)致的把一個(gè)項(xiàng)目拆分成一條條需求，你才能對(duì)所有的技術(shù)實(shí)現(xiàn)點(diǎn)有個(gè)預(yù)估，也才能對(duì)項(xiàng)目所需要的時(shí)間做個(gè)預(yù)判。

　　項(xiàng)目是否值得做，這個(gè)是個(gè)預(yù)防針，實(shí)際上很多時(shí)候個(gè)人項(xiàng)目都是拍腦袋想出來(lái)的，由于剛開(kāi)始沒(méi)有想好就一腔熱血，一上來(lái)就開(kāi)個(gè)項(xiàng)目工程文件開(kāi)始啪啪啪的寫代碼，很容易做著做著就沒(méi)有動(dòng)力了，最后有一天突然覺(jué)得這玩意也沒(méi)啥意思，于是草草的扔了，虎頭蛇尾的情況太常見(jiàn)了。

　　技術(shù)選型怎么做，是做一個(gè)網(wǎng)站還是做一款app或者是多平臺(tái)的，后端用什么語(yǔ)言來(lái)搭建，需要使用什么框架，這些選型需要在心中有底，我建議做項(xiàng)目的時(shí)候選用自己最熟悉、生態(tài)最豐富的語(yǔ)言和框架，除非你只想練個(gè)手，否則不應(yīng)當(dāng)用冷門的。

　　所以項(xiàng)目未動(dòng)，思考先行是必須的，通過(guò)仔細(xì)的思考我們可以判斷自己所謂的“靈感”是不是偽靈感，而自己又能否適應(yīng)開(kāi)發(fā)期的單調(diào)枯燥，這些需要慎重對(duì)待，不能掉以輕心。

　　產(chǎn)品需求清單

　　經(jīng)過(guò)仔細(xì)的思考之后，依舊覺(jué)得項(xiàng)目可行的話，那么就應(yīng)該進(jìn)入“產(chǎn)品經(jīng)理”的角色，作為一個(gè)人的項(xiàng)目，產(chǎn)品需求倒未必只能是一個(gè)人思考，也可以找朋友等人探討，征求一下別人的想法之類的。

　　產(chǎn)品需求需要確保每一步都能執(zhí)行，所以理論上越詳細(xì)越好，在你思索產(chǎn)品的時(shí)候，你應(yīng)該對(duì)界面上所需要的具體元素有清晰的認(rèn)知，而且還對(duì)它牽扯到后端的功能如何組織和拆分。

　　在產(chǎn)品需求階段，也是你把項(xiàng)目原型豐富的階段，這個(gè)時(shí)候其實(shí)至關(guān)重要，很多時(shí)候你會(huì)發(fā)現(xiàn)你真正想要的和你原本打算要的已經(jīng)完全不同了，最開(kāi)始的打算可能根本行不通，同時(shí)你也有可能蹦出新的靈感，這些又會(huì)對(duì)原有的產(chǎn)品需求做或大或小的更改，說(shuō)不定還會(huì)推翻原有的需求。

　　基本上到這個(gè)時(shí)候，原本的激情已經(jīng)逐漸平淡，理智重新歸位，但對(duì)產(chǎn)品未來(lái)的期待感還是很強(qiáng)，這時(shí)候你需要考慮的情況實(shí)際上是非常多的，也是你容易失眠的階段，所以應(yīng)當(dāng)好好調(diào)整心態(tài)。

　　做產(chǎn)品需求的時(shí)候，你可能需要幾個(gè)流程圖，依賴圖這些對(duì)功能的劃分，多使用腦圖軟件來(lái)構(gòu)思自己的產(chǎn)品，也嘗試思考流程是否能簡(jiǎn)化，站在用戶的角度下使用是否方便，哪些功能是主要的，哪些是次要的。

　　如果覺(jué)得文字描繪不清晰的話，你也可以自己做幾張?jiān)蛨D出來(lái)，注意這不是高保真圖，只是讓你自己弄明白這個(gè)產(chǎn)品的某一頁(yè)或者某一塊，不應(yīng)當(dāng)把心力花在細(xì)節(jié)上。

　　總之在這個(gè)階段，應(yīng)該有大局感，而且也應(yīng)當(dāng)仔細(xì)打磨自己的想法，如此三番之后要給自己定下個(gè)初稿，因?yàn)槟阒蟮臅r(shí)間很有可能會(huì)蹦出很多個(gè)想法，擾亂原有的安排，所以你需要在前期有個(gè)原則堅(jiān)持住，以防心不定而一事無(wú)成。

　　界面的設(shè)計(jì)

　　Web項(xiàng)目的一個(gè)重要部分就是界面，它可能指的是瀏覽器前端，也可能指的是某個(gè)手機(jī)平臺(tái)的UI，我們這個(gè)時(shí)候需要花些心力在設(shè)計(jì)方面，包括UI的設(shè)計(jì)和交互設(shè)計(jì)。

　　由于大部分開(kāi)發(fā)者很難有良好的設(shè)計(jì)感，如果有設(shè)計(jì)師朋友的話也可以請(qǐng)他們幫忙，否則的話可以多去一些設(shè)計(jì)網(wǎng)站(比如dribbble)，多收集一些美觀大方、符合自己要求的界面，從而形成對(duì)自己項(xiàng)目的認(rèn)識(shí)。

　　如果有能力做高保真界面的話，那么請(qǐng)一定要做，不要覺(jué)得做高保真界面的圖片是浪費(fèi)時(shí)間，不要因?yàn)槟阌X(jué)得寫html/css更省事就直接開(kāi)敲前端界面了，你在做圖的時(shí)候所思考的和你敲界面代碼所思考的其實(shí)并不是一回事，前者會(huì)讓你更加著重設(shè)計(jì)感，而后者更偏向于實(shí)現(xiàn)。

　　在這個(gè)期間里需要多觀察觀察別的網(wǎng)站/應(yīng)用的界面，找出那些自己喜歡的，然后詢問(wèn)自己哪部分是自己喜歡的，如果放在自己的項(xiàng)目是否可行，能完整表達(dá)我們之前的需求元素么？

　　很多人在做單獨(dú)項(xiàng)目的時(shí)候，前期花在界面設(shè)計(jì)上的時(shí)間極少，都是腦子有一個(gè)大概，然后邊寫代碼邊腦補(bǔ)界面樣子，寫著寫著就走了樣，最后弄出來(lái)的界面是混雜的，看上去很亂。

　　我以程序員的角色來(lái)分享幾條界面設(shè)計(jì)的建議：

　　1、如果自身不是專業(yè)設(shè)計(jì)，就不要采用復(fù)雜的界面，那么設(shè)計(jì)界面的時(shí)候請(qǐng)走扁平化，一個(gè)web頁(yè)面/app 頁(yè)面的顏色請(qǐng)盡量保持兩到三個(gè)，并維持一個(gè)主色調(diào)，其他的使用同類色系。

　　2、如果是手機(jī)app，那么請(qǐng)和平臺(tái)推薦的設(shè)計(jì)方向保持一致，比方說(shuō)如果是iOS app，那么應(yīng)當(dāng)參照ios的原生應(yīng)用來(lái)做設(shè)計(jì)，而如果是Androidapp，那么請(qǐng)使用material design的規(guī)則，不要妄圖利用相同的設(shè)計(jì)做不同平臺(tái)的app，容易變亂。你使用原生的平臺(tái)設(shè)計(jì)，就算設(shè)計(jì)感不強(qiáng)，也不會(huì)顯得雜亂無(wú)章。

　　3、Web界面的設(shè)計(jì)應(yīng)該有自己的特點(diǎn)，我知道很多做單獨(dú)web項(xiàng)目的人喜歡用開(kāi)源的web前端框架，比如bootstrap、amaze UI這些，雖然節(jié)省心力，但是做出來(lái)的界面大同小異，容易疲勞，瀏覽器上的界面和手機(jī)app不一樣，它屏幕更大，可以表現(xiàn)的也更豐富，如果實(shí)在要用開(kāi)源web框架的話，也要嘗試換換色系之類的。

　　４、心態(tài)要好，大多數(shù)的時(shí)候自己設(shè)計(jì)的界面，是挺難看的，別因?yàn)檫@事挫敗了做項(xiàng)目的積極性，也別想一口氣做出來(lái)個(gè)美輪美奐的UI閃瞎大家的眼，畢竟不是職業(yè)的設(shè)計(jì)師，不要和自己慪氣。

　　界面實(shí)現(xiàn)

　　在界面基本定稿的時(shí)候，這時(shí)候我們可以來(lái)正式實(shí)現(xiàn)界面了，我們之前技術(shù)選型的時(shí)候應(yīng)該考慮到前端需要用到哪些技術(shù)，比如說(shuō)做web界面的時(shí)候，是否需要做成one page application，是否需要使用前端庫(kù)等等。

　　web前端現(xiàn)在環(huán)境變化非常大，已經(jīng)由原來(lái)的做頁(yè)面轉(zhuǎn)成應(yīng)用化了，所以配套的工具也變得多、雜、繁了，選型的時(shí)候還是需要注意選自己熟悉的，生態(tài)圈好的，在這一點(diǎn)上，框架上有vue、React、angular比較知名，我個(gè)人比較喜歡vue，它上手還是蠻快的，如果想做應(yīng)用式的web產(chǎn)品可以選用。

　　android app的客戶端如果你以前使用非android studio來(lái)編寫的話，那么這個(gè)新項(xiàng)目就換用android studio吧，它已經(jīng)足夠好用了，在做界面開(kāi)發(fā)的時(shí)候，推薦使用那些大熱的開(kāi)源組件，比如說(shuō)fresco、rxjava、retrofit、gson這些，可以節(jié)省大量心力，組織代碼的話使用MVP或者M(jìn)VVM模式也能讓新項(xiàng)目變得容易維護(hù)，推薦使用，之前我也寫過(guò)一篇關(guān)于MVP應(yīng)用的文章：Dagger2的應(yīng)用——MVP+Retrofit+RxJava

　　如果你寫的是ios app的話，不要在語(yǔ)言上（OC或者Swift）來(lái)猶豫，事實(shí)上這兩門語(yǔ)言都能很好的完成一個(gè)app的構(gòu)建，而且還可以混合編程，同樣的，在開(kāi)發(fā)app的時(shí)候請(qǐng)大膽使用開(kāi)源庫(kù)，比如masonry、reactivecocoa或rxswift，cocoa touch原本的MVC模式也很清晰明了。

　　如果自己想實(shí)現(xiàn)多平臺(tái)的Wweb應(yīng)用，可能會(huì)使用React Native這類工具來(lái)完成app開(kāi)發(fā)，說(shuō)實(shí)話比起原生語(yǔ)言開(kāi)發(fā)app，它對(duì)web開(kāi)發(fā)者來(lái)說(shuō)更友好一些，如果有RN相關(guān)經(jīng)驗(yàn)的可以盡情嘗試。

　　現(xiàn)在不管web開(kāi)發(fā)還是app開(kāi)發(fā)，都可以把前后端切斷，讓后端作為數(shù)據(jù)輸出方，不過(guò)有時(shí)候我們的web項(xiàng)目可能需要對(duì)SEO友好，所以可能需要花心力在同構(gòu)上面，也就是在前端和后端都維護(hù)相同的路由和相同的模板渲染，代價(jià)也是比較大的，當(dāng)然也可以像傳統(tǒng)開(kāi)發(fā)那樣完全由后端render view，具體情況自己考慮。

　　后端的接入

　　后端開(kāi)發(fā)牽扯非常廣，所以我們不太可能是把前端做完了再做后端，一般情況下，做前端和做后端是交叉并行的，這一點(diǎn)其實(shí)是在模擬團(tuán)隊(duì)合作的情況，只不過(guò)身兼多職。

　　后端這邊我依舊推薦選型的時(shí)候選擇自己最熟悉的，如果熟悉某款框架的話，那么盡量用框架，后端開(kāi)發(fā)的語(yǔ)言并沒(méi)有什么限制，可以在下面幾種語(yǔ)言里選擇：

　　傳統(tǒng)語(yǔ)言：Java 、C# .Net

　　傳統(tǒng)腳本語(yǔ)言：PHP、Python、ruby

　　新興語(yǔ)言：Node.js、golang

　　用來(lái)作死的：C/C++

　　一般情況下，我推薦腳本語(yǔ)言來(lái)開(kāi)發(fā)web應(yīng)用的后端，前幾年ruby> 　　一個(gè)重點(diǎn)是我們可能要考慮數(shù)據(jù)庫(kù)的問(wèn)題，需要對(duì)常見(jiàn)的數(shù)據(jù)庫(kù)很熟悉，并且能夠合理的抽象出schema，以及合理的建立索引，多表之間如何聯(lián)合，這些都是和需求緊密相關(guān)的，只有深刻理解了自己的需求，才能做好這些事情。

　　后端開(kāi)發(fā)的時(shí)候建議使用ORM，如果框架自帶ORM的話那就用框架自帶的，如果不自帶可以選用社區(qū)開(kāi)源、生態(tài)圈豐富的ORM，需要注意有些ORM本身bug比較多，坑也多，只能多踩踩才知道。

　　我們剛開(kāi)始可能只是簡(jiǎn)單的增刪查改，不過(guò)隨著加入用戶體系、身份驗(yàn)證、權(quán)限劃分、內(nèi)容過(guò)濾等等需求之后，就可能需要你合理的規(guī)劃好控制器的代碼，我建議大部分情況下做成一條條service，然后做串聯(lián)調(diào)用。

　　后端開(kāi)發(fā)要注意網(wǎng)絡(luò)安全，用戶身份的存取，內(nèi)容數(shù)據(jù)的插入，文件的上傳這些容易出問(wèn)題的地方都需要格外注意，不要因?yàn)樽约鹤龅男【蛨D省事，弄個(gè)滿是安全漏洞的網(wǎng)站，還不如不上線。

　　緩存機(jī)制其實(shí)對(duì)于并發(fā)高的時(shí)候效果很明顯，在設(shè)計(jì)后端的架構(gòu)時(shí)候，也應(yīng)當(dāng)考慮到哪些部分可以用緩存代替，我們常用的memcached或者Redis都是緩存利器，非常建議配合使用，不要在意你的網(wǎng)站是個(gè)小網(wǎng)站。

　　有時(shí)候需要考慮定時(shí)任務(wù)或者異步任務(wù)隊(duì)列，這個(gè)時(shí)候我們可以選一些好用的工具，比如說(shuō)用redis、開(kāi)源MQ或者是專門用來(lái)做任務(wù)的任務(wù)調(diào)度器之類的，我之前寫過(guò)一篇關(guān)于任務(wù)隊(duì)列和任務(wù)調(diào)度器的文章：淺談任務(wù)隊(duì)列和任務(wù)調(diào)度
后端開(kāi)發(fā)注意主次，有的時(shí)候增加或者修改一個(gè)功能，其實(shí)牽扯到不只一塊區(qū)域，所以盡量保證抽象層次要高一些，代碼耦合也要低一些。

　　有些頁(yè)面是用來(lái)獲取數(shù)據(jù)的，而有些是用來(lái)處理數(shù)據(jù)的，我們對(duì)這些部分要分開(kāi)出來(lái)，也可以采用RESTful這種API 設(shè)計(jì)的架構(gòu)，把功能抽象成資源，轉(zhuǎn)而對(duì)資源進(jìn)行增加或者修改。

　　簡(jiǎn)單的總結(jié)

　　一個(gè)人寫一個(gè)web項(xiàng)目，是很累的，需要你有強(qiáng)大的熱愛(ài)才能完成它，有些建議可以讓你能夠順利的完成獨(dú)立的web項(xiàng)目：

　　1、三思而后行，不理智的項(xiàng)目乘早斷了想法。

　　2、不要上來(lái)就敲代碼，做些提前工作，需求和設(shè)計(jì)。

　　3、功能是一步一步來(lái)的，不要最開(kāi)始就弄一大堆，容易打退堂鼓。

　　4、用開(kāi)源框架、庫(kù)、工具能夠節(jié)省你的心力，前提是你足夠熟練。

　　5、不要在寫代碼的時(shí)候就想著優(yōu)化怎么做，說(shuō)不定你想的優(yōu)化其實(shí)很渣。

　　6、定下來(lái)的需求如果要變更，請(qǐng)盡量小，如果要推翻重做需求，說(shuō)明你最開(kāi)始就不成熟。

　　7、你要相信會(huì)有版本迭代，所以有新想法的時(shí)候別急，先記下來(lái)。

　　8、保持愛(ài)來(lái)抵抗做項(xiàng)目的寂寞和焦躁，碰到坑的時(shí)候可以散散心。

　　9、一個(gè)web項(xiàng)目別拖太久，時(shí)間越長(zhǎng)越容易腰斬。

　　10、心態(tài)好點(diǎn)，接收它99%會(huì)撲街的事實(shí)。