錯過
剛開發完一個小程式，這是小程式正式釋出3年來第一次實操。
2017年初，聽說微信將要上線叫“小程式”的產品，內心充滿嚮往和猜想。當時正趕上公司在討論學生產學結合專案問題，我感覺發現了新商機，當天晚上醞釀了一份方案，第二天就和老闆探討要如何開展。後來我離職了，之後也並沒有這小程式上投入精力。
2017年以前我一直很遺憾，2013年微信推出服務號開放介面時沒有投入微信營銷系統開發。那時候因為還沒有拼多多、有贊、微盟這些依託微信開源功能崛起的公司。網際網路圈外的人都對微信公眾號商城，互動小功能很好奇，很多傳統行業老闆都趕潮落，花幾千塊錢搞一個公眾號，覺得很高大上。眾多小公司用開源原始碼嫁接到新公眾號就賣幾千到數萬元。
有同事的前公司，是四五個南方人在賓縣開的公司，1500一個月的工資僱幾個客服，通過搜尋引擎廣告接單，一年有幾千萬的收入。
2017年面對微信小程式的推出，對於深度研究過公眾號開放介面的我來說，知道這又是一波好紅利。然而對於一直為眼前的苟且奔命的我來說，這三年前在小程式方面碌碌無為！
這三年，我研究過很多小程式的商業模式和落地營銷問題。但一直沒有真正實踐過一次！！！當然了，這這種碌碌無為也發生在任何一件新鮮事物上，包括短視訊、直播及眾多新生的新媒體平臺。
相識
小程式開發基於web前端技術，對於具備開發經驗的人來說沒有太多難度。這次疫情工作生活情況大變，有了機會實踐開發小程式。我分享下最近這段時間開發過程中遇到的新鮮事和隨想。
百度小程式目前已經和他的資訊流、百家號、搜尋結果相結合，聽說百度小程式和國內其他十幾家網際網路小巨頭比如攜程、快手相合作，實現小程式聯合，而今結果怎樣並不得知。
技術方面都基於web技術，都要用到JavaScript，甚至都是一樣的框架思想。
因為我用用小米手機，因想要個型號完善一下手機功能，前幾天研究了小米的“快應用”開發文件。就是小米左側和下面負一屏的那些小圖示，開啟類似app又不是app的應用。
他的“快應用”也一樣是使用web前端技術編寫。其實“快應用”可以說就是小米MIUI的“小程式”。
微信小程式2020年之前只簡單看過他的開發文件，同時也沒使用過vue，只知道vue是一個JavaScript非常流行的框架。對於JavaScript的這種自下而上用法還是覺得很新奇。可能只是先入為主的原因，之前我對JavaScript程式設計思想還是比較狹隘。
思想
說起程式設計的開發思想的先入為主，我是先接觸的前端，而後php的cms系統、php、資料庫、網站開發、微信公眾號開發、app開發、python資料分析、vb、再到微信小程式和vue，中途也了解過c++、安卓、java。每一次接觸新的技術都會覺得“原來一切可以是這個樣子”，發現之前對於技術的理解確實有些狹隘了。
很多次有人問我程式開發對個人有什麼要求？開發難嗎？不同程式語言有什麼區別？
我都是尋找其中的共同點，籠統的概括，說做程式都是數學，程式設計主要靠邏輯思維和想象力，就是將人的邏輯用程式表達出來而已。
我覺得這樣的回答是客觀的，簡要而又全面，很酷！
但其實把程式開發說的細化一點，說一說不同程式開發的區別，不同思想給人的啟示，也是很酷的一件事。
2014年第一次接觸微信公眾號開發文件的時候，那時候第一次接觸“介面”概念，當時的程式設計水平只停留在網站開發階段，程式設計思想也就是前端、資料庫、伺服器這三個緯度，看微信的開發文件覺得簡直是天書。
第一類，和我一樣，之前沒有進行過介面開發，對接第三方平臺這類工作。
第二類，之前做過介面開發，比如硬體開發，自動化開發，醫療裝置開發，或者淘寶介面開發。
第二類會覺得稀疏平常，沒什麼了不起，同時也沒勾起什麼興趣來。導致也傲慢與大意使其大部分程式設計師也被拒之門外。想必這也是2013、2014年從事微信商城開發的公司並不太多，直到四五年後才輪到拼多多把各種花樣玩個遍。
所以對於一項新技術或者新商業模式的出現，能以一顆永遠好奇的態度，投入點精力研究總是好的。就像是現在大部分商城、app、軟體服務公司、上游到小米這樣的再開發安卓系統，下游到“客如雲”這樣的終端收銀裝置、電子秤。都有了強大開放介面。而網際網路從業者們並不知道，很多技術與商業模式的出現都是四五年後才會廣泛普及。這使得錯失機會的我們來說倍感慚愧。
傲慢
隨後的幾年“玩弄”過幾乎所有微信開放的功能，我也揚言每一個細小功能我都能寫大量文章、出課程、編寫出各類花樣。顯然我後來只是想想、說說罷了，沒有去做。
2017年開始接觸app開發，再一次滿足了我的好奇心，覺得好玩的事情又多了許多。
關於手機app開發和其他開發的相比，要說它沒有區別，其實確實都是數學而已，都是將人的思想用程式來表達。有人問我某某功能能不能實現，我都是高調地說，只要人能想明白的功能，程式就能實現。
但就像人活著每天就是吃飯睡覺一樣，完全可以在看似一樣的事情中挖掘出更多不同來，從中尋找出不同的快樂與意義。這也正是很多高階程式設計師都對藝術痴迷，甚至可以在很多程式設計中看到藝術的美一樣。像蘋果創始人喬布斯就是很懂藝術，聽說他研究過中國的書法，現在用蘋果的筆記本寫下這些文字，也真是覺得蘋果電腦的設計確實是個藝術品。
升級
正式參與app專案是2018年加入的外賣平臺公司，從事產品經理。一年多的工作並沒有什麼成效，但個人來講收穫還是很大的。我認為退伍後2018年收穫最多，當然2019年比2018年還要多。
單純在技術角度來講，app開發採用介面請求、json資料前後端互動、json解析渲染前端、版本管理、推送處理、系統許可權、藍芽裝置對接、系統相容性這些方面和web開發說不同的邏輯。當然這對於從安卓或ios入門程式設計的人來說覺得一切都“事情本該有的樣子”，從web前端入門程式設計的來說覺得很有意思。
從此以後考慮程式的角度要更多具備空間立體思維。但從考慮的要素來講，管理app專案比存web多了不值10倍。所以管理app專案非常操心，再加上還要考慮服務端問題、資料庫問題、相容問題、bug檢測等，絕對會讓公司成本越來越多，並且還會存在很多的隱患。也奉勸那些沒事就考慮找個外包公司開發一個app的個人和企業，打消念頭，慎重考慮。
要說樂趣，就好比之前玩的是跳棋、動物棋，這回終於能接觸到象棋圍棋來。工作豐富了許多，也有種掀開鍋蓋看到美食的感覺。
app專案除了這技術和程式設計思想上更加具備立體感以外，其實是讓我知道了一個網際網路產品的運營，團隊管理實在是太重要了，遠遠超過程式本身。
不過程式其實也是團隊管理的一部分，團隊管理不到位是組建不起來一個技術團隊的。至於管理有多重要，不親身經歷確實很難體會的到，就像沒有吃過蘋果的人是想象不到蘋果的味道一樣。
不過不得不說app處理相容性很麻煩、測試很麻煩、版本迭代很麻煩、修復bug很麻煩、資料庫優化很麻煩、伺服器負載均衡很麻煩、ui設計細節非常多。而這些都是不做不知道的，這也大大增加了各個公司後續的成本。
當然更難的是如何讓技術緊密的、精準的配合自己的商業模式。這點最重要，難度也最大，正所謂方向比選擇更重要。
總之app產品的運營管理成功率是很低的，難度方面絕對是不做不知道。
發現
這份工作對於我個人來講沒有太多經濟收穫，但艱苦的過程還是值得回味的。讓我有了較為豐富的專案管理經，對程式設計思想、專案管理等方面有了新的見識。過程中也想過每一種技術與模式存在的必要性，也想過如果有另外一個人類世界，一切會不會有全新的模式出現。
比如現在絕大多數的網路公司都是以自己的app為載體，所有的資料呼叫都是受他本身的佈局UI限制的。比如知乎app、和快手app，我知道它裡面有很多我未發覺的內容，但一切都被它平庸的搜尋框和腦殘的推薦功能所制約。有一種院內春光無限好，但怕紅杏出牆來的感覺。但能不能完全換一種方式來互動，比如對所有有開發經驗的人開放一些介面，讓所人都可以根據需求個性化的獲取自己想要的內容呢。
比如快手，有時候我真想只看看某一類最火的視訊，能讓我快速、精準的看到，但同時必會因為看了之後一段時間全是相關推薦。我相信如果一切可以重來，那麼不一定非要像現在一樣，網路公司盈利就是靠把使用者圈到自己的app裡，承受其狹隘的UI限制。
我相信一切我們習以為常的事物都可以換個角度重新做一次，就好比微信小程式框架、vue框架就是打破了JavaScript以往應該有的樣子，換了個姿勢，新添了不少魅力。下面不談太多商業模式方面問題，主要再說說小程式技術方面的問題。
契機
小程式算是一種新的終端、一種新的UI規範、一種新的互動邏輯。重點提到微信小程式，我覺得它最大的好處就是和微信的血緣實在太濃了，可以說它是微信的一個器官。
好處就是效能相容性強，頁面設計方面很多問題微信官方都考慮到了，不用考慮全面屏、解析度等問題。推送問題基於微信訊息，支付、授權登入、手機許可權等微信app本身都做好了相容問題。與其他小程式、微信公眾號可以實現非常好的資訊資料合併與共享。不用考慮太多系統層面效能問題，比如是否會殺程序，藍芽版本支不支援等這類問題微信底層已經定了，就不用再浪費精力除錯啦。版本管理方面不用考慮多版本資料相容問題，其實是一個實現產品快速迭代的好契機。
今天這篇文章我是想要分析一下微信小程式技術問題，但寫著寫著還是覺得一切技術都不重要。發現確實一切都是數學問題，雖然各有差異但本質相同。可任何技術幾天可以學會，但其應用的模式、思想、對其態度問題卻是一輩子的事。圍繞小程式問題我會持續研究，會參與開發一些實用的專案，會研究一些小功能，不定期寫一些相關分享文章。
分享
下面整理一下最近一個月，親身實踐小程式的開發後，值得像技術同人分享經驗：
第一，如果時間可以最好每個人或團隊要有一套自己的架構。包括設計規範，json規範，以及是否適用自定義元件、構造器這些常見的。整個架構互動邏輯最好是自己的，不要往上購買個其他人指望後修改。因為小程式框架本身微信團隊已經盡力完善了，而我們還去購買他人框架長遠來看麻煩會很多。
第二，小程式流暢度上我覺得能得70分，和精細化開發等原生App沒法比，但比很多小公司粗糙設計等原生App要好些，小程式既然屬於快應用，那麼最好不要走極簡路線，不要過於臃腫。
第四，關於拷貝他人程式最好是逐個小功能下載，我發現功能越深細分越能滿意，如果複製別人程式太多沒有好的，並且浪費時間不值得。
第五，其實設計到的各類計算，我覺得還是交給服務端較好。既然是“小程式”，“快應用”就要把它的“小”和“快”發揮到極致，無論是客戶體驗還是產品維護迭代都是。小程式程式碼裡面放太多絕對會大大降低迭代效率。
第六，這產品屬性上講，我覺得應用可以分為功能目標實現型和消遣型，小程式就是作為某種功能的快速實現最好了，不要指望客戶將其當成消遣工具。
第七，編輯器ctrl+s就可以載入渲染預覽，有他方便的地方，但因為方便總這樣去做，也會浪費很多時間，所以要節制。
第八，很多元件的預設屬性（ css）樣式很討厭，有的很有用，有的很討厭，並且清楚預設屬性的方法和網頁web有所區別，記得陷入誤區時候儘快搜尋解決辦法，不要用蠻力。
第九，我覺得自定義屬性、構造器這些功能能方便工作，以及大專案的管理，但如果並非必要可以不用，太浪費腦細胞了。
第十，純網頁web前端程式設計師，沒接觸過vue，沒接觸過小程式和app開發的夥伴們第一次接觸可能會覺得有難度，但不要放棄，邁過這道門就是一個新世界。願我們每一天都鄙視又尊重我們過往的歲月。
第十一，因為小程式的不確定性不是特別多，所以遇到的問題多數都可以查到解決方案。我想遇到問題不用蠻力，尋求他人幫助是十分好的品質。
第十二，小程式屬於“麻雀雖小，五臟俱全”，應用價值大於技術價值，所以程式設計師實踐一下沒有壞處。
對於產品經理，網際網路行業創業者而言分享一下我的經驗和感觸：
第一，不要問小程式和網站、公眾號、app有什麼區別。有這個問題本身就是問題，這就是一個思維誤區，會使我們陷入外在形式本身而忽略問題本身。我們只要把所有精力放到我們要實現什麼商業目的，希望解決什麼問題才是核心。
第二，小程式絕對比app成本低很多，沒有app運營經驗或專案管理經驗的創始人，同時也不是單單想“圈錢割韭菜”的話，還是不要上來就花大價錢開發app。另外不要找外包公司！不要找外包公司！不要找外包公司！
第三，如果產品經理或創業者不懂技術，但要了解一下小程式到底能實現什麼功能，公眾號能有什麼功能，各個平臺，都有什麼功能，這些功能都有什麼用處，這個對於所有網際網路創業者和產品經理而言都是有十分好處的。否則就會想是黑夜裡開車不開燈，每一寸都是踐踏生命。
第四，產品經理和老闆的指責是把一切問題都梳理清楚，世界的現實複雜性總是遠遠超出我們的想象。很多邏輯要走自己腦子裡先梳理清楚，越透徹越好。就像沈騰主要的《飛馳人生》一樣，要在腦子裡模擬賽道無數遍。這樣開發出來的產品會完全不一樣，會省去大量的開發成本。
第五，一般而言初始技術團隊，開發一個適用的小功能，一個服務端、一個前端、外加一個ui設計就可以了。當然那種一個人可以即做服務端又做前端的最好，其實這樣的一個人全包並不比前後端兩個人做慢，兩個人會浪費很多溝通時間。
第六，第一版本要極簡，並做好快速迭代的準備，同時要講流程梳理的越清楚越好。我見過太多的專案會犯兩類錯誤。一是，第一個版本做的功能臃腫，二是，還沒想好就開始做。發現過程中問題越來越多，浪費時間不說還很容易走錯方向。功能極簡且清晰，考慮周密且深遠。這兩方面有些矛盾，但做到了就是藝術了。
第七，新時代每一種技術、概念離我們並不遠。每一個人快速入門都並不難。比如資料分析，90%的創業者們要麼不知道，要麼只知道模糊的概念。其實深度研究一下是非常有必要的，如果講資料分析慢慢的植入到你的小程式中，會對運營和產品迭代非常有幫助。
第八，小程式給創業和產品運營帶來了諸多好處，提供了便利性，降低了開發和運維成本，但這應該是使得我們講更多精力和成本放到產品的商業模式本身上，讓我們迴歸商業與管理的本質上才對。有了一把好的刻刀，我們考慮的應該是如何更好的發揮我們的技藝，而非覺得刻刀可以取代技術。
下面針對實體行業老闆給予一些忠告，如果你是從事餐飲服務，教育，銷售代理等等行業的，利用你要怎麼樣更好的利用小程式。針對這方面問題下一步是我工作的重點，將來會用更多的篇幅進行分享。這裡只解釋一些你們可能存在的疑問，及切實可行的一些忠告：
第一，如果多少能擠出一點精力，也不差一年幾千塊錢的前提下，那麼可以做嘗試。
第二，最好先想好用它來幹什麼，是作為課程分享、是純銷售、是商城、是對接現有工作流程還是搞促銷。當然做好了一個程式這些目的都能實現，但最初往往是目標越單一越好。
第三，關於目的性，雖然傳統老闆可能對網際網路並不了解，但還是要能清晰地描述出你自己用小程式到底要實現什麼，杜絕一切模糊的概念。如果說不清還是別做了，因為你根本沒想好，並且你也沒想真正的做好，你的努力將是徒勞的。
第四，如果單純想靠它賣東西，還是推薦直接買有贊、微擎這兩家，買個最低配就好了，其他小公司盜版的便宜，但常常會被騙，浪費感情讓你對其失去信心。
第五，如果是做課程的，那麼我看很多公司用“小鵝通”的，購買基本會滿足你的大多數需求。
第六，不要相信很多“大師”課程給你推銷的商業模式或者程式。雖然你可能不懂技術，但具體實現什麼功能這方面最好不要超過你的認知範圍。我相信腳踏實地，並且願意嘗試新事物並存是一種非常好的品質。
第七，先考慮我有什麼東西要用網路來賣，我有什麼資訊想通過網路來傳播，我有什麼營銷套路想要如何實現，這些都考慮好了再從一點出發。如果你是飯店，想做一個每天餐品秒殺的功能，你非常清楚這個功能做完後你怎麼配合這個功能完成服務，確定你會長期開展這樣的服務。這時你完全可以單獨要這樣一個功能的小程式，發現確實很好用，對經營有幫助了再逐步拓展。
第八，如果是大公司比如餐飲連鎖，那麼最好要找一個有商業思維的且懂網際網路的產品經理來負責。但要遵循快速迭代，清晰簡潔的功能規劃，有效果評估體系，最好做實踐之前做好流程演示考慮到任何意外狀況。否則多半會讓你失望……
第九，如果你購買的是有贊或者微擎，裡面的小功能都可以嘗試一下，但要一個一個嘗試。每個用好了都會是屠龍刀、倚天劍，但用不好害人害己。
第十，初期假設先不要想我做成了會怎樣，而是怎麼能有點小成效。比如你是一個理髮店老闆，如果你想的是以後我就用小程式預約，請購商品，客戶選擇髮型等等，而後你就開始購買或者定製程式，那麼你幾乎一定會失望。產品功能哪怕出來了你會發現你的小程式只是一個空殼子，只說擺設，根本無法和你現在的流程對接。你甚至會發現上傳發型圖片都是一件很難的事情，而預約也是擺設，完全不實用。所以現實的從一點入手，想一個小功能如何實現，這樣一步一步完善。你才會領先於同行業發展。
每一個詞語都是一個概念，每個人對每個概念的理解是根據個人精力而決定，或者說每個詞字對於每個人都是一個截然不同的故事，我相信《新華字典》對每個詞語的解釋並不能詮釋我們的寓意。針對我提到的每個一詞語或概念，今後都會和大家討論。