源碼評分因子


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

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

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

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

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

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

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

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

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

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

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