作為TGIDEAS里的技術(shu)(shu)研發團隊，我們跟其他的技術(shu)(shu)團隊一樣對新(xin)技術(shu)(shu)、新(xin)業(ye)務(wu)形(xing)態(tai)時刻關注，面對新(xin)的應用(yong)形(xing)態(tai)，團隊結合實際(ji)業(ye)務(wu)，趕在年前(qian)發布了以下四款小程(cheng)序應用(yong)：

其(qi)中“王(wang)(wang)者(zhe)榮耀(yao)賽(sai)事(shi)”僅僅歷經了1個月的開發時(shi)(shi)間，趕(gan)在(zai)小程序上(shang)線(xian)時(shi)(shi)發布；“王(wang)(wang)者(zhe)榮耀(yao)官網”緊隨(sui)其(qi)后，在(zai)上(shang)線(xian)的第(di)二天(tian)，也發布了。

而“火(huo)影忍(ren)者賽事”沿(yan)用現成的、完整的賽事直播框架，僅僅花了(le)8天(tian)時(shi)間，完成了(le)策(ce)劃、設計、開發和上線，這效率小伙伴們(men)都嚇了(le)一跳(tiao)。

“鄰友趣”這款(kuan)利用lbs找游戲好友的(de)陌(mo)生人(ren)社交小程序，歷經(jing)了一個多月的(de)開發時間，最終也在放假(jia)前發布。

項目的(de)(de)輸出效(xiao)率略高，這(zhe)背后(hou)到底(di)遵循了怎樣的(de)(de)開(kai)發(fa)流程(cheng)，樓主(zhu)今天(tian)拋磚(zhuan)引玉談(tan)(tan)一(yi)談(tan)(tan)，希望(wang)能(neng)引起大伙的(de)(de)一(yi)些思考，也(ye)希望(wang)能(neng)對即將或正(zheng)在開(kai)展小程(cheng)序開(kai)發(fa)的(de)(de)團隊有用。

小(xiao)(xiao)程(cheng)序(xu)(xu)在(zai)2017年1月(yue)9號(hao)全量發布，樓主團隊在(zai)10月(yue)份開(kai)始著手研究小(xiao)(xiao)程(cheng)序(xu)(xu)官網文(wen)檔，12月(yue)初團隊的第一個小(xiao)(xiao)程(cheng)序(xu)(xu)項目(mu)---“王者(zhe)榮耀賽事小(xiao)(xiao)程(cheng)序(xu)(xu)”項目(mu)需求正式立項，12月(yue)20日(ri)第一個成型的版本制作完(wan)畢，以(yi)下開(kai)發流程(cheng)示意圖：

（有同學疑(yi)問為什么是12月20制(zhi)作了第一版(ban)？當時(shi)微(wei)信公開(kai)課定(ding)在28號，我們猜其可能當天發布(bu)小程序，于是原計劃(hua)定(ding)在20號時(shi)完成完整版(ban)，有充足時(shi)間提審(shen)。）

王者賽事小(xiao)程序的開(kai)發(fa)流程跟網頁需求的開(kai)發(fa)流程很像，主要差(cha)別為：小(xiao)程序多了“版本(ben)提審”階段

由(you)于引入了審核(he)機(ji)制，小程序的迭代并(bing)不能(neng)如網頁(ye)那樣只(zhi)要(yao)開發(fa)者有發(fa)布(bu)(bu)權限就能(neng)馬上迭代到線上，需經(jing)微信(xin)官方團隊審核(he)后(hou)才(cai)能(neng)發(fa)布(bu)(bu)上線，于是，測試就變得重要(yao)了。

接(jie)下來說說王者賽事小程序(xu)的(de)開發流程遵循了簡(jian)單原則：

一、前(qian)端主(zhu)動驅動產品

為什(shen)么樓(lou)主建議(yi)前端主動驅動產(chan)品(pin)，主要原因在于(yu)：

1. 小程(cheng)序開發中前端技術比重較大(da)

對于API和組件，可由(you)前端開發者提供可行性評估。

由于小程序大(da)部分API和(he)組件均屬前(qian)端(duan)范疇，前(qian)端(duan)開發者(zhe)能告知產(chan)品經理組件和(he)API能實現到什么程度；而對于部分涉及后端(duan)技術的API，前(qian)端(duan)開發者(zhe)了解整(zheng)個前(qian)后端(duan)邏輯(ji)，可跟后端(duan)開發同(tong)學一起商(shang)量如(ru)何制作接(jie)口（例(li)如(ru)用戶鑒權接(jie)口）

