陳 暉 李紅波 柏立悅

（浙江中控技術(shù)股份有限公司）

軟件開發(fā)周期逐漸成為相關(guān)企業(yè)考量的關(guān)鍵因素，這也是快速迭代的開發(fā)模式在如今的應(yīng)用軟件開發(fā)中越來越流行的原因之一。 對于一個工業(yè)領(lǐng)域的公司來講，軟件質(zhì)量是重中之中。 那么在工業(yè)信息化程度日漸提高的今天，保證軟件質(zhì)量與實現(xiàn)快速交付成了工業(yè)軟件公司的主要矛盾。 因此，筆者介紹了在遇到工業(yè)應(yīng)用軟件開發(fā)效率瓶頸時， 一種分析和尋找根本原因的思路。工控行業(yè)一直以來的主流技術(shù)棧為C/C++，特別是應(yīng)用層的軟件主要集中在C++，因此筆者針對C++軟件開發(fā)中遇到的相關(guān)問題，分析造成這些問題的根本原因。

1 把控項目進度的關(guān)鍵因素

對軟件項目經(jīng)理來說，最重要的是把握軟件的發(fā)布節(jié)點。 關(guān)鍵點在于要對總?cè)蝿?wù)量和總生產(chǎn)力兩個方面進行準(zhǔn)確評估，以確保兩者相契合。

1.1 總?cè)蝿?wù)量的評估

總?cè)蝿?wù)量即完成軟件項目需要的全部客觀有效工作量，計算方式可簡化如下：

如果想要進行更細致的評估，則需要采取更復(fù)雜的方式，如類比建模法［1］、階段評估法［2］等。這些方法基于以往類似項目的經(jīng)驗進行推導(dǎo)，往往能較準(zhǔn)確地對項目的總?cè)蝿?wù)量進行評估。

1.2 總生產(chǎn)力的評估

總生產(chǎn)力指的是一個團隊在一定時期內(nèi)實際可以提供的開發(fā)成果產(chǎn)出：

由此可見，想要精確地掌握時間節(jié)點，不僅要準(zhǔn)確評估總?cè)蝿?wù)量，還要準(zhǔn)確地評估出團隊的總生產(chǎn)力，以確保其能覆蓋項目的總?cè)蝿?wù)量。 而想要準(zhǔn)確評估總生產(chǎn)力，就必須準(zhǔn)確地了解每個開發(fā)人員在特定領(lǐng)域的能力。 一旦某個人的實際生產(chǎn)效率與預(yù)估的發(fā)生較大的偏差，那么關(guān)鍵路徑就會大幅變長。 而如果在項目后期才發(fā)現(xiàn)偏差，那么即使投入人海戰(zhàn)術(shù)也不能對加快進度有明顯的改善，甚至?xí)a(chǎn)生負面作用——因為原先的開發(fā)人員需要對新加入的開發(fā)人員進行培訓(xùn)，并且更多的人意味著更高的溝通成本［3］。

因此，準(zhǔn)確地評估每個開發(fā)人員可以做出的貢獻，消除項目中的不穩(wěn)定因素，是保障軟件項目更快、更及時完成的關(guān)鍵點。

2 開發(fā)貢獻率的評估

2.1 開發(fā)貢獻率的差異化

一個優(yōu)秀的編程者的標(biāo)志在于能夠快速寫出精簡而又清晰易懂、符合客戶需求、具有良好擴展性的代碼。 這樣的編程者們，是一個項目組的核心骨干，往往可以承擔(dān)一個軟件項目中大量核心代碼的編寫工作。 Sackman H 等早期的研究指出，水平較差的編程者的編碼時間最多可達優(yōu)秀編程者的25 倍，調(diào)試時間則最多為28 倍［4］。

而筆者也在已開發(fā)完成的軟件項目中做過統(tǒng)計，約20%的核心技術(shù)骨干可以完成約50%的功能開發(fā)， 而考慮到這些代碼重要程度的權(quán)重，其貢獻率最高可以達到80%。 由此可見，每個軟件開發(fā)人員所能做出貢獻的差異很大，所以找到合適的評估方法就顯得尤為重要。

2.2 評估方法及其缺陷

