一個小程序的誕生過程
2019-10-09
小程序的使用范圍越來越廣，隨之而來的各種小程序開發工具也如雨后春筍，今天要分享的是一套完整的帶后臺的小程序，完全從0開始，沒有借助任何小程序生成框架。
一、概述
從第一天早上10點的Idea到第二天凌晨6點提交上架，除去做飯+吃喝拉撒，總共花費約16個小時。復盤下來，覺得整個過程頗有代表性，故分享出來，供諸位拍磚。
二、工具清單
2.1 準備階段
思維導圖：幕布
小程序申請：微信公眾平臺
2.2 開發階段
2.2.1 后臺
版本管理：碼云
后臺開發IDE：PHPStorm
后臺框架：PHP + Laravel
數據庫：MySQL
微信后臺對接（Laravel插件）：EasyWechat
圖片存儲（Laravel插件）：Aliyun-oss-storage
2.2.2 小程序
小程序開發IDE：微信開發者工具
小程序：官方的文檔、組件、API
瀑布流展示（小程序插件）：BrickLayout曉瀑布流
2.2.3 設計
圖標：iconfont
UI參考：WeUI小程序版
編輯：Photoshop
2.3 運維階段
小程序助手
小程序數據助手
小程序客服小助手
三、開發過程
3.1 從Idea到動手
吃夠了不經調研的動手開搞帶來的苦頭，近幾年對于Idea到產品是頗為謹慎的。像這次干凈利索的決定，顯然已經是好久不見。
其實我是不推薦這么迅速的作出開發新項目的決定的，除非具備幾個因素：
項目開發周期短，1-3天為宜；
具備立竿見影的效果；
沒錢了。
從Idea到產品，首先需要梳理思路。
之前用的xmind，最近一直用新出的幕布，后者更方便分享，多端可用，比較適合國內的使用習慣。
時間緊迫，簡單畫了畫。如果是較大的項目，則需要有比較系統的思路。這里推薦下 processon，之前一直用他畫流程圖，最近發現它又新出了諸如商業畫布一類的工具，很好用。
3.2 著手設計
產品最終的形態，在開發之處最好是要有原型的，否則開發過程中，會逐步失去方向，被瑣碎的事情干擾，以致最終開發出的產品和最初的設想有很大出入。
產品原型的工具，在上面沒有列出來，是因為項目太小，畫原型圖在時間上劃不來。原型圖的工具推薦下墨刀，和幕布一樣，也是可以在線分享演示的，這在團隊協作和給客戶演示時非常方便。
這次的設計，就是完全在腦子里打了個草稿，又去找了找同類型的產品取了點經，一個大概的產品模型就有了。
至于風格什么樣，那就只能靠天吃飯了。因為這么短的時間，不可能去動用設計的兄弟，所以就在 iconfont 和 ooopic 一類的設計網站上找靈感。
好在iconfont上剛好有一組圖標，與心目中的產品比較契合，果斷下載。
至此，logo、圖標、框架等都齊了，開始最激動的擼代碼階段。
3.3 擼代碼
一個人搞定前后端，這里面就有些門道了。
先干啥后干啥，每個人的喜好不同。
以效率為出發點，我有如下建議：首搭框架，先前再后，先橫再豎，敏捷交付。
首搭框架，是指先把前后端的基礎框架搭建起來，該配的基礎功能先做好。比如Laravel的本地調試環境、代碼倉庫、云端服務器、備案過的域名、小程序的賬號、業務域名配置等等，這些環節先在腦子里過一遍，再從頭到尾整個做完。
之所以一鼓作氣全部做完，是因為在后面編碼的過程中，一旦被上面一些小問題卡住，思路就容易被打亂，影響效率。并且，很多事情是需要較長的時間的，比如域名備案，慢的話就得一二十天，如果被域名卡住，項目流產的可能性就會直線攀升。
第二是先前再后。這個意思則是在開發某個功能時，先設計前端界面和邏輯，再做后端接口和數據。反過來不行么？行，但是不好。
在這種快速迭代開發的情況下，前端頁面和邏輯沒有經過系統的設計，會經常發生變動。這和傳統團隊開發不太一樣，沒有概要設計到詳細設計再到開發的過程，更沒有并行開發的條件，因此要因地制宜，采取更適合這種小型作戰的方式方法。
當然，這個建議重點關注的是具體的功能開發，而不是完全取消前置設計。如果沒有整體的框架設計，是萬萬不行的。
第三是先橫再豎。我們從水平和垂直兩個方向，去劃分具體的功能。
比如這個項目中有四個頁面，分別是發現頁、發布頁、個人主頁、以及單篇展示頁。我在開發時，先把四個頁面建好，把tab和圖標都加進去，頁面切換做好，先感受下最終的效果。這種方式叫水平開發，好處在于讓你會對產品的最終形態先有所感知，如果有不舒服的地方，及時地進行調整。
當我們對某個頁面，或者某個跨頁面的功能進行開發時，則稱之為垂直開發。此時的功能顆粒度就會相對較小，也更容易把控。
最后是敏捷交付，是脫胎于敏捷開發模式的。意思是要持續的向客戶交付可用的產品，這里的客戶就是開發者自身。
在前幾個原則的基礎上，要實現敏捷交付，還應該注意不要被細枝末節的點牽絆住。比如某個圖標的配色不好，某個按鈕的位置擺的不正等等。切記，一定要抓大放小，美化完善的工作一定放在最最后。再者，一款產品就是要在不斷的打磨下，才能奔著精品而去。
3.4 運營準備
一個產品的啟動是很有講究的，尤其是社交和UGC產品。當一個用戶初次使用時，如果覺得你這個產品冷冷清清毫無生氣，是很難沉下心來去體驗的。所以，適當的“作假”是提高用戶體驗的增長黑客手段。
在產品達到一定量級后，一定記得把這些措施去除。比如王者榮耀的排位匹配，當你的等級很低時，會匹配一些AI機器人陪玩，以鼓勵玩家。當到達人數比較多的等級階段時，就會降低AI機器人的比率，因為讓用戶等待時間過久，是一件體驗非常不好的事。
同樣的，在我們這個產品中，用戶發出去的文章，在達到一定時間內，應當引入一定的激勵機制，以鼓勵用戶。當用戶較多時，真實的互動足夠激勵用戶再創作時，則可取消激勵機制，徹底度過項目的冷啟動階段（時間關系，當前版本并沒有加入激勵機制）。
四、擴散
如上所述，這樣一個產品，站在前人的肩膀上，可以快速搭建一個簡單的MVP，而之后的運營和迭代才是難中之難。
首先，任何的迭代開發，要保持一個大方向不動搖。換句話說，產品的調性不要輕易改變。
比如做上面這樣一款社交產品，就扎扎實實圍繞社交打磨功能，當可以成為精品的時候，再考慮逐步橫向拓展，諸如廣告、帶貨、游戲等。
微信就是一個很好的例子。
近幾個月，微信動作頻繁，上線了一大批變現功能，并且前提是以用戶體驗不受較大影響。社交是微信的方向，是微信的固有屬性，根深蒂固；如果把這個根基動了，上層功能模塊也便不牢靠了。
對面的支付寶，不斷創新，不論從功能還是排版，均發揮了產品經理極大的腦洞。結果是最終偃旗息鼓，不再大動社交的腦筋。
其次，產品初期的迭代要根據市場反饋靈活調整。市場反饋怎么看？數據。像微信小程序，就給出了相當完善的運營工具，其他諸如阿拉丁第三方工具，也可以作為不錯的輔助。
具體怎么玩呢？看活動效果，看推廣渠道帶來的指標增長，看某個功能調整帶來的用戶波動，等等。這是個大話題，不是一兩篇能搞定的。推薦一本范冰的《增長黑客》吧，里面更多的從技術角度上闡述了如何對運營效果進行改善，比較適合技術人員充電。
一、概述
從第一天早上10點的Idea到第二天凌晨6點提交上架，除去做飯+吃喝拉撒，總共花費約16個小時。復盤下來，覺得整個過程頗有代表性，故分享出來，供諸位拍磚。
二、工具清單
2.1 準備階段
思維導圖：幕布
小程序申請：微信公眾平臺
2.2 開發階段
2.2.1 后臺
版本管理：碼云
后臺開發IDE：PHPStorm
后臺框架：PHP + Laravel
數據庫：MySQL
微信后臺對接（Laravel插件）：EasyWechat
圖片存儲（Laravel插件）：Aliyun-oss-storage
2.2.2 小程序
小程序開發IDE：微信開發者工具
小程序：官方的文檔、組件、API
瀑布流展示（小程序插件）：BrickLayout曉瀑布流
2.2.3 設計
圖標：iconfont
UI參考：WeUI小程序版
編輯：Photoshop
2.3 運維階段
小程序助手
小程序數據助手
小程序客服小助手
三、開發過程
3.1 從Idea到動手
吃夠了不經調研的動手開搞帶來的苦頭，近幾年對于Idea到產品是頗為謹慎的。像這次干凈利索的決定，顯然已經是好久不見。
其實我是不推薦這么迅速的作出開發新項目的決定的，除非具備幾個因素：
項目開發周期短，1-3天為宜；
具備立竿見影的效果；
沒錢了。
從Idea到產品，首先需要梳理思路。
之前用的xmind，最近一直用新出的幕布，后者更方便分享，多端可用，比較適合國內的使用習慣。
時間緊迫，簡單畫了畫。如果是較大的項目，則需要有比較系統的思路。這里推薦下 processon，之前一直用他畫流程圖，最近發現它又新出了諸如商業畫布一類的工具，很好用。
3.2 著手設計
產品最終的形態，在開發之處最好是要有原型的，否則開發過程中，會逐步失去方向，被瑣碎的事情干擾，以致最終開發出的產品和最初的設想有很大出入。
產品原型的工具，在上面沒有列出來，是因為項目太小，畫原型圖在時間上劃不來。原型圖的工具推薦下墨刀，和幕布一樣，也是可以在線分享演示的，這在團隊協作和給客戶演示時非常方便。
這次的設計，就是完全在腦子里打了個草稿，又去找了找同類型的產品取了點經，一個大概的產品模型就有了。
至于風格什么樣，那就只能靠天吃飯了。因為這么短的時間，不可能去動用設計的兄弟，所以就在 iconfont 和 ooopic 一類的設計網站上找靈感。
好在iconfont上剛好有一組圖標，與心目中的產品比較契合，果斷下載。
至此，logo、圖標、框架等都齊了，開始最激動的擼代碼階段。
3.3 擼代碼
一個人搞定前后端，這里面就有些門道了。
先干啥后干啥，每個人的喜好不同。
以效率為出發點，我有如下建議：首搭框架，先前再后，先橫再豎，敏捷交付。
首搭框架，是指先把前后端的基礎框架搭建起來，該配的基礎功能先做好。比如Laravel的本地調試環境、代碼倉庫、云端服務器、備案過的域名、小程序的賬號、業務域名配置等等，這些環節先在腦子里過一遍，再從頭到尾整個做完。
之所以一鼓作氣全部做完，是因為在后面編碼的過程中，一旦被上面一些小問題卡住，思路就容易被打亂，影響效率。并且，很多事情是需要較長的時間的，比如域名備案，慢的話就得一二十天，如果被域名卡住，項目流產的可能性就會直線攀升。
第二是先前再后。這個意思則是在開發某個功能時，先設計前端界面和邏輯，再做后端接口和數據。反過來不行么？行，但是不好。
在這種快速迭代開發的情況下，前端頁面和邏輯沒有經過系統的設計，會經常發生變動。這和傳統團隊開發不太一樣，沒有概要設計到詳細設計再到開發的過程，更沒有并行開發的條件，因此要因地制宜，采取更適合這種小型作戰的方式方法。
當然，這個建議重點關注的是具體的功能開發，而不是完全取消前置設計。如果沒有整體的框架設計，是萬萬不行的。
第三是先橫再豎。我們從水平和垂直兩個方向，去劃分具體的功能。
比如這個項目中有四個頁面，分別是發現頁、發布頁、個人主頁、以及單篇展示頁。我在開發時，先把四個頁面建好，把tab和圖標都加進去，頁面切換做好，先感受下最終的效果。這種方式叫水平開發，好處在于讓你會對產品的最終形態先有所感知，如果有不舒服的地方，及時地進行調整。
當我們對某個頁面，或者某個跨頁面的功能進行開發時，則稱之為垂直開發。此時的功能顆粒度就會相對較小，也更容易把控。
最后是敏捷交付，是脫胎于敏捷開發模式的。意思是要持續的向客戶交付可用的產品，這里的客戶就是開發者自身。
在前幾個原則的基礎上，要實現敏捷交付，還應該注意不要被細枝末節的點牽絆住。比如某個圖標的配色不好，某個按鈕的位置擺的不正等等。切記，一定要抓大放小，美化完善的工作一定放在最最后。再者，一款產品就是要在不斷的打磨下，才能奔著精品而去。
3.4 運營準備
一個產品的啟動是很有講究的，尤其是社交和UGC產品。當一個用戶初次使用時，如果覺得你這個產品冷冷清清毫無生氣，是很難沉下心來去體驗的。所以，適當的“作假”是提高用戶體驗的增長黑客手段。
在產品達到一定量級后，一定記得把這些措施去除。比如王者榮耀的排位匹配，當你的等級很低時，會匹配一些AI機器人陪玩，以鼓勵玩家。當到達人數比較多的等級階段時，就會降低AI機器人的比率，因為讓用戶等待時間過久，是一件體驗非常不好的事。
同樣的，在我們這個產品中，用戶發出去的文章，在達到一定時間內，應當引入一定的激勵機制，以鼓勵用戶。當用戶較多時，真實的互動足夠激勵用戶再創作時，則可取消激勵機制，徹底度過項目的冷啟動階段（時間關系，當前版本并沒有加入激勵機制）。
四、擴散
如上所述，這樣一個產品，站在前人的肩膀上，可以快速搭建一個簡單的MVP，而之后的運營和迭代才是難中之難。
首先，任何的迭代開發，要保持一個大方向不動搖。換句話說，產品的調性不要輕易改變。
比如做上面這樣一款社交產品，就扎扎實實圍繞社交打磨功能，當可以成為精品的時候，再考慮逐步橫向拓展，諸如廣告、帶貨、游戲等。
微信就是一個很好的例子。
近幾個月，微信動作頻繁，上線了一大批變現功能，并且前提是以用戶體驗不受較大影響。社交是微信的方向，是微信的固有屬性，根深蒂固；如果把這個根基動了，上層功能模塊也便不牢靠了。
對面的支付寶，不斷創新，不論從功能還是排版，均發揮了產品經理極大的腦洞。結果是最終偃旗息鼓，不再大動社交的腦筋。
其次，產品初期的迭代要根據市場反饋靈活調整。市場反饋怎么看？數據。像微信小程序，就給出了相當完善的運營工具，其他諸如阿拉丁第三方工具，也可以作為不錯的輔助。
具體怎么玩呢？看活動效果，看推廣渠道帶來的指標增長，看某個功能調整帶來的用戶波動，等等。這是個大話題，不是一兩篇能搞定的。推薦一本范冰的《增長黑客》吧，里面更多的從技術角度上闡述了如何對運營效果進行改善，比較適合技術人員充電。
訪問手機端更方便
技術創造價值 服務締造品牌
Copyright ? 2011-2024 鄭州開拓者電子科技有限公司 All Rights Reserved
友情鏈接：
小程序開發