感覺已經好久沒寫程式了，最近這段時間，一方面是學習了python，然後折騰了scrapy框架，用python寫了下守護程序程式監聽任務以及用redis做佇列任務通訊，並開程序來處理爬蟲任務。以上這些其實沒啥好說的，就是順帶提一下。另外就是最近編寫segmentfault的講堂小程式，算起來，自小程式開始編寫到現在算是正式的上線，大大小小的也除了些問題，所幸都能及時發現並解決。

整套小程式開發過程中大概涉及到了幾方面的內容：

• 後端基礎業務邏輯服務部分；
• 小程式使用者與segmentfault原本使用者同步部分，也就是使用者繫結模組；
• 定時任務處理小程式太陽碼；
• 小程式介面佈局踩坑；
• 小程式介面使用踩坑；
• 小程式本身的各種配置踩坑；

後端基礎業務邏輯部分基本上不用做多說，同步本身講堂的程式基本就可以了，主要就是在使用者模組，這一塊一方面主要涉及到微信登入判斷是否曾經繫結過微信，另外就是判斷是否是新使用者。使用者繫結的邏輯主要複雜在既需要考慮微信本身的介面在不同情況下提供的資料不同，另外一方面就是考慮本身使用者模組的業務邏輯問題。當然還有新使用者註冊解決使用者名稱重複等細節問題，大大小小的問題加起來在這個看似的簡單功能上面解決了好幾次bug。

針對每一節課以及每一節系列課程生成小程式太陽碼主要涉及到幾個細節問題。首先小程式本身沒有提供一個用來生成太陽碼的測試介面，必須要小程式上線才行，所以這一步的開發很不方便，雖然是按照文件一步一步的進行編寫，而且也看似沒問題，但是其實心裡是一點底都沒有的，如果生成的太陽碼訪問不了，特別是如果攜帶的引數不對，壓根就不知道到底錯在哪裡，而如果要用小程式除錯模式看引數有何問題，那麼需要重新提交小程式稽核上線，一耽擱可能又是一天兩天時間，相當不方便。

另外就是太陽碼生成的話這裡其實有一個併發的問題，我原本的考慮是如果當前講座沒有太陽碼那就即刻生成，如果有則直接返回太陽碼。看似毫無任何問題，還是老大 @joyqi 問了我一句：“如果一次性訪問這個頁面有多個人咋辦？”，當時的那種感覺就是，似乎突然腦袋裡一道光一閃，臥槽，這種操作怎麼沒想過？特別是圖片生成本身就會消耗一定的時間，如果在這個地方有多個使用者同時操作必定會浪費大量的資源，記憶體，CPU，以及磁碟儲存，雲服務儲存等。最後當然就是乖乖的改成了定時任務處理了（當然也考慮過佇列任務處理，此處不做多說了）。

說到小程式本身，那就是切記要看清楚小程式開發文件後面的Bug & Tips

經歷了這次小程式開發後，要說感悟的話，估計就是對segmentfault本身的業務邏輯是更熟悉了，另外最大的感觸就是感覺做小程式既不像是做前端，也不像是在寫APP，這種感覺...無話可說。

最後非常感謝公司各位夥伴給予的支援和幫助。

原文地址：https://segmentfault.com/a/1190000016011830