開發(fā)貢獻率的評估方法有很多，但大多是基于一個開發(fā)人員的已有開發(fā)成果進行推斷，例如傳統(tǒng)的方法有考察日均代碼行數(shù)、千行代碼缺陷率、代碼圈復(fù)雜度，而近年來則有人嘗試更復(fù)雜的建模方法，來達到更準(zhǔn)確的評估目的。 筆者將這些方法及其缺陷整理如下：

a. 日均代碼行數(shù)。 即考察開發(fā)人員每天產(chǎn)出的代碼數(shù)量。 該方法完全忽略了代碼的質(zhì)量。

b. 千行代碼缺陷率。 即通過測試結(jié)果來考察開發(fā)人員所寫代碼在邏輯上的質(zhì)量。 但該方法忽略了開發(fā)過程的差異性——如果相同的功能，人員A 比人員B 抽象提煉能力更強，在更好地考慮了復(fù)用性、擴展性、簡潔性后，產(chǎn)出的代碼比人員B 產(chǎn)出的代碼數(shù)量要少，在缺陷數(shù)同樣的情況下，人員A 的千行代碼缺陷率比人員B 要高，但顯然人員A 產(chǎn)生的效益比人員B 要高。

c. 圈復(fù)雜度。 即考察一個代碼模塊的復(fù)雜度。 在沒有對照的情況下，該方法也不能很好地反映出開發(fā)人員的貢獻率，因為它反映的是一個模塊最后實際產(chǎn)出的代碼呈現(xiàn)出的復(fù)雜度，而不是其應(yīng)有的復(fù)雜度，而一個模塊本身應(yīng)有的復(fù)雜度是很難衡量的，所以也就無從比較。 除非兩個程序員都實現(xiàn)同一個模塊的代碼，那么這兩份代碼的圈復(fù)雜度能較好地體現(xiàn)出他們技術(shù)水平的差距（圈復(fù)雜度越低的反而越好，表明其能把復(fù)雜的事情簡化）。

d. 數(shù)學(xué)建模。 以上的方法單一應(yīng)用時都有相當(dāng)大的局限性，因此近年來有人試圖使用數(shù)學(xué)建模的方法把各種因素結(jié)合在一起，并使用人工智能的方法得出一套實際可用的評價系統(tǒng)。 例如Ren J L 等基于其研究成果開發(fā)的Merico 評價系統(tǒng)將代碼的貢獻值分成結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，并用機器學(xué)習(xí)的方法將這兩種數(shù)據(jù)擬合在一起，得出最終的貢獻值［5］。其中結(jié)構(gòu)化數(shù)據(jù)主要由一個函數(shù)的被調(diào)用次數(shù)決定，而非結(jié)構(gòu)化數(shù)據(jù)則由機器學(xué)習(xí)來判斷某條代碼提交的重要性。Merico 評價系統(tǒng)確實在一定程度上解決了編程貢獻值評估難的問題，但也有其局限性。 例如該系統(tǒng)判斷結(jié)構(gòu)化貢獻值的方式是統(tǒng)計一個函數(shù)的被調(diào)用次數(shù)，其驗證手段是考察3 個開源社區(qū)貢獻者的開源代碼來實現(xiàn)的。 由此可知其局限性在于，首先，開源社區(qū)貢獻者的開發(fā)水平屬于中上游，不具有全面的代表性；其次，一般地，在一個大中型公司中， 軟件的模塊劃分更為細致，基礎(chǔ)模塊（通常來說代碼質(zhì)量、穩(wěn)定性及可閱讀性等要求都相對更高）比上層的應(yīng)用模塊有更多的機會被調(diào)用到，但無法就此推斷出負責(zé)基礎(chǔ)模塊的程序員其代碼貢獻率就一定比負責(zé)應(yīng)用模塊的大。 而基礎(chǔ)模塊和應(yīng)用模塊通常是不同的項目組（例如公共組件組和產(chǎn)品項目組）負責(zé)的，對于同一個組的成員來說，他們負責(zé)的模塊層次是相對扁平化的，那么函數(shù)被調(diào)用的幾率實質(zhì)上是均等的。 所以實際上這是一個從結(jié)果推出條件的偽命題，因為越底層越基礎(chǔ)的模塊，通常會被多個產(chǎn)品線共用，其重要性不言而喻，一般會讓技術(shù)功底深厚的老員工來擔(dān)綱，那么他們編寫的代碼自然而然地具有更好的質(zhì)量，而不是因為他們的接口被使用更多就認為他們的代碼質(zhì)量更好。

