我們(men)的學員經常留(liu)言說剛(gang)接(jie)手了一(yi)個(ge)新項(xiang)目(mu)，感覺手忙腳(jiao)亂(luan)的，不知道從何(he)下手，針(zhen)對(dui)這點(dian)小編準備羅列(lie)了一(yi)套(tao)職場(chang)小白如何(he)順利完成一(yi)個(ge)新項(xiang)目(mu)的流程(cheng)，步驟和項(xiang)目(mu)規劃書，歡(huan)迎圍觀。

一、項目規劃

1.1 首先，你得徹底明白到底要做什么?

這個過程，可能是你(ni)要讀(du)需(xu)求(qiu)一(yi)遍、兩遍、三遍。。。 然后假(jia)設，你(ni)已經在使用這個產品了。

1.2 其次，明白需求后，就要進行整體框架的構思!

比如(ru)用(yong)什(shen)么呈現給(gei)用(yong)戶，用(yong)什(shen)么來存儲數據，需要(yao)些什(shen)么樣的(de)系統(tong)等。

在這個層次(ci)上(shang)，一(yi)般都會遵循公司的規定，然(ran)后再根據(ju)項目本身需求，做些相應的調整。

我們在(zai)這(zhe)個(ge)項(xiang)目(mu)里的整(zheng)體框(kuang)架為：前(qian)端使用 APP(ios&android)、H5進(jin)行(xing)用戶界(jie)面(mian)呈現 ===>> 接入網(wang)關進(jin)行(xing)數(shu)據加解(jie)密，流控(kong)轉發等(deng) ===>> 第(di)一層API服務(wu)(wu)(wu)，接受客戶端請求，做(zuo)簡單業務(wu)(wu)(wu)檢驗(yan)組裝 ===>> 第(di)二層核心業務(wu)(wu)(wu)SERVICE服務(wu)(wu)(wu)，進(jin)行(xing)核心業務(wu)(wu)(wu)處理，如寫庫、調(diao)用第(di)三(san)方接口等(deng) ===>> 最下(xia)層基礎服務(wu)(wu)(wu)，提供單一的功能服務(wu)(wu)(wu)，如消息(xi)服務(wu)(wu)(wu)，訂單服務(wu)(wu)(wu)。

前期只提(ti)供APP，因此不(bu)存在單獨H5調用API服務(wu)的情況，但是H5的應用場景仍然存在，此時的H5地址，由服務(wu)接口提(ti)供地址返回到(dao)APP進行webview加載。

1.3 人員規劃

項目整體框架出(chu)來后(hou)，得要有(you)人(ren)去實施才(cai)行。

這里(li)一(yi)(yi)(yi)般需要(yao)遵循一(yi)(yi)(yi)個最(zui)(zui)小原則，即劃分出的人員，盡(jin)量做到能(neng)夠獨(du)立(li)(li)完(wan)成自有(you)(you)的模塊，而(er)不是一(yi)(yi)(yi)定要(yao)依賴于另一(yi)(yi)(yi)方的實(shi)現(xian)才能(neng)進一(yi)(yi)(yi)步。比(bi)如 android,ios各(ge)一(yi)(yi)(yi)人，API與(yu)SERVICE可(ke)以(yi)多(duo)個人，但是都要(yao)讓其有(you)(you)全(quan)部權限，因為API與(yu)SERVICE有(you)(you)強依賴，脫離(li)一(yi)(yi)(yi)方，將(jiang)無法獨(du)立(li)(li)完(wan)成。基礎(chu)服務各(ge)自安排相關人員實(shi)現(xian)。最(zui)(zui)后(hou)進行聯調即可(ke)。

1.4 時間規劃

有(you)(you)了人(ren)員(yuan)之后，也(ye)不能無限時(shi)(shi)(shi)間的(de)去做事。肯定(ding)是要規(gui)劃(hua)的(de)，否則沒有(you)(you)壓力(li)也(ye)沒有(you)(you)動力(li)。項目不知(zhi)何時(shi)(shi)(shi)才能結束(shu)。訂時(shi)(shi)(shi)間計劃(hua)一定(ding)要去詢問當事人(ren)，要多少時(shi)(shi)(shi)間，盡(jin)量站在專業的(de)角度給出合理的(de)建議和評(ping)估。促(cu)進項目的(de)完成(cheng)。

