最近在公司接手兩個舊專案，分別是 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) ，就要踩過雷才能體會了。
  • 語句別裝牛逼，連自己都看不懂就呆了。