自己一人如(rú)何去做一個(gè)web項目

發表時間：2016-12-20

發布人：葵宇科技

浏覽次數：38

三思而後行

　　當你(nǐ)被自己的想法激起心中(zhōng)豪情的時候，一定要按下(xià)心情，冷(lěng)靜的思考一下(xià)，思考點包括以下(xià)幾個(gè)部分：

　　這個(gè)Web項目所需要的知識和(hé)能力是否在自己所掌握的範圍内，這個(gè)是技術(shù)前提，如(rú)果項目本身技術(shù)複雜度過高，那麼你(nǐ)在開發的時候所面對的壓力就非常大，而且挫敗感也很高，項目很容易夭折。

　　項目的需求能否清晰描繪，這一點非常重要，因為隻有你(nǐ)能細緻的把一個(gè)項目拆分成一條條需求，你(nǐ)才能對所有的技術(shù)實現點有個(gè)預估，也才能對項目所需要的時間做個(gè)預判。

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

　　技術(shù)選型怎麼做，是做一個(gè)網站(zhàn)還是做一款app或者是多平台的，後端用什麼語言來搭建，需要使用什麼框架，這些選型需要在心中(zhōng)有底，我建議做項目的時候選用自己最熟悉、生态最豐富的語言和(hé)框架，除非你(nǐ)隻想練個(gè)手，否則不應當用冷(lěng)門的。

　　所以項目未動(dòng)，思考先行是必須的，通(tōng)過仔細的思考我們可(kě)以判斷自己所謂的“靈感”是不是僞靈感，而自己又能否适應開發期的單調枯燥，這些需要慎重對待，不能掉以輕心。

　　産品需求清單

　　經過仔細的思考之後，依舊覺得項目可(kě)行的話，那麼就應該進入“産品經理”的角色，作為一個(gè)人的項目，産品需求倒未必隻能是一個(gè)人思考，也可(kě)以找朋友等人探讨，征求一下(xià)别人的想法之類的。

　　産品需求需要确保每一步都能執行，所以理論上越詳細越好，在你(nǐ)思索産品的時候，你(nǐ)應該對界面上所需要的具體元素有清晰的認知，而且還對它牽扯到後端的功能如(rú)何組織和(hé)拆分。

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

　　基本上到這個(gè)時候，原本的激情已經逐漸平淡，理智重新歸位，但對産品未來的期待感還是很強，這時候你(nǐ)需要考慮的情況實際上是非常多的，也是你(nǐ)容易失眠的階段，所以應當好好調整心态。

　　做産品需求的時候，你(nǐ)可(kě)能需要幾個(gè)流程圖，依賴圖這些對功能的劃分，多使用腦圖軟件來構思自己的産品，也嘗試思考流程是否能簡化，站(zhàn)在用戶的角度下(xià)使用是否方便，哪些功能是主要的，哪些是次要的。

　　如(rú)果覺得文(wén)字描繪不清晰的話，你(nǐ)也可(kě)以自己做幾張原型圖出來，注意這不是高保真圖，隻是讓你(nǐ)自己弄明白這個(gè)産品的某一頁或者某一塊，不應當把心力花(huā)在細節上。

　　總之在這個(gè)階段，應該有大局感，而且也應當仔細打磨自己的想法，如(rú)此三番之後要給自己定下(xià)個(gè)初稿，因為你(nǐ)之後的時間很有可(kě)能會蹦出很多個(gè)想法，擾亂原有的安排，所以你(nǐ)需要在前期有個(gè)原則堅持住，以防心不定而一事無成。

　　界面的設計

　　Web項目的一個(gè)重要部分就是界面，它可(kě)能指的是浏覽器(qì)前端，也可(kě)能指的是某個(gè)手機平台的UI，我們這個(gè)時候需要花(huā)些心力在設計方面，包括UI的設計和(hé)交互設計。

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

　　如(rú)果有能力做高保真界面的話，那麼請一定要做，不要覺得做高保真界面的圖片是浪費時間，不要因為你(nǐ)覺得寫html/css更省事就直接開敲前端界面了，你(nǐ)在做圖的時候所思考的和(hé)你(nǐ)敲界面代碼所思考的其實并不是一回事，前者會讓你(nǐ)更加着重設計感，而後者更偏向于實現。

　　在這個(gè)期間裡需要多觀察觀察别的網站(zhàn)/應用的界面，找出那些自己喜歡的，然後詢問(wèn)自己哪部分是自己喜歡的，如(rú)果放在自己的項目是否可(kě)行，能完整表達我們之前的需求元素麼？

　　很多人在做單獨項目的時候，前期花(huā)在界面設計上的時間極少(shǎo)，都是腦子(zǐ)有一個(gè)大概，然後邊寫代碼邊腦補界面樣子(zǐ)，寫着寫着就走了樣，最後弄出來的界面是混雜的，看上去很亂。

　　我以程序員的角色來分享幾條界面設計的建議：

　　1、如(rú)果自身不是專業(yè)設計，就不要采用複雜的界面，那麼設計界面的時候請走扁平化，一個(gè)web頁面/app 頁面的顔色請盡量保持兩到三個(gè)，并維持一個(gè)主色調，其他的使用同類色系。

