一直再做前端，突然想到如果有一天領導讓自己獨立承擔一個web 專案的話是否有足夠的能力去接這個任務，要學會自己去搭建一些基礎的工具資訊。所有的這一切在心裡都要有個大致的流程，不然真正做的時候難免會手忙腳亂起來，接不了這個活難免失去了一個表現自己的機會，接下來做的差了，則更影響了錢途，前途啊。所以本文對做PC端的專案進行了一個過程的總結。 　　一、瞭解、明確需求。 　　這個應該是第一步了，不瞭解需求你就不知道為什麼要做，要怎麼去做這個專案的工作。 　　（1）明確需求是相當重要的，很有必要去和產品經理、設計人員去溝通，需要明白每一個按鈕，每一個開關存在的意義，這個需要設計人員足夠的瞭解專案的需求。之前做的一個專案就是這樣，工資花了好多錢請了一個UI設計公司設計了一個十分高大上的產品，各種頁面各種炫酷，領導覺得很滿意，趕緊讓我們去做，結果，真正到了我們開發人員手裡去開發的時候，才發現有些東西雖然在這裡很炫酷，但是根本不應該存在在這裡啊，例如你把新增人員的按鈕放在人員分組的管理下面，而不是人員管理下面有什麼意義呢？結果可想而知，不僅一些功能白設計了而且由於專案時間關係還得我們開發去擔任設計，重新設計功能的展示位置，這無疑耽誤了專案的進度。 　　（2）後臺介面問題，一般大的公司前臺和後臺是分離的，如果分離需要去跟後臺確定各種介面的方式，要有一個文件去管理這些後臺介面，要有示例、測試資料。現在的一般都是Restful風格的API方便呼叫。管理的平臺第一家公司用的是一個內部的叫OSG的介面管理系統，這裡是一個所有介面的中轉站，各個部門的介面都從這裡走，還有的用的是showdoc進行管理。要是前後端不分離的話，後臺便要自己開發，這個用node還是其他語言，也要做好相應的處理。 　　（3）、明確功能點，做好任務分配。 　　如果你是一個leader,那這一部分工作可能需要你去做了，列舉好所有的業務功能點，列成一個Excel檔案，明確每個功能的負責人，完成時間，技術難度等。這一步也是很重要的一步。 　　（4）開發時間確定 　　這個要確保開發時間的充足，不然匆匆忙忙做完一堆的bug改起來也是很痛苦的。這個而且前後臺一起進行確認，不然前端做完了，發現後端的介面還沒有完善，也是很耽誤時間的。 　　二、明確技術選型。 　　這一步也非常重要，需要去根據設計人員設計，去確認這個工作到底應該去用什麼框架去做。 　　（1）最基本的頁面佈局工作，是用bootstrap、flex還是手寫css進行佈局或者其它，需要去一開始就確定，不然真正做的時候，不同的開發人員用的不同的東西，顯然會造成專案程式碼的混亂。 　　（2）頁面的Css 是純手寫的還是使用Less或者Sass?這個根據專案的情況酌情處理，一旦使用的話就需要對這些指令碼進行編譯工作，這個工作可以用一些自動化工具例如Gulp webpack進行，也可以用Sublime（我用習慣這個了）、webstorm 等編輯器自帶的外掛進行,再或者使用考拉編譯進行編譯。 　　（3）、js的模組化是用sea.js還是require.js ？還是不進行模組化。不進行模組化當專案很大的時候，程式碼將變得很難維護，所以建議進行模組化，至於到底是用sea.js還是require.js這個就看自己的喜歡的，兩者的區別主要是一個是非同步一個是同步的，具體區別問問度娘、谷歌。 　　（4）、圖表模組、table等用什麼實現。圖表有：echarts、highCharts等、table有bootstrap table 、jgGrid,datatables等等。 　　三、自動化工具的使用。 　　現在各種自動化的工具很多，例如：webpack, gulp, grunt等等，（技術更新實在太快了），到目前我只會gulp有點low了，感覺跟不上時代的感覺。這一步工作主要是減少一些重複的工作，比如壓縮js、css、頁面實時重新整理等工作。我最近的一個專案是使用的gulp進行專案裡的html、js檔案進行多語種的處理，用gulp讀取了language.js裡的每句話對應的變數，然後再頁面裡進行替換後變成一個英文版和中文版的兩份，這樣的工作肯定也必須是要自動的工具去處理的，不然寫兩份的話不得痛苦死。 　　四、基礎程式碼的模組化。 　　以上都是準備工作，但也是很重要的部分。這一步開始就可以真的開始就進行工作了。 　　（1）、如果使用了自動化，自動化的指令碼是要寫的，具體去如何實現你需要的自動化工作，如何減少重複的，枯燥的工作將極大的提高開發效率，縮短開發時間。 　　（2）、再者就是頁面的 alert、對話方塊（confirm）、模態窗(layer,boostrap modal)、驗證模組（例如：郵箱，電話號碼的驗證，不為空的驗證等），日期處理（如：date add 、format等），這些需要有人去專門的進行模組化，而且一定要在真正的業務程式碼開始之前完成，否則後面修改起來將十分費勁。 　　（3）還有就是要有人對專案裡比較棘手的技術難題提前進行攻關，確保真正的業務開始開發時，技術已經可以實現了。 　　五、業務程式碼的模組化。 　　這一步開始就要真正的開始接觸業務的東西了。開始這一步之前當然得要有設計的文件，假設你已經有了。功能程式碼也可以進行模組化進行，將專案設計文件裡的出現的比較多的展示的內容進行抽離，例如表格，展示圖，共用樣式，頁面佈局等等、抽離出來，指定專門的一個兩個開發人員進行開發，進行模組化，然後有一個人進行對這些模組的呼叫，組裝。這部分工作讓最熟悉的人去做相應的工作，可以提高開發效率。這部分裡面包括和後臺進行的介面，所以確保要有介面進行呼叫。 　　六、零碎任務分配。 　　大塊的功能完了之後就是各個功能點了，這個應該在分配任務的時候分配好，當然也可以當前面的工作完了之後看開發人員的工作情況進行分配，保證每個人都有工作，保證專案不會拖沓。 　　七、當上面的工作進行完了之後，整個專案的功能基本就完成了。最好還要讓各自的開發人員測試下自己的功能。自測完成後再交由測試進行測試，後續就是bug修復的問題了。 　　八、專案總結。 　　專案完了總要總結一下，可以開一個內部的會議，將各自開發過程中的難題難點提出來，大家一起聽聽是怎麼解決的，或者誰對別人開發的東西比較感興趣，想要了解是怎麼實現的及內部原理，在這個時候就可以進行溝通了交流了，這樣的交流對提高團隊人員的技能還是很有幫助的。然後一起聚個餐，增進下團隊的友誼。 　　過程中如果一個開發人員做了太久了一個類似的功能，可能會感到枯燥，所以避免一個人對一個大塊的內容進行開發，連個交流的人都沒有，會很痛苦。因為我就有這樣的經歷。 以上就是我的一些總結，希望對大家能有些許的幫助。如有不同意見，歡迎提出。 ———完結