The Art of Readable Code && High Performance Comments

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

 

發表迴響

分類

%d 位部落客按了讚: