當要建立新專案時，都會需要決定一些關於基礎的架構或開發規劃的事項例如 :
- 設計 folder structure
- 打包編譯工具的選擇
- IDE 預設環境配置；IDE plugin 或 extension 的安裝
- CI/CD、IaC 設定或工具選擇
每次建立專案時都會參考之前的架構規劃，然後手動複製架構雛形，重新設定參數，其實不太方便… 這時就可以引入 Scaffold 這樣的模坂概念，來直接生成專案的骨架。本質用意是把那些重複地創建專案基礎結構、專案規格流程取代掉，實現 DRY (Don’t Repeat Yourself) 原則。而 Yeoman 就是一個著名 scaffolding generator tool，微軟官方維護 Visual Studio Code extensions，就是裡面非常著名的例子。
Homebrew 是一個廣泛使用在 MAC 上的套件管理工具，可以安裝一些 Mac App Store 上沒有的軟體，其操作十分方便，可以簡化軟體安裝的過程，是個很有名的非官方工具，由 Max Howell 以 Git 和 Ruby 為基底寫成，並通過 GitHub 維護，為 2012 年 GitHub 上擁有最多新貢獻者的專案。對於其作者也有個有趣的軼事：Max Howell 曾應聘過 Google 的職位，面試失敗之後在 Twitter 上發文章 :
- Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so f*** off.
因此在網上引發了面試白板題的討論。
現在越來越多的服務應用使用 Protobuf 來作為資料交換的格式，它被廣泛應用於 RPC 調用和資料存儲。 Protobuf 語言中立、平臺中立，只要定義好一份 .proto 檔案，就可以生成不同的程式語言來處理資料的序列化或反序列化。要了解 Protobuf 序列化/反序列化，首先需要了解一些知識點 :
- Varint Encoding
- Zigzag Encoding
- Wire Type 類型
- T-L-V 儲存方式
熟悉這些可以更加理解 protobuf，也能避免錯誤使用，以及更好的優化性能。本章節會實際把前面學到的知識點一次用上，用實際案例來了解 Protobuf - Serialization。
隨者網路傳輸、頻寬與硬體的設備的改善和增強，能傳遞資料量也越來越大、越來越複雜，這時我們也不再只是追求能夠將資料傳遞完成，而是更加要求短時內傳遞大量的資料，故勢必會需要強化序列化和壓縮的技術。這篇會介紹 Protobuf 編碼後的 byte array 結構，以及會這樣設計的思路，當有了基本的認識後，就會明白 Protobuf 為何它可以比 JSON、XML 傳輸效率更高，更能壓縮資料，實現高效率。
蠻多 coding 語言在一般情況下是使用
32 bits的空間來儲存整數的，例如 Java 的 int，範圍是-2147483648 ~ 2147483647，大約正負21億。但是現實世界中，較小的數字往往比較常出現，大約幾十到幾十萬是最多最常出現的，如果只是要儲存或傳輸這樣的一個小數字，卻每次都需要用到 32 bits 的空間，其實有點浪費，這是有機會優化的 !Varint 和 Zigzag 演算法就是要處理這種問題，讓值小的數字，可以用較少的 byte 數量表示，而達到資料壓縮目的，著名的資料傳輸格式 Protobuf 也是通過 Varint 和 Zigzag ，來大幅減少了資料佔用的空間。
Protobuf 全稱 Protocol Buffers ，是一種輕量級的資料交換格式，最初是由 Google 開發的「可擴展的序列化資料結構」，現已成為一個開源項目，其語⾔中⽴且平台無關，適合高性能且對響應速度有高要求的資料傳輸場景；也因為有資料壓縮的能力，故也可用於資料儲存。Protobuf 的核心思想是先定義好 data schema ，然後可根據所需的語言生成對應的 code base，方便使用者操作 :「序列化寫入、反序列化讀取」。
Profobuf 需要注意的缺點是為二進制格式，故編碼之後不具有可讀性，需要反序列化後才能看得懂資料內容 ; 雖然是個好東西，但並非是個用來完全取代 JSON 的解決方案，JSON 仍有其可讀性高、易操作及通用性高等優點，在多數 API 設計的場景之下，JSON 仍然是最好的選擇。