如何管理工具函数
近期维护项目时发现有许多通用的函数散乱的分布在项目当中，于是趁有空时整理出一个统一的结构规则以便团队使用。很多时候我们对这些通用工具函数的印象只停留在要抽离到某个文件夹，至于要怎么管理或是维护这些函数就没有太多想法，导致许多乱象产生，像是：过度抽象、意义不明的命名、神级函数。
I found many common functions scattered throughout the project. So, I took the opportunity to organize a unified structural rule for the team to use.
我之所以调查这个主题，是因为目前所在的团队大量使用这种模式，但 Vite 在开发中不进行 Tree Shake，导致每次开发环境都有大量无用代码被打包，严重影响开发体验。因此研究一下这种方法的理念与优缺点以架构更好的项目。
Vite does not perform Tree Shake during development, leading to a lot of unused code being bundled, severely affecting the development experience.
會想調查這個主題是因為目前所在的團隊大量地使用到這樣的模式，但 Vite 並不會在開發中進行 Tree Shake 就導致每一次開發環境都有大量的無用代碼被打包進去，嚴重影響到開發體驗。因此研究一下這種方法的理念與優缺點以架構更好的專案。
前面写了一篇文章关于 ES6 JavaScript 当中的内建数据结构： Map，这次来谈谈 WeakMap，它又与 Map 有什么不同呢？会发现 WeakMap 相较 `Map` 少了非常多可用的方法，这是因为它们的根本处理数据的方式不同，Map 是强引用，而 WeakMap 是弱引用。
I previously wrote an article about the built-in data structure in ES6 JavaScript: Map. This time, let's discuss WeakMap and how it differs from Map.
前面寫了一篇文章關於 ES6 JavaScript 當中的內建資料結構： Map，這次來談談 WeakMap，它又與 Map 有什麼不同呢？會發現 WeakMap 相較 `Map` 少了非常多可用的方法，這是因為它們的根本處理資料的方式不同，Map 是強引用，而 WeakMap 是弱引用。
从很早以前就大致知道浏览器开始推出 Web Components 相关 API 与标准，但一直没有机会在实战中使用这项技术。想撰写这篇文章记录是因为随着时间推移发现 Web Components 的应用范围越来越广，因此趁着有空也来了解一下相关知识，并且分析它与现有的解决方案有什么不同。
Browsers began to introduce Web Components related APIs and standards, but I never had the chance to use this technology in practice.
從很早以前就大致知道瀏覽器開始推出 Web Components 相關 API 與標準，但一直沒有機會在實戰中使用這項技術。想撰寫這篇文章記錄是因為隨著時間推移發現 Web Components 的應用範疇越來越廣，因此趁著有空也來了解一下相關知識，並且分析它與現有的解決方案有什麼不同。
近期我对自己看待撰写程式这件事有更高的期许，除了最基本的效能、阅读性、扩充性……之外还有一个非常重要的领域就是：测试。不过程式好端端的能动就代表测试没有必要了吗？在我刚工作时实际上做了一段时间的自动化 QA 工程一段时间，不过那时候的我其实也并不明白写测试的原因，就是有程式就拿来自动化测试，并没有想太多。
Recently, I've set higher expectations for my programming, and testing has become a crucial area. But does a working program mean testing is unnecessary?
近期我對自己看待撰寫程式這件事有更高的期許，除了最基本的效能、閱讀性、擴充性……之外還有一個非常重要的領域就是：測試。不過程式好端端的能動就代表測試沒有必要了嗎？在我剛工作時實際上做了一段時間的自動化 QA 工程一段時間，不過那時候的我其實也並不明白寫測試的原因，就是有程式就拿來自動化測試，並沒有想太多。