開(kai)發模式(shi)的轉變，前端架構首當其沖。

小(xiao)程(cheng)序相比于(yu)網(wang)頁，前端技(ji)術(shu)形態(tai)雖然(ran)主體開(kai)發(fa)語(yu)言未發(fa)生(sheng)變化(hua)，依然(ran)可以通過編(bian)寫javascript/(w)xml/css實(shi)現邏輯(ji)，但(dan)設計思路已(yi)發(fa)生(sheng)大改(gai)，原本大部分網(wang)頁的(de)前端邏輯(ji)大多為(wei)面向過程(cheng)式編(bian)程(cheng)，而小(xiao)程(cheng)序是借了 HTML5 的(de)技(ji)術(shu)棧，卻跑的(de)是傳(chuan)統客戶端開(kai)發(fa)的(de)模式，限制(zhi)(zhi)了javascript直接對界面進行控制(zhi)(zhi)，開(kai)發(fa)者只能通過數據驅動來間接實(shi)現界面控制(zhi)(zhi)。

前(qian)端開發者結合上述兩點，可(ke)進一步(bu)進行技(ji)術預(yu)研，輸出成型(xing)demo，并推廣到產品(pin)側，引導其結合實際業務進行需求立項(xiang)，而在需求立項(xiang)后(hou)的功能迭代中，又可(ke)結合現有(you)API或(huo)組(zu)件的技(ji)術擴展性對立項(xiang)功能的設計邏輯提出建議。

TGIDEAS的(de)前端團隊遵循了以(yi)(yi)上方法，在10月-11月份對(dui)小程序(xu)進行技術研究，曾輸出過部分技術demo，如結合(he)web socket的(de)demo，以(yi)(yi)及結合(he)實(shi)際業務數據的(de)王者榮耀資訊demo，

（王者(zhe)榮耀賽事/官(guan)網小程(cheng)序(xu)原型(xing)）

為(wei)了告知相關團隊我們(men)能(neng)利用小程序實現什(shen)么，我們(men)還(huan)撰寫專(zhuan)門(men)的技術文(wen)章，最終(zhong)得(de)到產品和項目側的認可(ke)，進而策劃新需(xu)求，并最終(zhong)決定開發；而在后續的開發中，對于視頻直播、分享邏輯(ji)等功能(neng)上(shang)均提供(gong)了技術側以及(ji)產品側的建議。

2. 前端開發(fa)者需兼顧(gu)整個開發(fa)流程

首先，因開(kai)(kai)發(fa)需要(yao)，小(xiao)程序賬(zhang)號的唯一運營者(zhe)需要(yao)綁定為前端開(kai)(kai)發(fa)者(zhe)的微信號。從最(zui)初的賬(zhang)號申請到(dao)最(zui)終的提(ti)審(shen)發(fa)布(bu)，以及后(hou)續的數據統計分析階段，前端開(kai)(kai)發(fa)者(zhe)都需要(yao)參與，需要(yao)兼顧整個研發(fa)、測試和發(fa)布(bu)過(guo)程。

其(qi)次，前(qian)端(duan)橋接交(jiao)互、UI和后端(duan)，是各方通(tong)信的橋梁，因此，如果前(qian)端(duan)同學在此過程中(zhong)主動(dong)推動(dong)整個項目(mu)的進展(zhan)，項目(mu)研(yan)發速度將會有(you)較大提(ti)升。

二(er)、小步(bu)快跑(pao)，敏捷(jie)開發

每個功(gong)能(neng)，每個bug，在提(ti)出后的短時間內均快(kuai)(kuai)速(su)實現(xian)，王者(zhe)榮耀賽事(shi)小(xiao)程(cheng)序的開發周期之所(suo)以僅(jin)花了一個月，有賴(lai)于各(ge)方團隊的極力配合，實現(xian)了快(kuai)(kuai)速(su)拉會，快(kuai)(kuai)速(su)拍(pai)板，快(kuai)(kuai)速(su)排期，快(kuai)(kuai)速(su)開發等高效工(gong)作(zuo)模式。

怎樣做到敏捷開發，樓主覺得(de)只要(yao)有驅(qu)(qu)動者即(ji)可(ke)。前端可(ke)以驅(qu)(qu)動產(chan)品(pin)，所以這時(shi)候(hou)只要(yao)前端同學不要(yao)把自己的(de)角色定(ding)(ding)義為執行(xing)(xing)者，而是定(ding)(ding)義為驅(qu)(qu)動者，在遇(yu)到問題時(shi)，不是尋求方(fang)案(an)而是先提早預想解決方(fang)案(an)，然(ran)后引導大家(jia)對方(fang)案(an)進行(xing)(xing)優化即(ji)可(ke)。

