最近這半年，我花了不少時間將五年前做的Tasmap給商品化，也檢視了五年前的自己是如何設計架構，以及實作程式的，這裡記錄一些我的想法。
Meta很重要
從現在看來，我的原則以及想法是正確的。有一些可以更精練，更細化的部分，但核心思考的可靠性讓我即使過了五年也不會有「咦？這三小？我在幹嘛？」的疑惑。我認為整理自己的meta是一件很重要的事，這可以幫助你在遭逢挑戰時有穩定的核心，並且可以一步步根據新學到的經驗來擴張他。
你也該有自己的meta。
時代下的「最佳實踐」並不重要
從現在來回顧的話，我在五年前寫的code都是當下的「最佳實踐」，但用現在的角度去檢視卻已經不是「modern pattern」。當你使用所謂的「最佳實踐」的時候，你必須很清楚「為什麼？」。還有，相信你的直覺以及品味，而不是別人的話語。近幾年（特別是20年之後），技術圈變得非常的商業化，各種誇大、炒作及行銷非常的嚴重，你必須有良好的「技術識讀能力」來作出選擇。就像投資一樣，聽著別人的話語而隨之起舞，下場多半是韭菜。
我很喜歡巴菲特的一項原則：「我不投資我不理解的東西」。這放在技術選型上更加重要，因為技術環境是一個更加封閉而理性的環境，基本面的成分比遠高於認知面。兩個原則：
- 不要使用你不理解的技術。如果你不理解他大概是如何運作的，別用。
- 如果他原理上有問題，實際上就有問題。計算機科學裡沒有黑魔法。
我還記得這句話：「Dirty digest is fine」。Angular 1教會了我質疑那些閃閃發光的技術大佬。
基本面與市場面
投資時有基本面以及市場面，技術選型，框架，庫，架構設計，代碼風格也可以套用相同的判斷框架。基本面是指一個東西的技術原理，以及一些客觀指標（例如時間複雜度，空間複雜度，有限情況的測試結果），市場面指的是團隊資源，人才市場，作者，流行程度等等。當基本面遠大於市場面的時候，代表成長空間有限。當市場面遠大於基本面的時候，這是炒作。
平衡與取捨很重要。
造輪子吧
以前我們都說「不要重複造輪子」，但在現在這個時代，我覺得應該把輪子拿回來自己造了。最大的原因是AI。很多既定實現穩定的東西（例如in-men cache，image component）在以前是老手的苦力活，新人的練功房，現在都可以靠AI輕鬆完成。自己造輪子的好處就是百分之百的主控性跟百分之百的客製化能力。你可以保證這個lib完全依你的需求而打造，想要什麼就加什麼，而且不會因為一些五四三的原因出事（license轉私人，或是被塞一些奇怪的東西）等等。
如果說我對官方說法的不信任來自Angular 1，那我對開源專案的不信任就來自Ant Design。我還記得當天早餐的飯糰只吃了一半，就花了半天在找是誰在我的Dashboard裡放了「小彩蛋」。
防禦性模組設計
以長期專案來說，模組設計的重點可能不是擴展性跟可重用性，而是防禦性。這裡的防禦性指的是：
- 預防未來的變更
- 預防不可控的錯誤
大原則是：模組應該永遠輸出可預測的結果。模組的邊界應該能夠有效的控制模組內部不可控的錯誤及變更。只要達到這個目的，模組間的實踐不一致是可接受的，有時甚至會是一種分散風險的措施。
一致性是有毒的
我發現近幾年，「一致性」變成一個很熱門的buzzword，但我卻沒有看見他帶來正面的效果。大多數的時候，所謂的一致性被用來包裝「你給我這樣做」。
老話一句，先問「為什麼」。為什麼要一致性？一致性會帶來哪些正面或負面的結果？這個一致性適合這樣的環境嗎？我看過許多「架構師」在追求完美無瑕的理想代碼庫，對「一致性」有著強烈慾望，最後毀掉產品跟整個團隊。不只是架構師，很多掌控欲強的管理者都有這個毛病，而一致性在這種場合成了出征的「大義名分」。
有些東西必須有一致性：公司的文化原則及願景，產品的北極星，至於其他的東西，特別是底層執行，如代碼風格之類的東西，過度的要求一致性只會讓團隊背上無意義的枷鎖及造成爭執。你該使用的東西是「原則」，或是我一開始提到的「meta」，而不是一致性。
我甚至無法跟幾年前的自己達成一致性。
技術債不是債
技術債是個很通用的概念以及名詞，但是，這其實會造成一種錯誤的類比認知：欠「債」是不好的，是要還的。於是團隊為了所謂的「技術債」衍伸出許多糾紛：何時要還債，是誰欠的債，誰來還之類的。事實上，程式上的取捨和債務不同，他比較像是一種戰略安排：人力資源，時間點，投入期間等等因素。重點在於：你有沒有搞清楚這個選擇在什麼時間點會帶來什麼結果。
技術債不是債的另一個原因是：很多時候，技術債是可以不用還的。如果有個模組永遠都運作正常，那我其實不在意他裡面長怎樣，是王重陽還是哥布林寫的。如何「拿不用還的技術債開槓桿」是個很有趣的思考方式。
別擋AI的路
在Tiat中，有一個功能是「用畫的搜尋圖片」。簡單來說，就是給你一個canvas，然後像小畫家一樣畫個塗鴉，藉由這個塗鴉來搜尋圖片。為了實現這個功能，我花了不少的時間研究CV領域的相關知識。去年，有篇文章「苦澀的教訓」談到了近期CV的發展：人類的專家知識在訓練時已經成為一種阻礙，效果不如全都交給模型本身。
這讓我想到一件事：我們的編程風格，架構設計，最佳實踐，會不會也成為一種阻礙呢？會不會，AI原本可以產出更好的實作，但卻因為配合我們加上去的一些限制及指導，反而限制了他的發揮？
目前的主流意見是，人類會比較擅長高階的架構設計以及需求轉換，然後把底層實作交給AI。但我在想的是：這個前提是建立在人類擁有不平等的輸入量。如果輸入量相同，或者找到對AI更有效的輸入方式，人類的高階架構設計還會勝出嗎？
我在前幾個月有試著做過「AI優先的架構設計」，結果是失敗的。不過過程很有趣，有空再跟大家分享。
擴展現實的魔法
Application是一種魔法，一種擴展現實的魔法。魔法的本質是「實現你心中的想法」。想順暢的瀏覽百萬張圖片，想全自動整理所有檔案，想用Markdown寫Medium文章，想建立一張漂亮的地圖。Application是種魔法，魔法是為了實現你內心的想法，而想法則是由生活中孕育而生。體驗，感受，思考，交流，如此一來才能把無趣的火球術變成動人的煙火。