二、框架規劃及搭建

2.1 有了整體框架的構思后，就要細節到每個層次的實踐了

因(yin)為都是應(ying)(ying)用(yong)的(de)(de)(de)分層，所以(yi)，不可(ke)能有統(tong)一(yi)的(de)(de)(de)描(miao)述(shu)，只能是針對(dui)每個(ge)應(ying)(ying)用(yong)層。做(zuo)自(zi)己該做(zuo)的(de)(de)(de)事(shi)。如 android/ios 有自(zi)己的(de)(de)(de)開(kai)發(fa)(fa)(fa)框架;h5有自(zi)己的(de)(de)(de)開(kai)發(fa)(fa)(fa)框架(因(yin)為很多(duo)應(ying)(ying)用(yong)場景(jing)可(ke)能涉(she)及到h5與app原生的(de)(de)(de)交互，所以(yi)即使功能簡單，也盡量利(li)用(yong)一(yi)些已(yi)有的(de)(de)(de)框架進(jin)行開(kai)發(fa)(fa)(fa))。

而(er)服務端(duan)，雖(sui)分為多層應(ying)(ying)用(yong)，但是應(ying)(ying)盡(jin)量使用(yong)同一門語言，利用(yong)同一套開發(fa)框架，自己公司(si)有(you)研發(fa)框架自然最好，沒有(you)也(ye)盡(jin)量利用(yong)統一的開源(yuan)框架。這樣做的好處是，當有(you)人員變動時，可以立(li)即熟(shu)悉其(qi)代碼(ma)及(ji)應(ying)(ying)用(yong)場(chang)景，從而(er)增加適應(ying)(ying)性(xing)和管理性(xing)。

針(zhen)對服(fu)務端(duan)的(de)(de)框架，我覺得有必要多說(shuo)點。因為(wei)整個(ge)應用(yong)運行的(de)(de)流暢性(xing)(xing)，可靠性(xing)(xing)，準確性(xing)(xing)，都是由服(fu)務端(duan)來(lai)決定的(de)(de)。雖(sui)然(ran)用(yong)戶(hu)看到的(de)(de)是APP或(huo)者H5，但(dan)是可以說(shuo)，服(fu)務端(duan)才是應用(yong)的(de)(de)核心。所以，服(fu)務端(duan)要做的(de)(de)事情(qing)自(zi)然(ran)很多了。

2.2 怎樣搭建好一些服務端的框架呢?

首先，框架(jia)類的(de)東(dong)西，自然是(shi)(shi)要(yao)提前(qian)學習(xi)的(de)。但是(shi)(shi)，就目前(qian)市場行情來說，要(yao)想(xiang)利用框架(jia)應(ying)該都是(shi)(shi)比較(jiao)簡單的(de)，尤(you)其是(shi)(shi)公司內部提供的(de)框架(jia)，一(yi)定要(yao)有demo。這樣，照(zhao)著demo，一(yi)步步調試，直到整(zheng)個(ge)應(ying)用接通;

刪(shan)除不需要的(de)模塊，添加特(te)別需要的(de)模塊，保證在具體開發(fa)過程中(zhong)，能夠想利用(yong)啥(sha)就有啥(sha)可利用(yong);

充分了(le)解(jie)框架需要的一(yi)些配(pei)置參(can)數(shu)，知道事務從哪里(li)來(lai)，到哪里(li)去?這(zhe)里(li)，應有一(yi)個(ge)配(pei)置中心與(yu)之對應，但(dan)是自己得清楚。

使用一(yi)個順手的(de)IDE工(gong)具，不是(shi)說你(ni)技術不夠(gou)牛逼，而(er)是(shi)一(yi)個好(hao)的(de)工(gong)具，能夠(gou)讓(rang)你(ni)事(shi)半功倍。(其實能夠(gou)多背點(dian)套(tao)路，也(ye)不一(yi)定非(fei)要體現(xian)在正式項目(mu)上)

