在基本完全組件化的前端工程中，調(diào)用組件就像調(diào)用函數(shù)一樣常見：
- 調(diào)用函數(shù)時，我們傳入?yún)?shù)，得到計算結(jié)果；
- 調(diào)用組件時，我們傳入數(shù)據(jù)，得到渲染視圖；
不同的是，函數(shù)的參數(shù)通常只有1-5個左右，清晰的羅列在函數(shù)的定義過程中，而組件的數(shù)據(jù)，常常多達數(shù)十個，摻雜在html視圖和js的邏輯中。
在這種情況下，調(diào)用某個組件的時候，工作過程是這樣的：
- 組件作者提供了示例代碼：
- 從示例中找到引用組件的代碼，得到需要傳給組件的數(shù)據(jù)
- 如果數(shù)據(jù)是對象結(jié)構(gòu)，從js中梳理出對象的屬性
- 組件作者沒有提供示例代碼：）
- 從html中找到所有視圖數(shù)據(jù)
- 從js中梳理出視圖數(shù)據(jù)的來龍去脈，得到傳入的數(shù)據(jù)
梳理過程的復雜度和組件的復雜度呈現(xiàn)正相關，難度和組件涉及的業(yè)務難度呈現(xiàn)正相關。總的來說，梳理是最耗時、最折磨人的。
怎樣才能提高梳理過程的效率呢？
想起曾經(jīng)有同事調(diào)用我的組件的時候，提出了給組件寫示例代碼的要求，現(xiàn)在想起來，他應該也飽受梳理的折磨。現(xiàn)在的我，經(jīng)歷了一番題庫的折磨后，恍然大悟：
注釋，就能有效的提高梳理效率。但是，年輕的少年猿啊，你真的會寫注釋嗎？
寫注釋，本質(zhì)上是一件比Hello，World更簡單的事情（斜杠+*號，誰還不會呢
關于注釋，
有人信奉注釋越少越好，命名良好的變量就是天然的最佳注釋。
有些人很喜歡寫注釋，一個文件中的注釋足以構(gòu)成一道閱讀理解題。
對于函數(shù)而言，通常能做到職責單一，職責單一保證了參數(shù)較少，配合命名良好的變量，確實能做到不需要注釋，下面的函數(shù)，基本上一看就能知道它的功能以及調(diào)用方法。
arabicToChineseFilter = function (arabicNumber) {
var BIG_QUESTION_ORDER_NUMBER = ['', '一', '二', '三', '四', '五', '六', '七', '八', '九'],
UNIT = ['', '千', '百', '十', ''],
chineseNumber = String(arabicNumber)
.split("")
.reduceRight(function (pre, cur, idx) {
return (cur ? BIG_QUESTION_ORDER_NUMBER[Number(cur)] + UNIT[idx] : '') + pre;
}, '');
return chineseNumber;
};
所以，函數(shù)的注釋相對少見，也并不影響使用，但組件：
- 所需數(shù)據(jù)能夠多達數(shù)十個
- 在組件的聲明處，通常不會有所需參數(shù)的定義，即使有，也不清晰（regular對此沒有約束）
不過，函數(shù)的注釋標準，借鑒到組件中來，效果卻是很不錯：
/**
* knowledge組件
*
* @param {Object} resource
* @param {String} [resource.comment=''] 自定義評論
*
* @param {Object[]} knowledgeLogicPoints 題目關聯(lián)知識點
* @param {String} knowledgeLogicPoints[].name 知識點的名稱
*
* @param {Object[]} [microCourseVideo=[]] 本次答題關聯(lián)的微課視頻
* @param {String} microCourseVideo[].name 微課視頻的名稱
* @param {Number} microCourseVideo[].id 微課視頻的id
*/
從上面的注釋中，可以立刻得到組件所需的數(shù)據(jù)結(jié)構(gòu)：
setting: {
isDisabled
}
question: {
questionSocore:
subjectiveQuestionContent: {
stdAnswer: []
}
}
注釋的標準格式文檔