三、PLAN B原則

這也(ye)是樓主在(zai)其他(ta)項目中(zhong)應用的原(yuan)則(ze)，意思是任何一套技術方(fang)案(an)，最好(hao)能構想兩(liang)套方(fang)案(an)，一個是預想方(fang)案(an)，一個是保(bao)底(di)方(fang)案(an)。

預(yu)想方案是大膽的假設方案，必(bi)須(xu)安排時間進行預(yu)研、突破和實現。

保底方(fang)案是(shi)必定能行的方(fang)案，一(yi)般是(shi)很簡單粗暴的方(fang)法(fa)，目(mu)的是(shi)為(wei)了保證(zheng)整(zheng)個產品邏輯(ji)起碼能形成閉環。

這(zhe)(zhe)么說可能(neng)有(you)點(dian)玄乎(hu)，我(wo)(wo)舉個(ge)例子，在進行王者(zhe)榮(rong)耀賽事小程(cheng)序時，我(wo)(wo)們有(you)面臨這(zhe)(zhe)么一個(ge)問題：現有(you)資訊(xun)的數(shu)據格(ge)式(shi)沒法滿足小程(cheng)序的數(shu)據格(ge)式(shi)要求。

我們制定的預選方案為(wei)：運營側(ce)(ce)或者前端側(ce)(ce)制作自動(dong)轉(zhuan)換接口，把原有(you)資訊內容自動(dong)轉(zhuan)成小(xiao)程序格式的內容。

保底方(fang)案為：手動轉換(huan)文章格式，并(bing)沉淀入(ru)庫，制(zhi)作接口調用(yong)。

起初(chu)，運(yun)營開(kai)發對預(yu)選方(fang)(fang)案(an)經過初(chu)步嘗(chang)試后，并未能實現(xian)，于是(shi)我們快速切換為保底方(fang)(fang)案(an)，讓項(xiang)目邏輯直接往下跑(pao)，而等到后期釋(shi)放人(ren)力后，運(yun)營開(kai)發的同(tong)學其實已(yi)經攻(gong)破了難關，原本的預(yu)選方(fang)(fang)案(an)已(yi)經能實現(xian)。

保底方(fang)案就是plan b，它不一(yi)定能用上，但它有不可磨(mo)滅的作用。

當然，這兩套(tao)方案并不是(shi)只(zhi)能選其一(yi)，也能同時(shi)使用。我們(men)對(dui)熱區數據埋(mai)點統計同時(shi)部署了預想方案和保底方案，

預想方案：微(wei)信提供的事(shi)件統計模(mo)塊

保(bao)底方案：點擊流(liu)的二次封裝接口

事(shi)實是(shi)(shi)，微(wei)信提供(gong)的(de)事(shi)件(jian)統(tong)計模塊(kuai)在小程序發布前期有BUG，數(shu)據有點(dian)偏差，但幸運的(de)是(shi)(shi)我們(men)兩(liang)套方案均部(bu)署(shu)了，點(dian)擊流的(de)統(tong)計方式(shi)把熱區統(tong)計的(de)數(shu)據收(shou)集了。

上(shang)述扯談了一下王者賽事小程(cheng)(cheng)序的(de)應(ying)急開發流(liu)程(cheng)(cheng)和一些原則(ze)，其實在(zai)攻克(ke)這(zhe)個小程(cheng)(cheng)序后，我們手(shou)上(shang)別的(de)小程(cheng)(cheng)序項目的(de)開發流(liu)程(cheng)(cheng)也就順暢起(qi)來了，這(zhe)里總結一下通(tong)用的(de)一個流(liu)程(cheng)(cheng)圖(tu)：

（時間的(de)評估是以我們團隊的(de)人力情況衡(heng)量的(de)，只做(zuo)參考(kao)）

預延期(qi)部分我涂灰了，并(bing)不是說這塊不重(zhong)要，相反樓主覺得這塊特別重(zhong)要，前端的同學最好在項目(mu)開(kai)始之前做一(yi)下預研，這樣有時候會(hui)事半(ban)功倍。

而在動態開發期，視(shi)覺還原環節可類比于目前網(wang)頁開發中的重構環節，可對目前的重構人力進行培訓進而分(fen)擔該部分(fen)工作。