吳旻泰巖網路工作室
我自己的小孩就是獨生子女，所以在這裡我沒有說獨生子女如何如何不好的意思。
最近接手的幾個程式都發現原來的程式設計師使用了大量的「單例項模式」。單例項模式的本意是說程式中如果有多個，那是不允許的；而我接手的程式中，之所以這麼做，完全是因為當時的程式設計師覺得有乙個就夠了，而不是不能有多個。相反，當我覺得如果有多個例項，程式的安全性和架構會更好一些時，我失去了快速重構的可能。我必須將遍布於整個程式中是單例項分離出來，將程式模組間的耦合開啟，才可能做更進一步的重構。
乙個單例項和乙個獨生子女有些太像了，總之是不能再有第二個。其實不是不能有第二個，而是原來的程式會「想盡一切辦法」阻止我使用第二個，讓我必須按照只能有乙個的思路來。這就像政治上一旦對某個事件定了性，想盡快修改，可就是難上加難了。講實話，原來的程式根本沒有打算阻止我使用第二個，但他隨意使用單例項，客觀上造成的結果是我只能按他原來的思路來，要不然就困難重重。相當於說：改革是可以的，代價是慘重的。
不改，是沒有出路的，改，代價又是慘重的！這就是現狀。
我有點不太理解為什麼這種程式的適應性會這麼差。或許是最初的程式設計師沒能理解程式作為整個系統的一部分，是會遇到其它介面的瓶頸的。比如，網路傳輸需要時間，磁碟讀寫需要時間，資料庫查詢需要時間。總而言之，原來的程式設計師覺得這個程式是最重要的，所有的其它部分都是配合它而且不需要時間的，如果其它部分不能配合，那就是其它部分的問題了。如果眼下效能出現問題，那調整其它部分的代價是高的，但修改這部分程式的代價一定是最高的！
其實多數獨生子女不會覺得自己在家中是最重要的，但是他們會意識到別人拿他們是沒有辦法的。他們只要既成事實，家長就會因代價的選擇而不得不預設什麼。我接手的程式，大意也是如此。
希望以後能少接一些這樣的程式。
微信小程式開發之頭像是Emoji表情的儲存問題
只能儲存3個位元組，而 emoji表情有些需要佔4個位元組。這時就需要我們修改資料庫的編碼格式了。首先，我們新建資料庫時選擇utf8mb4編碼，相應的表中字段也設定成utf8mb4編碼 設定完之後，可以在資料庫 查詢 新建查詢裡執行一下下邊的命令，檢視資料庫的編碼格式是否改成utf8mb4編碼 sh...