Embed Size (px)
DESCRIPTION
「關於 JavaScript 品質，我想說的是...」於 JSDC.tw 2013
Citation preview
JAVASCRIPT CODE QUALITY
講者 josephj
關於 JavaScript 品質，我想說的是...
當談到 JavaScript 品質...
大家心裡的重要性就好像左邊那一本 XD
JavaScript 的興起...讓開發者覺得 JavaScript 就是要複製貼上
Bad JavaScript = 違章建築
寫程式應該是被維護的，而不是一看就想要拆掉的
6000 ⾏行 JavaScript!
Agenda
·在 Yahoo! 學到的教訓
·需要建立前端團隊的架構
·在 miiiCasa 學到的教訓
·需要先設計、多抽離
·未來可持續努力的方向
·自動化 Plus
成長 = 從過去的錯誤反省！
第 1 課 from Yahoo!前端⼯工程師必須成為真正的團隊、⽽而⾮非只是資源
中央游泳池當時「前端⼯工程師」不屬於任何產品線
專案 1
專案 2
F2E Pool不會有閒置資源
中央游泳池當時「前端⼯工程師」不屬於任何產品線
專案 1
專案 2
F2E Pool基本上都在專案
任務導向、缺少團隊機制
大家只管自己的眼前的案子
缺少水平的機制去管理品質
久了必會發生慘案
• 由新人負責、跟其他專案成員關在小房間
（沒有其他 F2E）
• View 全部用 JS 組、後端只給 JSON
• 不支援 NoJS、沒法上一頁
• 重複程式碼非常多，沒人敢大改
• 專案結束沒多久，新人離職
• 2012 年底，此服務關閉
永遠在我心裡的一句話
“As a team, F2E 的價值究竟在哪裡？”
好不容易培訓⼀一個新⼈人、卻⼜又因制度不健全害了他
開始去思考「團隊」這件事
• Code Convention 團隊規範
• Code Review 定期 Review 程式碼
• Checklist 上線前需達成的清單
⾮非常重視⼀一致性、維護性
規範一些最基礎的小事情
一致性、像同一個人寫的
https://github.com/josephj/f2e-styleguide
Code Review
http://programmers.stackexchange.com/questions/170211/php-data-access-layer
程式碼接受所有⼈人檢驗
比 JSLint 更傷感情 XDhttps://github.com/miiicasa/youtube-iframe/issues/1
需要比較正面的態度
每次 Code Review 都能學到很多東⻄西！
Pair Programming
http://en.wikipedia.org/wiki/File:Pair_programming_1.jpg
⼀一個⼈人寫程式、⼀一個⼈人當觀察員
導入正確的模式模組化 (Module) 與觀察者 (Observer) 模式
模組：寫法一致、避免全域變數
welcome/_notification.js
⼀一個模組即有⼀一個 JS 檔
模組：寫法一致、避免全域變數
YUI.add("welcome/_notification", function (Y) { var trans = {}, module;
module = new Y.Module({ selector: "#notification", init: function () { }, on: { viewload: function (node) {
} } });
}, "0.0.1", {"requires": [ "module" ]});
welcome/_notification.js
以 CLI ⾃自動從樣板建⽴立模組⼀一個模組 (Partial) 配⼀一個 JavaScript 檔
好⽤用⽅方法與屬性都圍繞在此 instance
⼀一旦當此模組存在於 DOM 之中
相依模組
此模組的 Selector 或物件參考
模組：寫法一致、避免全域變數
YUI.add("welcome/_notification", function (Y) { var trans = {}, module;
module = new Y.Module({ selector: "#notification", init: function () { }, on: { viewload: function (node) {
} } });
}, "0.0.1", {"requires": [ "module" ]});
module.broadcast("greeting", trans.greeting); module.listen("need-‐love", function (e) { /* do something */ }); new Y.ScrollPagination({node: node});
welcome/_notification.js
所有的功能都圍繞著模組化開發
多國語系
送廣播
聽廣播
加上其他相依模組
trans.greeting = module.getTrans("greeting", "Hello World");
,"module-‐popup", "module-‐intl", "gallery/scroll-‐pagination"
模組：寫法一致、避免全域變數
YUI.add("welcome/_notification", function (Y) { var trans = {}, module;
module = new Y.Module({ selector: "#notification", init: function () { }, on: { viewload: function (node) {
} } });
}, "0.0.1", {"requires": [ "module" ]});
module.alert(trans.greeting); module.broadcast("greeting", trans.greeting); module.listen("need-‐love", function (e) { /* do something */ }); new Y.ScrollPagination({node: node});
welcome/_notification.js
所有的功能都圍繞著模組化開發
多國語系
共⽤用的 popup
送廣播
聽廣播
加上其他相依模組
trans.greeting = module.getTrans("greeting", "Hello World");
,"module-‐popup", "module-‐intl", "gallery/scroll-‐pagination"
限制團隊成員在沙箱（Sandbox) 中開發
功能擴充也能有一致介面
只專注開發該模組功能、無法污染外界
不只是 JavaScript Ninja!認識軟體⼯工程與持續集成，事半功倍！
需從軟體工程的角度出發
• Lint 自動檢查程式碼
• Combine/Compress 自動合併及壓縮 JS/CSS
• Optimize image 圖檔最佳化
• Compass 用 High Level 的語言讓 CSS 簡化
• Skeleton 自動建立樣板檔案
導⼊入⾃自動化、減少「⼿手⼯工」、才能提昇品質
在 miiiCasa 實踐了這些理念很幸運可以從零開始、擔任前端⼯工程部⾨門主管
這些想法與理念都⼀一⼀一地實踐了
難道就不會有問題了嗎？
http://www.slideshare.net/josephj/ss-7705095
建立前端開發團隊
第 2 課 from miiiCasa 必須先設計、並導⼊入更好的 JavaScript Pattern
miiiCasa Space 家庭雲：用單一 URL 存取家中裝置上的資料
• 4 個不同的媒體：照片、音樂、影片、文件
• 2 個不同的類型：首頁列出 Storage、內頁只列目錄
• 都是檔案列表、但差異很大：• View 都各自有差異
• 照片要 Slideshow
• 音樂要播放器
• 影片用 VLC / Flowplayer
• 文件要用 Lightbox 顯示照片、同時支援
影片、音樂、Google Drive Preview...
有時程壓⼒力...該怎麼快速產出？
『coding』＝ 複製貼上的工作
http://but.tw/2008/10/programmers_rule/
團隊的每個⼈人都有責任
用「複製、貼上」達成需求與滿足時程
• 一模組約 1,500 行 JS
• 4 個不同的媒體
• 2 個不同的類型
• 差異很大 = 修修改改
1,500*4*2 = 12,000 行
後續有新功能都幾乎是「複製貼上 x 8」
Winchester Mystery House
http://www.flickr.com/photos/harshlight/3670192350/
外表富麗堂皇、也確實地達成應有功能與時程
http://www.flickr.com/photos/dalvenjah/33560263/lightbox/
內部的結構...
http://www.flickr.com/photos/skinnylawyer/5570163978/
疊床架屋是軟體開發最常見的問題
在煙囪上架屋頂？ ⾛走向屋頂的樓梯？
壓縮開發時程之謎
Stoyan Stefanov
The few man-hours spent writing the code initially end up in man-weeks spent reading it.
數⼩小時寫出的程式碼、得花數週或更多的時間維護它
要在 8 個 JavaScript 上：
• 增加新功能
• 修改 Bug
• 改變邏輯
• 看不懂、乾脆重寫
⽼老闆跟專案經理永遠無法理解的事...
面對問題未來要怎麼預防同樣的問題、或避免讓問題繼續蔓延
EDD – 設計文件圖表
BranchURLs
檔案結構
Controller
模組詳細說明
預先規劃的假資料
JS 的架構日益複雜
需要跟後端程式一樣先規劃
負責人先仔細思考、撰寫出此文件
所有開發人員一起討論可行性、問題點
把思考不周延之處找出來、了解配合模式
時程預估較為準確、有機會先預防
Refactoring - 重構
重構 ＝ 打掉重寫？
應避免 NIH 綜合症（非我所創、Not Invented Here Syndrome）
NO!
技術人員應該用更客觀的心態面對重構
重構 = 持續且小的改進。
開發 重構 開發 重構
把重構納入產品開發的 Iteration
......
無法⼀一開始寫出完美的程式碼藉由實作、看到問題與需求，再著⼿手修正
逐步達成理想的程式碼品質
重構案例：Pop-up 視窗
util.showDialog(module, title, message, okText, cancelText);
module.broadcast("dialog-‐show-‐request", { title: title, msg: message, buttons: { ok : { label: okText, callback: okHandler }, cancel : { label: cancelText } }});
new Y.Panel({ headerContent: title, bodyContent: message, buttons: [] render: true, visible: true})
過去⾄至少有三種不同的作法
統⼀一作法、將預設⾏行為確認
module.alert(message);
module.confirm({ title : title content : message}, okHandler);
module.inform(message);
對程式碼精簡、⾏行為的⼀一致性獲得⼤大幅改善
重構案例：Pop-up 視窗
util.showDialog(module, title, message, okText, cancelText);
module.broadcast("dialog-‐show-‐request", { title: title, msg: message, buttons: { ok : { label: okText, callback: okHandler }, cancel : { label: cancelText } }});
new Y.Panel({ headerContent: title, bodyContent: message, buttons: [] render: true, visible: true})
過去⾄至少有三種不同的作法
統⼀一作法、將預設⾏行為確認
module.alert(message);
module.confirm({ title : title content : message}, okHandler);
module.inform(message);
對程式碼精簡、⾏行為的⼀一致性獲得⼤大幅改善
重構的價值
減少程式碼中光怪陸離的現象
未來開發更容易
減少 UI 的不一致
Decoupling - 抽離
避免把所有程式碼都放在一個 JS 中
為什麼會產出「一大包」JS？
• 麻煩！JS 載入需考慮「前後順序」<script/> 有先後順序，例如載入 jQuery UI 的 Tabview.
• JS 本身缺乏「模組」的觀念直到最近 ECMAScript 才要內建
• 「頁面」眾多、分割不易不像其他的語言，大多只要 require 就可以使用
• 對 JavaScript 缺乏「軟體工程」的態度非本科：對程式抽離、正規化概念薄弱。本科：對 JS 不用想這麼多吧！
抽離範例：Space Photo
• 主要功能：列出 Router USB 裡的照片。
• 其他功能：
提供下載檔案、幻燈秀、縮圖產生機制、
檔案描述、LightBox、分享、重新命名等機制。
這才是此程式中最重要的
每一個都可以另開 Module 處理
代碼抽象三原則
• DRY - 不要重複自己出現重複時就抽象出一個解決方法
• YAGNI - 你不會需要他快 + 簡單！不要把精力放在抽象化上
• Rule of 3 - 三次原則當同樣的情況出現三次才進行抽象化
http://www.ruanyifeng.com/blog/2013/01/abstraction_principles.html
功能抽離範例
space-centralize.js (共 103 行)
/** * @module space-‐centralize */YUI.add("space-‐centralize", function (Y) {
// Implementation here...
Y.Space.bindCentralize = bindCentralize;
}, "0.0.1", { "requires": [ "space", "node-‐base", "event-‐resize" ]});
需要讓圖⽚片隨螢幕寬度置中對⿑齊，瀏覽較舒適
原本負擔很重、1500+ ⾏行的 JS 檔
/** * @module space/photos/_photos_main */YUI.add("space/photos/_photos_main", function (Y) {
// ... Y.Space.bindCentralize(); // ...
},}, "0.0.1", { "requires": [ // ... "space-‐centralize", // ... ]});
只增加兩行
採用模組化 Library解決 HTML 中 JavaScript 缺乏模組機制的問題
define(“editor”, [‘a’,’b’,’c’], function () { function Editor { /* Constructor */ } return Editor;});
require(["editor"], function (Editor) { new Editor();});
editor.js – 定義 editor 模組
demo.js – 使⽤用 editor 模組
任何⼀一個網站都應該要⽤用！
應加入的規範
• 一個 JS 檔案不應超過 500 行
• 一行不應超過 100 個字元
維護一個大雜匯的 JavaScript 有何意義？
會超過 500 行應代表你該抽離功能了
未來還能做些什麼
給自己未來的一些題目
大多是更多工具的整合、讓自動化來提升品質
⼯工具 ⼯工程師
•無聊•重複性的•浪費時間的 藉由⼯工具持續回饋
自動偵測重複的原始碼
需要把「避免重複原始碼」變成⼀一個習慣
是很重要的一件事！
大家所熟悉的 JSLint, JSHint 卻沒有 Orz...
都只有「單一檔案內」的語法檢查
PMD - 原始碼分析器
其中 CPD 工具可以分析 JS 的重複
/bin/run.sh cpd -‐-‐minimum-‐tokens 50 -‐-‐files ~/project/foo/js -‐-‐language ecmascript
跑出來的結果重複的行數 重複的檔案列表
非常需要納入 Commit 流程或 Auto Build 檢查
Error Log 管理JavaScript 錯誤應該被即時記錄並回報
瀏覽器錯誤
window.onerror
try-catch
錯誤發生
程式決定是否要往上丟
程式決定是否要往上丟 把錯誤丟到 Server 做記錄、回報
就不用辛苦地翻程式碼找問題
控管好這兩個時間點
// Log to server. window.onerror = function (message, url, line) { var queryString, el; queryString = location.search.slice(1); el = document.createElement("img"); el.src = LOG_URL + "?" + [ "hostname=" + encodeURIComponent(location.host), "message=" + encodeURIComponent(message), "line=" + encodeURIComponent(line), "url=" + encodeURIComponent(url), "query=" + encodeURIComponent(queryString) ].join("&"); return true; // Avoid browser error. };
把錯誤回報給 Server常見作法：用假圖片 Request 達成、可跨網域
但是！錯誤需要被 Grouping 才有價值
推薦工具 - Sentry接收各種程式語言錯誤、分組、寄通知信
Esprima
http://esprima.org/
最近只要聊到 JavaScript Code 品質，幾乎都會聽到這個工具
Esprima 運行原理
程式碼 抽象語法樹Source Code Abstract Syntax Tree
var answer = 6 * 7;
{ "type": "Program", "body": [ { "type": "VariableDeclaration", "declarations": [ { "type": "VariableDeclarator", "id": { "type": "Identifier", "name": "answer" }, "init": { "type": "BinaryExpression", "operator": "*", "left": { "type": "Literal", "value": 6, "raw": "6" }, "right": { "type": "Literal", "value": 7, "raw": "7" } } } ], "kind": "var" } ]}
將程式碼轉成結構⼀一致的 AST 格式，很容易做後續處理
經過 Esprima Parse
Esprima 範例 – CodePainter問題：每個⼈人寫的空格、引號習慣都不⼀一樣，能否統⼀一？
跑⼀一次⽤用 Esprima 實作的 CodePainter ⼯工具，問題全搞定
https://github.com/fawek/codepainter
Esprima 的可能應用
• JSHint: 將會改用 Esprima
• 語法高亮
• 塞 Log，協助偵錯：
• 在每個 Method 都放：console.log("someMethod() is executed.")
http://www.slideshare.net/ariyahidayat/javascript-parser-infrastructure-for-code-quality-analysis
Continuous Integration 持續集成「所有」⾃自動化檢查，都應該與 CI 整合
中央 Git
個⼈人 Git
git push
post-‐receive
trigger
git clone
Build
JSHint
Code Duplication
Unit Test
Functional Test
Code Coverage
通知
成功或失敗
Performance
讓檢查像喝⽔水⼀一樣簡單、確保品質
CI 伺服器
推薦服務
CodeShip
懶得⾃自⼰己架⼀一台 CI 伺服器？市⾯面上有好幾家 SaaS 的服務可⽤用
若你的原始碼是放在 GitHubCodeShip 與 Travis 都只要勾選就可以使⽤用
把團隊更緊密的綁在一起把所有訊息 (Commit, Wiki, Issue) 都倒進聊天室
不用交談也知道彼此的做了什麼、點選可看詳細內容
文學編程Literate Programming
寫程式的理想型態
Donald Knuth現代電腦科學的鼻祖
A style of programming that maximize our ability to perceive the structure of a complex piece of software.
文學編程的理念
「是時候了，讓我們的程式碼更好！」
文學編程是一種寫程式的理想形態 :
讓我們對於軟體的每個複雜環節都能
充分地理解
更有組織維護自己的文件Leo Editor - 依自己的思路撰寫文件、組織代碼
可以是任何的內外部⽂文件、節點可以任意地被複製搬移
⾃自由地組織、編排節點順序
產出的程式碼可與其他⼈人 Merge、Leo 會幫你追蹤⽀支援 Textile、Web 投影⽚片的輸出
更有組織維護自己的文件Leo Editor - 依自己的思路撰寫文件、組織代碼
可以是任何的內外部⽂文件、節點可以任意地被複製搬移
⾃自由地組織、編排節點順序
產出的程式碼可與其他⼈人 Merge、Leo 會幫你追蹤⽀支援 Textile、Web 投影⽚片的輸出
Leo Editor 很強大、也不針對特定語言，但是...
每個人都有自己愛用的編輯器（Vim 或 Sublime）
Leo 在程式碼編輯功能上似乎不怎麼樣...
在一堆編輯器中切換也是件很愚蠢的事
以喜歡的編輯器、⽤用⽂文學編程寫 JavaScript
Leo 的缺點
https://github.com/jostylr/literate-programming
以 JavaScript 實作的文學編程
編譯 Markdown
產出 JavaScript
James Taylor
https://gist.github.com/josephj/5580918
Demo
> File count.js savedliterate-‐programming ⽂文學編程.md
寫程式就像寫部落格⼀一樣！
可重新組合章節讓別⼈人⾮非常容易理解
Literate CoffeeScriptCoffeeScript 的作者 ＝ 文學編程的大力推廣者
Jeremy Ashkenas
Journo 部落格系統
Docco API 文件產生器
以⽂文學咖啡寫成：
缺點：得依照原始碼的順序寫
Journo 的 README.md就是部落格系統的完整原始碼 ( journo.litcoffee)
$ coffee -‐c journo.litcoffee #output journo.js
文學編程過去不是主流、未來也不會
文學編程小結
但身為一個開發者，應秉持文學編程的精神：
「程式碼是給人閱讀的」
以上兩種作法，似乎也可以稱為「部落格編程」
是我們現今最容易理解技術的一種 Material
Code Review
設計⽂文件 產出 API ⽂文件
模組化
模組架構代碼規範Pair Programming
檢查清單⾃自動合併與最⼩小化
Lint
單元測試物件導向
重構
代碼重複檢查
JS 語法分析、重置
持續整合
品質的 TODO LIST
抽離原則⽂文學編程
團隊活動 觀念及架構 ⾃自動化
整合訊息
看團隊需求來做導入或整合
Prototyping
寫程式是個良心的事業
過去的評價會⼀一直跟著你，我們應該盡⼒力寫好
程式碼品質，大師們都會強調再強調
2b || !2bthat is a question.
Thank you!
• GitHub - josephj
• Facebook - 蔣定宇
• Slideshare - josephj
• Linkedin - josephj6802
聯繫我
