github精選編寫可迭代，可測的小程式

github精選：編寫可迭代，可測的小程式。

把玩過小程式開發的朋友應該都有一種直觀的認識：

api 高度封裝，精簡

元件豐富，足以滿足日常需求

官方工具齊備，雲端解決方案到位

顯然，微信團隊以折損自由度的代價，輔之完備元件，配有一站式工具，換取傻瓜式的開發體驗。

以此來博取開發者的青睞，甚至「勾引」零基礎的人來嘗鮮，以淡化人們對 wxml 這種全新的、封閉的 xml 拓展語言的牴觸心理。(人們理所當然擁抱 h5 這種 w3c web 標準規範，卻不一定願意傾注時間和精力去學習一門封閉式、非標準化的私家語言)

拋開其他不談，單就門檻而言，已經將到極低。

這容易給人造成一種假象，即小程式沒有啥技術含量，所有的能力框架已經給出，原本需要乙個月週期的 web 、 app，用小程式實現大可縮短到 1 至兩周。

讓這個結論成立，得滿足乙個前提，即只負責功能的實現，不考慮可迭代性或可測性。

然而不可迭代亦不可測的應用程式，我通常認為那只能是玩具 demo。

網際網路應用程式從來不是一觸而就

生活裡，工作中你所使用過的任意一款應用程式，哪怕是功能極簡，哪怕是採用了某高大上框架開發，都離不開軟體層面的構架設計、迭代計畫和各類測試。

言下之意，好上手是一回事，把東西做好則是另外一碼事。

so，忘記小程式的便捷性吧，那只是個幌子。

正確認識小程式開發

wxml，玩過 vue 嗎?相似度高達 80%，玩過的話，掃下文件就可以上手擼個 demo;

玩過 react 嗎? 元件化思想和生命週期 hook 函式一樣一樣的，玩過的話，只需熟悉下新語法;

如果曾經玩過 angular，簡要替換下，還是可以快速上手;

如果玩過 react native，那麼這只是一次平滑的遷移。

說到底，小程式的意識形態可以說是國人首創(人口福利造就了微信，張小龍的野望，讓 wxml 有了載體，不然這種只能跑在某 app 裡的全家桶，誰會來玩呢?如果印度也有「啊三信」的話，小程式這種形態也是可以複製的)然而小程式的設計模式，實現原理，只是借鑑、沿襲了時下幾大趨勢：元件化，js膠合。

只要是遵循元件化思想，總能從前端三大框架裡找到影子，只要是 j**ascript 驅動，就可以復用狀態機概念：redux

言下之意，號稱簡單易用的小程式，終究離不開 view 層的狀態與互動，資料流的繫結與控制。幸運的是，這些都有現成的解決方案，不幸的是，你必須用這些解決方案，否則在產品的路上，要分分鐘失控。

現在來思考小程式的實現，該如何分工

業務邏輯、資料流控制、靜態資源、類庫、工具函式和模版&通用元件應該相對解耦。可以通過目錄結構來直觀地分配。

actions/

getrecords.js

getrecords.test.js

common/

constants.js

strings.js

apis.js

images/

logo.png

layouts/

home-list.wxml

libs/

redux.js

pages/

home/

me/reducers/

home.js

me.js

utils/

gettoken.js

gettoken.test.js

formatdate.js

formatdate.test.js

app.js

app.json

app.wxss

我用了 redux 所以會有 reducers 和 actions 目錄。 reducers 存放每個 page 對應的邏輯分發和資料同步; actions 目錄存放每一次 view 的互動邏輯，這兩者是一一對應的，熟悉 redux 的一目了然。

common 目錄存放一些常量、字串、api 資源以便統一配置、呼叫。

layouts 目錄存放一些通用模板，或者說可復用的元件，遵循元件化思想，盡量不重複自己。

utils 目錄自然是放一些和主業務邏輯無瓜葛的通用工具函式。

其他目錄無需贅述，都是些基本的命名和用法，這裡面沒有 test 目錄，整個專案的邏輯已經被 redux 解耦，所以我直接在 actions 目錄裡寫一些功能測試，在 utils 目錄裡寫單元測試，主要是引用方便吧，借鑑了 facebook 的 create-react-app 的做法。

說點和 redux 相關的

github精選編寫可迭代，可測的小程式

可測集的性質

Python可迭代跟迭代器的區別

python當中的可迭代物件迭代器

github精選 編寫可迭代，可測的小程式

可測集的性質

Python可迭代跟迭代器的區別

python當中的 可迭代物件 迭代器

相關推薦

github精選編寫可迭代，可測的小程式

python當中的可迭代物件迭代器