3 產(chǎn)生偏差的原因分析

3.1 造成偏差的不穩(wěn)定因素

由上文可見，目前大部分方法都不能客觀準(zhǔn)確地評估貢獻率，實際日常操作也仍是以項目經(jīng)理依據(jù)對團隊成員能力上的印象進行判斷為主。如果不是一個參與架構(gòu)設(shè)計和日常代碼評審的項目經(jīng)理，很難做到準(zhǔn)確公平地評估每個組員的真實貢獻。 事實上這種情況在企業(yè)中很常見，由于項目管理流程的需要，項目經(jīng)理無法在具體開發(fā)工作上投入過多精力，一般會把這些任務(wù)轉(zhuǎn)交給組內(nèi)的技術(shù)專家或資深員工，這就造成項目經(jīng)理對開發(fā)人員的真實水平很難有準(zhǔn)確的把握。

通常在項目初期，項目經(jīng)理會較均勻地分配任務(wù)，原因是出于對團隊成員的信任，避免他們認為被邊緣化。 而隨著開發(fā)過程的推移，在最初任務(wù)分配均等的前提下，高水平開發(fā)者的進度一般領(lǐng)先于其他員工。 此時項目經(jīng)理出于項目進度考慮，基本會轉(zhuǎn)移部分可分離的任務(wù)到骨干員工身上。 以上的做法往往導(dǎo)致高水平的開發(fā)人員不堪重負——不但要承擔(dān)架構(gòu)設(shè)計，還要負責(zé)大部分功能的實現(xiàn)。 而低水平的開發(fā)人員只能在邊緣的功能上做文章， 對于他們的技術(shù)成長收效甚微，即便公司給予培訓(xùn)上的支持，但缺乏實踐使得知識很難得到沉淀。 如果給予他與其水平不符的任務(wù)，然后花費高水平開發(fā)者的時間來仔細評審他們的設(shè)計和代碼，確實能更快速地提高其水平，從長遠來看也更有意義，但也得忍受當(dāng)前項目數(shù)倍的開發(fā)周期和更多的錯誤數(shù)量。

因此，一個有時間節(jié)點壓力的項目型團隊就容易陷入到一個不好的循環(huán)中來，整個團隊總是疲于應(yīng)付開發(fā)任務(wù)，其整體水平只能以一個很平緩的曲線上升。 這對于公司和員工來說是一個雙輸?shù)木置妫簩緛碚f，一個開發(fā)團隊的成本日益上升，但其開發(fā)水平并沒有得到相應(yīng)程度的提高，其價值其實是日益下降的；對于員工來說，在相當(dāng)長的時間內(nèi)沒有得到成長，那么對自身的發(fā)展和職業(yè)生涯是很不利的。

可以推斷，軟件項目周期的穩(wěn)定性主要是依據(jù)非核心開發(fā)人員。 一個項目的關(guān)鍵因素在核心員工身上， 但關(guān)鍵路徑卻體現(xiàn)在非核心員工身上。 如前文所述，項目經(jīng)理依賴于工作經(jīng)驗豐富的核心員工來保障項目進度，那么相反地，非核心員工在開發(fā)不同產(chǎn)品或不同模塊時所表現(xiàn)出的不穩(wěn)定性正是影響項目進度的最大因素。 他們更容易受開發(fā)平臺、產(chǎn)品特點的影響，這種不穩(wěn)定性就反映在他們的開發(fā)周期和開發(fā)質(zhì)量上。

綜上所述，非核心員工的開發(fā)效率、質(zhì)量相對不穩(wěn)定，導(dǎo)致項目組的資源配置也不能達到最優(yōu)化，因此項目的進度風(fēng)險就會變大。

3.2 根本原因分析

首先對兩個不同水平的C++開發(fā)人員所能做出的貢獻有巨大差距這個現(xiàn)象做出一個分析：

