自己一人如何去做一個web專案

　　三思而後行

　　當你被自己的想法激起心中豪情的時候，一定要按下心情，冷靜的思考一下，思考點包括以下幾個部分：

 

　　這個Web專案所需要的知識和能力是否在自己所掌握的範圍內，這個是技術前提，如果專案本身技術複雜度過高，那麼你在開發的時候所面對的壓力就非常大，而且挫敗感也很高，專案很容易夭折。

　　專案的需求能否清晰描繪，這一點非常重要，因為只有你能細緻的把一個專案拆分成一條條需求，你才能對所有的技術實現點有個預估，也才能對專案所需要的時間做個預判。

　　專案是否值得做，這個是個預防針，實際上很多時候個人專案都是拍腦袋想出來的，由於剛開始沒有想好就一腔熱血，一上來就開個專案工程檔案開始啪啪啪的寫程式碼，很容易做著做著就沒有動力了，最後有一天突然覺得這玩意也沒啥意思，於是草草的扔了，虎頭蛇尾的情況太常見了。

　　技術選型怎麼做，是做一個網站還是做一款app或者是多平臺的，後端用什麼語言來搭建，需要使用什麼框架，這些選型需要在心中有底，我建議做專案的時候選用自己最熟悉、生態最豐富的語言和框架，除非你只想練個手，否則不應當用冷門的。

　　所以專案未動，思考先行是必須的，通過仔細的思考我們可以判斷自己所謂的“靈感”是不是偽靈感，而自己又能否適應開發期的單調枯燥，這些需要慎重對待，不能掉以輕心。

　　產品需求清單

　　經過仔細的思考之後，依舊覺得專案可行的話，那麼就應該進入“產品經理”的角色，作為一個人的專案，產品需求倒未必只能是一個人思考，也可以找朋友等人探討，徵求一下別人的想法之類的。

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

　　在產品需求階段，也是你把專案原型豐富的階段，這個時候其實至關重要，很多時候你會發現你真正想要的和你原本打算要的已經完全不同了，最開始的打算可能根本行不通，同時你也有可能蹦出新的靈感，這些又會對原有的產品需求做或大或小的更改，說不定還會推翻原有的需求。

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

　　做產品需求的時候，你可能需要幾個流程圖，依賴圖這些對功能的劃分，多使用腦圖軟體來構思自己的產品，也嘗試思考流程是否能簡化，站在使用者的角度下使用是否方便，哪些功能是主要的，哪些是次要的。

　　如果覺得文字描繪不清晰的話，你也可以自己做幾張原型圖出來，注意這不是高保真圖，只是讓你自己弄明白這個產品的某一頁或者某一塊，不應當把心力花在細節上。

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

　　介面的設計

　　Web專案的一個重要部分就是介面，它可能指的是瀏覽器前端，也可能指的是某個手機平臺的UI，我們這個時候需要花些心力在設計方面，包括UI的設計和互動設計。

　　由於大部分開發者很難有良好的設計感，如果有設計師朋友的話也可以請他們幫忙，否則的話可以多去一些設計網站(比如dribbble)，多收集一些美觀大方、符合自己要求的介面，從而形成對自己專案的認識。

　　如果有能力做高保真介面的話，那麼請一定要做，不要覺得做高保真介面的圖片是浪費時間，不要因為你覺得寫html/css更省事就直接開敲前端介面了，你在做圖的時候所思考的和你敲介面程式碼所思考的其實並不是一回事，前者會讓你更加著重設計感，而後者更偏向於實現。

　　在這個期間裡需要多觀察觀察別的網站/應用的介面，找出那些自己喜歡的，然後詢問自己哪部分是自己喜歡的，如果放在自己的專案是否可行，能完整表達我們之前的需求元素麼？

　　很多人在做單獨專案的時候，前期花在介面設計上的時間極少，都是腦子有一個大概，然後邊寫程式碼邊腦補介面樣子，寫著寫著就走了樣，最後弄出來的介面是混雜的，看上去很亂。

　　我以程式設計師的角色來分享幾條介面設計的建議：

　　1、如果自身不是專業設計，就不要採用複雜的介面，那麼設計介面的時候請走扁平化，一個web頁面/app 頁面的顏色請儘量保持兩到三個，並維持一個主色調，其他的使用同類色系。

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

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

