用uniapp開發微信小程序的心得 - 總結與思考

這周用uniapp寫了個微信小程序，有點感觸，可能今晚睡一覺就忘了，趕忙記下來：

• 原型和設計不可靠
• 前端開發依賴後端接口
• 界面佈局效率較低
• 編譯速度慢很煩人
• 對接後端接口效率較低

距離上次開發微信小程序估計有1年多了吧，此次是到新公司以後的第一個開發任務，第一次使用uniapp，第一次使用藍湖看設計圖，第一次使用swagger看接口...

最後算是勉強完成任務了，下週提測。

優化工做流程

這周的工做流程是這樣的：

• 拿到原型和設計以後，隨便看了看，心不在焉地看不出什麼問題
• 憑藉多年踩坑經驗，粗略評估了開發時間
• 技術選型，久聞uniapp的大名，趕忙上
• 搭建了幾個uniapp的模板項目，發現果真仍是最簡單的那個hello world適合我這樣頭腦簡單的人
• 對着設計圖就寫代碼，佈局沒作完就寫邏輯，邏輯沒寫完又繼續寫佈局
• 用新的框架老是會遇到一些坑，而且總會吐槽一些寫法，並想着本身改變一下架構
• 寫着寫着就會發現這個原型、設計有問題，而後各類溝通
• 後端下班了，也沒有開發服務器繼續跑着，也沒有模擬的接口，工做無法開展了
• 由於同時進行界面佈局、熟悉設計、對接接口，因此雖然接口很少，可是也是到了最後一天也還在對接口、界面佈局、熟悉設計
• uniapp編譯+微信小程序編譯=慢得讓人有些煩躁，甚至想喝奶茶

若是再讓我重來，我會這麼優化個人工做流程：
儘快和工做的上下游對接清楚
由於你向上下游反饋的問題，他們須要時間配合你解決問題，你越晚反饋問題，你的工做風險越高。

• 拿到原型和設計以後，光看是看不出什麼的，整理出一份業務思惟導圖，儘快把發現的問題反饋給產品經理和UI設計
• 開發時間的評估通常要給得比較早，因此我仍是會在拿到原型以後向項目經理提供開發計劃
• 若是這時接口已經出來了，那麼就先想辦法調試接口。印象中postman能夠把請求過的接口保存起來，之後能夠直接用來看成本地調試數據。

優先解決界面佈局
不要同時寫界面佈局和界面邏輯，編譯慢不說，思惟跳躍效率也不高。優先作好頁面佈局的話，也能夠進一步熟悉設計，更早地發現問題，反饋問題。

• 技術選型時着重考慮配套的UI組件，結合設計儘可能找到成熟的UI組件，畢竟界面佈局什麼的很煩
• 先一口氣把因此html代碼寫了，先無論樣式
• 印象中chrome控制檯不只能夠臨時調試樣式，還能夠把樣式直接同步到源代碼中，的空得把這個技能弄到手

寫邏輯
這一塊沒什麼要優化的，我寫代碼心中一直謹記着：這份代碼得讓實習生也能看得懂才行。