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