　　４、心態要好，大多數的時候自己設計的介面，是挺難看的，別因為這事挫敗了做專案的積極性，也別想一口氣做出來個美輪美奐的UI閃瞎大家的眼，畢竟不是職業的設計師，不要和自己慪氣。

　　介面實現

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

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

　　android app的客戶端如果你以前使用非android studio來編寫的話，那麼這個新專案就換用android studio吧，它已經足夠好用了，在做介面開發的時候，推薦使用那些大熱的開源元件，比如說fresco、rxjava、retrofit、gson這些，可以節省大量心力，組織程式碼的話使用MVP或者MVVM模式也能讓新專案變得容易維護，推薦使用，之前我也寫過一篇關於MVP應用的文章：Dagger2的應用——MVP+Retrofit+RxJava

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

　　如果自己想實現多平臺的Wweb應用，可能會使用react native這類工具來完成app開發，說實話比起原生語言開發app，它對web開發者來說更友好一些，如果有RN相關經驗的可以盡情嘗試。

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

　　後端的接入

　　後端開發牽扯非常廣，所以我們不太可能是把前端做完了再做後端，一般情況下，做前端和做後端是交叉並行的，這一點其實是在模擬團隊合作的情況，只不過身兼多職。

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

　　傳統語言：Java 、C# .Net

　　傳統指令碼語言：php、python、ruby

　　新興語言：node.js、golang

　　用來作死的：C/C++

　　一般情況下，我推薦指令碼語言來開發web應用的後端，前幾年ruby on rails框架流行的時候，帶來了非常快捷的開發方式，隨後其他語言也都相繼出現很方便的web框架，其中有大型框架，也有微框架，具體的抉擇可以看一下我之前的文章：除夕亂談web微框架，從koa說起

　　一個重點是我們可能要考慮資料庫的問題，需要對常見的資料庫很熟悉，並且能夠合理的抽象出schema，以及合理的建立索引，多表之間如何聯合，這些都是和需求緊密相關的，只有深刻理解了自己的需求，才能做好這些事情。

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

　　我們剛開始可能只是簡單的增刪查改，不過隨著加入使用者體系、身份驗證、許可權劃分、內容過濾等等需求之後，就可能需要你合理的規劃好控制器的程式碼，我建議大部分情況下做成一條條service，然後做串聯呼叫。

　　後端開發要注意網路安全，使用者身份的存取，內容資料的插入，檔案的上傳這些容易出問題的地方都需要格外注意，不要因為自己做的小就圖省事，弄個滿是安全漏洞的網站，還不如不上線。

　　快取機制其實對於併發高的時候效果很明顯，在設計後端的架構時候，也應當考慮到哪些部分可以用快取代替，我們常用的memcached或者redis都是快取利器，非常建議配合使用，不要在意你的網站是個小網站。

　　有時候需要考慮定時任務或者非同步任務佇列，這個時候我們可以選一些好用的工具，比如說用redis、開源MQ或者是專門用來做任務的任務排程器之類的，我之前寫過一篇關於任務佇列和任務排程器的文章：淺談任務佇列和任務排程
後端開發注意主次，有的時候增加或者修改一個功能，其實牽扯到不只一塊區域，所以儘量保證抽象層次要高一些，程式碼耦合也要低一些。

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

　　簡單的總結

　　一個人寫一個web專案，是很累的，需要你有強大的熱愛才能完成它，有些建議可以讓你能夠順利的完成獨立的web專案：

　　1、三思而後行，不理智的專案乘早斷了想法。

　　2、不要上來就敲程式碼，做些提前工作，需求和設計。

　　3、功能是一步一步來的，不要最開始就弄一大堆，容易打退堂鼓。

　　4、用開源框架、庫、工具能夠節省你的心力，前提是你足夠熟練。

　　5、不要在寫程式碼的時候就想著優化怎麼做，說不定你想的優化其實很渣。

　　6、定下來的需求如果要變更，請儘量小，如果要推翻重做需求，說明你最開始就不成熟。

　　7、你要相信會有版本迭代，所以有新想法的時候別急，先記下來。

　　8、保持愛來抵抗做專案的寂寞和焦躁，碰到坑的時候可以散散心。

　　9、一個web專案別拖太久，時間越長越容易腰斬。

　　10、心態好點，接收它99%會撲街的事實。