　　2、如(rú)果是手機app，那麼請和(hé)平台推薦的設計方向保持一緻，比方說如(rú)果是iOS app，那麼應當參照ios的原生應用來做設計，而如(rú)果是Androidapp，那麼請使用material design的規則，不要妄圖利用相同的設計做不同平台的app，容易變亂。你(nǐ)使用原生的平台設計，就算設計感不強，也不會顯得雜亂無章。

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

　　４、心态要好，大多數的時候自己設計的界面，是挺難看的，别因為這事挫敗了做項目的積極性，也别想一口氣做出來個(gè)美輪美奂的UI閃瞎大家的眼，畢竟不是職業(yè)的設計師(shī)，不要和(hé)自己怄氣。

　　界面實現

　　在界面基本定稿的時候，這時候我們可(kě)以來正式實現界面了，我們之前技術(shù)選型的時候應該考慮到前端需要用到哪些技術(shù)，比如(rú)說做web界面的時候，是否需要做成one page application，是否需要使用前端庫等等。

　　web前端現在環境變化非常大，已經由原來的做頁面轉成應用化了，所以配套的工具也變得多、雜、繁了，選型的時候還是需要注意選自己熟悉的，生态圈好的，在這一點上，框架上有vue、React、angular比較知名，我個(gè)人比較喜歡vue，它上手還是蠻快的，如(rú)果想做應用式的web産品可(kě)以選用。

　　android app的客戶端如(rú)果你(nǐ)以前使用非android studio來編寫的話，那麼這個(gè)新項目就換用android studio吧，它已經足夠好用了，在做界面開發的時候，推薦使用那些大熱的開源組件，比如(rú)說fresco、rxjava、retrofit、gson這些，可(kě)以節省大量心力，組織代碼的話使用MVP或者MVVM模式也能讓新項目變得容易維護，推薦使用，之前我也寫過一篇關(guān)于MVP應用的文(wén)章：Dagger2的應用——MVP+Retrofit+RxJava

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

　　如(rú)果自己想實現多平台的Wweb應用，可(kě)能會使用React Native這類工具來完成app開發，說實話比起原生語言開發app，它對web開發者來說更友好一些，如(rú)果有RN相關(guān)經驗的可(kě)以盡情嘗試。

　　現在不管web開發還是app開發，都可(kě)以把前後端切斷，讓後端作為數據輸出方，不過有時候我們的web項目可(kě)能需要對SEO友好，所以可(kě)能需要花(huā)心力在同構上面，也就是在前端和(hé)後端都維護相同的路(lù)由和(hé)相同的模闆渲染，代價也是比較大的，當然也可(kě)以像傳統開發那樣完全由後端render view，具體情況自己考慮。

　　後端的接入

　　後端開發牽扯非常廣，所以我們不太可(kě)能是把前端做完了再做後端，一般情況下(xià)，做前端和(hé)做後端是交叉并行的，這一點其實是在模拟團隊合作的情況，隻不過身兼多職。

　　後端這邊我依舊推薦選型的時候選擇自己最熟悉的，如(rú)果熟悉某款框架的話，那麼盡量用框架，後端開發的語言并沒有什麼限制，可(kě)以在下(xià)面幾種語言裡選擇：

　　傳統語言：Java 、C# .Net

　　傳統腳本語言：PHP、Python、ruby

　　新興語言：Node.js、golang

　　用來作死的：C/C++

　　一般情況下(xià)，我推薦腳本語言來開發web應用的後端，前幾年ruby> 　　一個(gè)重點是我們可(kě)能要考慮數據庫的問(wèn)題，需要對常見的數據庫很熟悉，并且能夠合理的抽象出schema，以及合理的建立索引，多表之間如(rú)何聯合，這些都是和(hé)需求緊密相關(guān)的，隻有深刻理解了自己的需求，才能做好這些事情。

　　後端開發的時候建議使用ORM，如(rú)果框架自帶ORM的話那就用框架自帶的，如(rú)果不自帶可(kě)以選用社區開源、生态圈豐富的ORM，需要注意有些ORM本身bug比較多，坑也多，隻能多踩踩才知道。

　　我們剛開始可(kě)能隻是簡單的增删查改，不過随着加入用戶體系、身份驗證、權限劃分、内容過濾等等需求之後，就可(kě)能需要你(nǐ)合理的規劃好控制器(qì)的代碼，我建議大部分情況下(xià)做成一條條service，然後做串聯調用。

　　後端開發要注意網絡安全，用戶身份的存取，内容數據的插入，文(wén)件的上傳這些容易出問(wèn)題的地方都需要格外注意，不要因為自己做的小就圖省事，弄個(gè)滿是安全漏洞的網站(zhàn)，還不如(rú)不上線。

　　緩存機制其實對于并發高的時候效果很明顯，在設計後端的架構時候，也應當考慮到哪些部分可(kě)以用緩存代替，我們常用的memcached或者Redis都是緩存利器(qì)，非常建議配合使用，不要在意你(nǐ)的網站(zhàn)是個(gè)小網站(zhàn)。

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

　　有些頁面是用來獲取數據的，而有些是用來處理數據的，我們對這些部分要分開出來，也可(kě)以采用RESTful這種API 設計的架構，把功能抽象成資(zī)源，轉而對資(zī)源進行增加或者修改。