寫出第(di)一(yi)個(ge)可供(gong)使用的(de)接口服務，可以說(shuo)，第(di)一(yi)個(ge)永遠是比較重要的(de)。因為(wei)，第(di)一(yi)個(ge)的(de)思路，就是你后續所(suo)有功(gong)能的(de)方向，因此(ci)，寫好第(di)一(yi)個(ge)”hello, world.”;

三、開發環境的搭建(服務端)

3.1 其(qi)實這項工作是及其(qi)重要的(de)，之所以把它放在第三點，是因為，沒有代碼作鋪墊，開發(fa)環境搭了也沒用(yong)。

3.2 開發環境的(de)搭建，主要也是服從(cong)于(yu)整體框架的(de)構思。

主要(yao)包括(kuo)，需(xu)要(yao)多(duo)(duo)少個服務(wu)，需(xu)要(yao)多(duo)(duo)少臺服務(wu)器，需(xu)要(yao)多(duo)(duo)少個基礎應用(yong)，需(xu)要(yao)多(duo)(duo)少個基礎配(pei)置(zhi)等等。

當(dang)然，開(kai)發環境(jing)本身就是一(yi)個很大的難題，一(yi)般還是交(jiao)給專(zhuan)業運維幾(ji)十年的老(lao)司機來(lai)完(wan)成了。自(zi)己就當(dang)作了解得了。

目前的(de)(de)項(xiang)目開發，除一些小規模(mo)公(gong)司(si)還(huan)在利用(yong)一套服(fu)務(wu)(wu)端代碼，干(gan)完所有的(de)(de)事(shi)外，大部分應(ying)該都是(shi)多(duo)(duo)個(ge)應(ying)用(yong)的(de)(de)配合(he)完成。而測(ce)試環境，不太可能利用(yong)多(duo)(duo)個(ge)服(fu)務(wu)(wu)器提供服(fu)務(wu)(wu)。因此，使用(yong)docker進行測(ce)試環境搭建(jian)尤佳。建(jian)立多(duo)(duo)個(ge)docker進行多(duo)(duo)個(ge)服(fu)務(wu)(wu)器模(mo)擬，也算是(shi)和線上環境保持(chi)一致了。

目前的主流技術得(de)用(yong)上(當然關鍵還(huan)得(de)看(kan)你的框架(jia)規劃)，zookeeper, dubbo, redis, mongo, mq, …

3.3 只有開(kai)發環境搭(da)建好了，才能讓后面(mian)的流(liu)程(cheng)無憂。搭(da)建的過(guo)程(cheng)一(yi)定是(shi)，又(you)搭(da)建，又(you)改(gai)代(dai)碼，又(you)排錯…

四、進度的同步

4.1 及時向領導同步項目進度

對于(yu)一個(ge)新項(xiang)目(mu)，有些地方行(xing)動緩(huan)慢(man)是很(hen)正常的(de)。而(er)(er)部(bu)分開發(fa)同(tong)學(比如(ru)我(wo)自(zi)己(ji))，就喜歡(huan)沉浸在自(zi)己(ji)的(de)小(xiao)世界里糾(jiu)結(jie)，走不出來(lai)，從而(er)(er)忘卻(que)向領(ling)導匯報工作。而(er)(er)作為一個(ge)有點同(tong)理心的(de)領(ling)導來(lai)說，他又(you)不愿意實時都來(lai)盯著你(ni)做事，因為也(ye)怕你(ni)遇(yu)到(dao)困(kun)難，想多給你(ni)點時間解(jie)決。

但是，這種情(qing)況，開(kai)發同學自(zi)己其實是要吃虧的，因(yin)為，給外(wai)人的感覺就(jiu)是，你啥都沒做(zuo)。所以，解決問題的同時，也(ye)不忘向領導匯報。

4.2 有處理不了的問題，及時向大牛們或者領導請教

