最近在公司接手兩個舊專案，分別是 Web Service API 與 Website；為了分析傳說中曾解決過的問題 (大量 img tag 對瀏覽器記憶體消耗，先不談)，待讀清單裡又多一個已下線專案。

這裡頭用到的語言、套件、工具著實不少：

• Automation & package management:
  • Capistrano
  • Grunt.js
  • shell script
  • Python / Virtualenv
  • vagrant
  • npm / gem / rpm / pip / easy_install
• Server-side languages / Frameworks
  • Javascript / Node.js
  • Coffeescript
  • Express
  • Python / Django
• HTML-related frameworks / utilities
  • underscore
  • bootstrap
  • jQuery
  • Compass, Less,
• Services:
  • Nginx, Apache
  • Redis, MongoDB
  • HAProxy

然而引用的每種新工具，背後都有學習成本；若是之間介接 (所謂 “架構”)  “不漂亮”，帶來的維護成本更是倍增。玩專題 (包含自由研究) 的時候，多用各種工具 “練功” 是好事；但在打算上線的產品這麼搞，除非文檔 team 實力堅強，長久看來未必得宜。

語言問題永遠戰不完，所以直接跳到我的想法：

• 要有 coding standard
• 程式碼、註解、文檔 三者同等重要
• 模組功能、輸出入接口要明確，方便日後重構、重寫或重用該模組；資料與功能耦合是關鍵。
• API 接口不是只能靠 RESTful service；如果多層調用的網路傳輸會成問題，就先拉函式接口給近端調用。當核心服務需要 scale out 或擴充的時候，缺少良好分層與接口將成惡夢。
• Good code explains itself，但這不代表可以忽略文件；後人終究需要某些依據，才知道功能實作在哪一個檔案裡。使用贅餘的命名方式有助於此，比如說，Django 的 django.contrib.auth.middleware.AuthenticationMiddleware 確保能以 “middleware” 或 “auth” 簡單的找到該檔案，或是該物件的引用。至於在各種 Design Pattern 下，怎麼讓角色間的關聯性明顯 (容易理解，grep) ，就要踩過雷才能體會了。
• 語句別裝牛逼，連自己都看不懂就呆了。