a. 面向?qū)ο蟊让嫦蜻^程在設(shè)計上需要更多的努力和領(lǐng)悟［6］。對于大部分C++程序員來說，在學(xué)校學(xué)習(xí)的課程以C 語言居多，或者學(xué)習(xí)過C++課程，但并未領(lǐng)悟面向?qū)ο蟮乃枷耄趧偼度腴_發(fā)工作中時仍把C++當(dāng)成C 語言來使用。 事實上領(lǐng)悟面向?qū)ο蠛茈y，也需要一定的天賦，因為面向?qū)ο笾皇且粋€概念， 其背后蘊含的是抽象、提取、 總結(jié)事物內(nèi)在邏輯和聯(lián)系的本領(lǐng)與技巧，即便一個有多年C++使用經(jīng)驗的程序員都不敢宣稱完全掌握其精髓。

b. 新手往往知識面不夠豐富。對于一個核心開發(fā)人員來說，他可能兼具編程知識的廣度與深度，擁有不同項目的開發(fā)經(jīng)驗，負責(zé)過不同領(lǐng)域的產(chǎn)品和模塊，文件讀寫、網(wǎng)絡(luò)通信等不同方面的知識對于他們來說已經(jīng)成為常規(guī)武器。 而對于一個新手來說，處理產(chǎn)品的業(yè)務(wù)邏輯就已經(jīng)耗費其精力，其他方面不可能以一種十分自然、毫不費力的方式把它們處理正確。

c. 新手往往自信心不足。 新手由于缺乏項目經(jīng)驗，即便已經(jīng)儲備了很豐厚的理論知識，但在實際開發(fā)過程中， 對自己寫的代碼的不自信，追求盡量少犯錯，依然會用一種比較初級但自己更熟悉的方式去編寫代碼。 但在商業(yè)化項目的開發(fā)中，邏輯上的正確往往是不夠的，性能、可維護性等方面都是需要考量的因素。

以上原因使新手在開發(fā)過程中會遇到很多困難和疑惑。 以下是一個案例，該段代碼用于實現(xiàn)查詢用戶列表中是否有“admin”用戶的功能：

運行這段代碼雖然能獲得正確的結(jié)果，但可從一個代碼評審者的角度來討論其不足之處：

a. bFound 變量多余，iter 和userIdList.end（）比較即可實現(xiàn)同樣的效果；

b. iter++改為++iter 更佳，避免每次產(chǎn)生一個臨時變量和賦值動作；

c. 在if（*iter==“admin”）分 支 中 應(yīng) 該 添 加break，否則找到“admin”后仍會繼續(xù)執(zhí)行，導(dǎo)致浪費計算機的性能；

d. for 循環(huán)終止條件中的userIdList.end（），應(yīng)該使用臨時變量進行緩存，以避免重復(fù)的函數(shù)調(diào)用削弱性能。

一個簡單功能的實現(xiàn)，卻有至少4 處改進之處，且b、d 兩條是絕大多數(shù)新手沒有理解和掌握的。 在一些服務(wù)器端的開發(fā)中，這些缺陷可能造成一定程度的性能問題，而針對這些缺陷進行優(yōu)化后，某些情況下性能甚至可以提升20%以上［7］。

因此， 一個新手或者低水平的開發(fā)人員，與資深開發(fā)人員的差距是全方位的，如果要求他們一開始就去處理編程的各個方面， 如數(shù)據(jù)結(jié)構(gòu)、網(wǎng)絡(luò)交互及操作系統(tǒng)等， 那么他們便會顧此失彼，從而影響編程效率和質(zhì)量，最終開發(fā)周期變長甚至成倍增長。 如果想減少這種不利的因素，那么就必須創(chuàng)造環(huán)境來盡量避免新手同時面對多個他不熟悉的領(lǐng)域，從而使其精力足以應(yīng)付一定的不確定性，并穩(wěn)步地成長。

4 結(jié)束語

筆者闡述了把控項目進度的關(guān)鍵因素為團隊總生產(chǎn)力的評估，介紹了評估開發(fā)人員貢獻率的方法及其局限性，指出開發(fā)貢獻率的評估難點是軟件項目發(fā)生進度偏差的一大原因，進一步指出造成偏差的深層原因是新手在面對多個不熟悉領(lǐng)域時所表現(xiàn)出的不穩(wěn)定性，這些為企業(yè)優(yōu)化軟件開發(fā)流程、改進開發(fā)環(huán)境提供了一種思路。