獨(du)立解決(jue)問(wen)題是好事，但是千(qian)萬(wan)別過了(le)頭(tou)，實在解決(jue)不了(le)，就要及時請教(jiao)(jiao)。否(fou)則，浪(lang)費的是時間。進(jin)步最快的方式，莫過于向比(bi)自己牛逼的人請教(jiao)(jiao)。知(zhi)(zhi)之(zhi)為知(zhi)(zhi)之(zhi)，不知(zhi)(zhi)為不知(zhi)(zhi)!

4.3 盡量將問題分攤下去

問(wen)題(ti)肯定是有的，而且(qie)會很多。千萬不要把所有的事情都壓在自己這兒，那樣自己會累死的，而且(qie)項(xiang)目(mu)進度也會因此(ci)變得緩慢。要多利用小(xiao)組成員的各自優點，適(shi)當多讓其搞點事情。

工作永(yong)遠(yuan)都不是(shi)單一(yi)的(de)一(yi)件(jian)事，肯定還會有其(qi)他(ta)的(de)事情插入進來，觀察事情的(de)重要性解決。如果能夠讓其(qi)他(ta)同學解決的(de)，盡(jin)量讓其(qi)他(ta)同學處理，這(zhe)點也得(de)與領導(dao)同步。否則(ze)分心過(guo)于利(li)害，受(shou)阻的(de)只有項(xiang)目(mu)進度，延期(qi)可(ke)不是(shi)自己一(yi)人的(de)事情了。

需(xu)求也(ye)不可能(neng)一下就(jiu)是(shi)完善(shan)的(de)(de)，在(zai)做(zuo)的(de)(de)過程中，才(cai)可能(neng)發現一些潛(qian)在(zai)的(de)(de)問題，這時及時與需(xu)求方溝通，保(bao)持高(gao)效的(de)(de)狀態。當然，后期(qi)的(de)(de)跟進，也(ye)是(shi)盡量做(zuo)到不要一人(ren)大(da)包(bao)大(da)攬(lan)，而是(shi)相(xiang)應的(de)(de)人(ren)就(jiu)去負責相(xiang)應事情的(de)(de)跟進。其他人(ren)只要知道(dao)結果就(jiu)行(xing)。

五、功能模塊的完成

5.1 說到具體的業務實現，個人覺(jue)得(de)，已經(jing)不那么難了(le)。不過就是，先盡力提(ti)出的一(yi)個初(chu)稿，然后發現問(wen)題(ti)解決(jue)問(wen)題(ti)，發現問(wen)題(ti)，解決(jue)問(wen)題(ti)的過程。

5.2 各自系統(tong)能(neng)做的(de)(de)事情完(wan)成(cheng)后，就是聯調各系統(tong)間的(de)(de)調用關系，保(bao)持(chi)高效的(de)(de)溝通，讓問題在短時(shi)間內解決，尤為(wei)重要。在這種時(shi)候(hou)，我覺得(de)，一個(ge)小(xiao)黑(hei)屋也許也是個(ge)不錯(cuo)的(de)(de)選擇。

5.3 聯調的過程，其實(shi)就是一個自(zi)測的過程，應把盡可能多情況(kuang)給考(kao)慮到位。

5.4 代碼檢查(cha)，自己(ji)開(kai)發的(de)代碼，基本上很(hen)難發現其(qi)中的(de)問(wen)題(ti)，即時找(zhao)到相(xiang)應人幫忙檢查(cha)代碼，是(shi)比較好的(de)解決(jue)代碼問(wen)題(ti)的(de)方案。其(qi)實，在(zai)給別人檢查(cha)的(de)時候(hou)，也是(shi)自己(ji)檢查(cha)的(de)時候(hou)，相(xiang)當于自己(ji)再一次的(de)開(kai)發，也能及時發現問(wen)題(ti)。

六、多輪的測試驗證

6.1 測試(shi)(shi)(shi)同(tong)學，其實(shi)在開(kai)(kai)發快(kuai)結束的時候，已(yi)經把測試(shi)(shi)(shi)用(yong)例給到(dao)大(da)家(jia)。這也是另一(yi)個角(jiao)度的開(kai)(kai)發，因(yin)此，參考測試(shi)(shi)(shi)用(yong)例進行相應開(kai)(kai)發修改也是很有必(bi)要的。

