源碼評分因子

作者：   發佈於：  

要怎麼去評定一份源始碼，給其量化的分數？

如果是一篇文章(Blog/Comment/Article)，就算比賽小學生作文一樣，我們 會用「切題」、「合乎邏輯」、「文筆通順」、「條理分明」…等等，諸多層面 (亦即給分的「因子」)來給定這篇文章的一個價值，雖然小學生會拿到個「83」 這種全部加起來的一個滿分一百分的分數，可是實質上這是一個像是 (20,25,17,21) 這樣的向量，代表每一個因子的分數。

可以這樣子給分的原因在於，應該沒有一篇小學生作文是「文不對題、毫無 邏輯、詞句生硬、狗屁不通」，卻又「萬分精采」。基本上，載道的文章好像都 有這種類似 optimal substructure 的特性，所以可以把因子們拆開來討論。

不過，所有的 kuso 文都是例外就是了。 (這麼說的話，「kuso」似乎屬於某種 dominated factor ?)

另外，這些因子的特性應力求客觀。這似乎是傳統做評論的通則。也就是說， 真他媽狗屁不通，也得真真切切的狗屁不通才行。

同樣的道理似乎可以用於源碼的評比上面。不過源碼並不是文章，雖然說有 人認為演算法、程式碼、可以被放在藝術的眼光上來看，不過，一般在軟體工程 的範疇之中，是希望用量化的方式來做衡量。也就是，東西都成了數字，多就是 多，少就是少。質化的評量一般被認為帶有主觀性色彩，是進入小圈圈的必修課 程。

所以我們須要些可以用數量來代表源碼的因子，像是「程式碼行數」這樣的 因子。(當然算這行數有些方法，不然寫程式的就會老是多按幾個 Enter)。 很簡單就可以注意到，像這樣的評分方式是 bottom-up 的，也就是說，一次 看一小點，一小個方面，要累積起來，才看得見大局。

那麼，該用些什麼樣的因子呢？ 在只考慮一份固定的源碼時，筆者以為可以分為三類， 其一並不隨著人的主體使用感受而變，是一般軟體工程之中 Software Metric 的因子，包括了：

其二則是前述因子在意義上的衍生因子，與人的認知有關， 但這些因子於軟體製程之中也被認為與軟體的發展性有密切關係。像是：

其三則是在軟體整體表現上的一般因子，同時也與軟體的 發展過程有關：

若考慮軟體的發展「過程」，那麼也一樣可以有以下幾種因子：