6.2 第(di)一輪測(ce)試，可(ke)能主要是(shi)大功(gong)能的驗(yan)證，小功(gong)能的檢查，擋板環境(jing)即(ji)可(ke)，無需真實環境(jing)。

6.3 第二輪測(ce)試(shi)，則是要把(ba)之(zhi)前的測(ce)試(shi)及各種配置(zhi)，全部清空，以(yi)一個全新的項(xiang)目來(lai)對待，重(zhong)新進(jin)行(xing)相(xiang)應(ying)環(huan)境(jing)(jing)搭(da)建，代(dai)碼(ma)部署，然(ran)后再進(jin)行(xing)測(ce)試(shi)，確保問題(ti)解(jie)決(jue)后，做好了相(xiang)應(ying)的處理(li)方案備份。這時，就需要用(yong)到(dao)真實的應(ying)用(yong)環(huan)境(jing)(jing)了。對之(zhi)前一些暫(zan)未解(jie)決(jue)的問題(ti)進(jin)行(xing)重(zhong)新測(ce)試(shi)。確保無問題(ti)。

6.4 第三輪測試(shi)，應該是(shi)一個灰度(du)發布(bu)的環境，也(ye)可以認為是(shi)預上(shang)線(xian)。將所有(you)環境當作是(shi)線(xian)上(shang)來處理，如(ru)果(guo)運行ok,即可準備發布(bu)上(shang)線(xian)了(le)。

6.5 在(zai)測試過(guo)程中(zhong)，因測試人員只(zhi)是人工的(de)處(chu)理(li)，有(you)時(shi)不一定(ding)能捕獲(huo)所有(you)的(de)問題(ti)，開發在(zai)這時(shi)，也應站在(zai)測試的(de)角(jiao)度(du)，發現問題(ti)，即(ji)時(shi)監控，即(ji)時(shi)處(chu)理(li)。

6.6 自動(dong)化(hua)測試，這個其實應該是靠后的(de)處理，但是如果能做到這些(xie)的(de)話，也能夠快速的(de)重(zhong)現(xian)問題。

6.7 壓力(li)測(ce)試，應對線上環境，需有(you)一定的(de)(de)能力(li)評(ping)估，不然，只瞎猜，恐(kong)怕(pa)也(ye)(ye)不是好事。隨時準備(bei)橫向擴展，也(ye)(ye)只是出現(xian)問題后(hou)的(de)(de)解決(jue)方案(an)。做好壓測(ce)，發現(xian)代碼中(zhong)存(cun)在(zai)的(de)(de)問題，即時處理掉。

七、外圍處理(上線前)

7.1 上(shang)線前，肯定是有(you)很多事務要處理的。

測試環境中的各種基礎(chu)數據，隨(sui)時導出備份(fen)，到線上時，直(zhi)接(jie)插入使用;

服務(wu)器，在架構評審過(guo)程中進行數量評估;

域名，對外網提供服務一定是要域名的;

權(quan)限，比如上(shang)線后，出現(xian)了問題，誰有(you)權(quan)限來(lai)處理問題，一(yi)定(ding)提前給到;

驗(yan)收(shou)，這是關(guan)鍵(jian)的一(yi)點，功能完成后，及時驗(yan)收(shou)，如果上線(xian)有(you)些小問題，盡量協商，不要(yao)在線(xian)上頻繁(fan)改動。

如此!

整個項目就完工了。

其實(shi)發(fa)現(xian)，一(yi)個項目真正(zheng)的(de)功能實(shi)現(xian)，并沒有占多(duo)大的(de)比例，而(er)是一(yi)些前期的(de)準(zhun)備(bei)及后續(xu)的(de)處理，反而(er)占了(le)更多(duo)的(de)時間(jian)。

第一(yi)個(ge)版本(ben)上(shang)線(xian)后(hou)，可能接著就是迅速迭代了。(如果運營(ying)還可以的話(hua)!)

以上，就是一(yi)整個項目的流程清單，以一(yi)步(bu)一(yi)個腳印的經歷總(zong)結(jie)，不涉及具體語言代碼(ma)，但是思路都是相通的，希望對你有(you)幫助!