如果引用或轉貼,麻煩註明出處與本網誌連結,否則視為侵權。

2017年6月20日

程式碼審查有助於提升程式品質嗎? 有關程式審查的十個事實

作者: Fred F.M. Wang (FW知識瑣記) 日期:20170620

英文原文:10 facts about code reviews and quality 

摘要翻譯
        以下是從 680家公司訪談有關程式品質與程式碼審查的案例,得到下面結果
  事實一:我們花大量的時間在審查程式碼 。事實是,我們每週平均花費 5 個小時來審查程式碼 ,或者每週 12.5% 的時間來查看程式碼 。
 
  事實二:作為開發人員,每週花費超過一天的時間來審查程式碼與提高程式碼品質並不相關,反而是用更多時間在發佈新功能(而不是修復bug 或償還技術債務)。  
 
  事實三:45% 的開發人員說,「缺少時間」是審查程式碼的真正障礙,34% 的開發人員則認為是迫於「發佈新功能的壓力」

  事實四:72% 的開發人員表示他們被阻止花時間審查程式碼

  事實五 66% 的開發人員表示需要 1 人批准他們的 pull requests,25% 需要 2 人,小於 5% 需要超過 2 人。(註 : Pull Requests : 開發人員可以透過Github發出Pull Requests要求請求他人將程式拉下來看,也就是由開發人員主動要求他人幫忙做Code Review的意味。)

  事實六:53% 的人表示有監控程式碼覆蓋率,但 65% 表示沒有程式碼覆蓋率的最小門檻值(標準),來批准 pull requests  (註 : 代碼覆蓋(英語:Code coverage)是軟體測試中的一種度量,描述程式中源代碼被測試的比例和程度,所得比例稱為代碼覆蓋率。有多種不同的覆蓋率準則, 如函式覆蓋率,敘述覆蓋率,判斷覆蓋率, 條件覆蓋率等 )

  事實七:29% 的開發人員表示 他們的專案中最大的問題是「工作量」,而工程副總和處長的則認為是「交付速度」。開發人員的第三大問題則是「管理」。

  事實八:關於誰來審查程式碼 ,讓團隊中的每個人都參與是最常見的做法。其他方法則是由專案負責人或模組的負責人來參與,或讓資深的開發人員來審查多數的程式碼 。
 
  事實九:較嚴格的程式碼 審查會讓我們用更少的時間修復錯誤,也就有更多的時間來提供新功能。較不嚴格的程式碼審查者會花費 31% 的時間修復錯誤,而嚴格的審查者則只花費 24% 的時間。關於專注新功能的時間:和上面對應的分別是 43% 和 54%。(嚴格的審查者有更多的時間專注於新功能)

  事實十:開發人員花費 45% 的時間修復錯誤或解決技術債務(以前留下來的問題),與建立新功能所花費的時間不相上下。
 
由上面來看,程式碼審查可以提高修復錯誤的效率,但是不見得可以提高程式碼品質。
 
 


2017年6月15日

[企業管理的省思] 資安系統能阻止所有商業機密外洩的可能嗎?

作者: Fred F.M. Wang (FW知識瑣記) 日期:2017/6/15

有些很多公司導入資安系統以防止公司機密洩漏。筆者認為這些系統僅能發揮部分防護與紀錄的效用,讓機密外洩稍微不容易一點,但無法完全阻止機密外洩,有時反而造成想做事的人工作上的不便與企業的效率不彰。

例如資安系統能完全防止透過下面方式洩漏或竊取機密 ?
1 傳真
2 假冒主管郵件要資料
3 IT系統管理員,資料庫管理員等掌有資料讀取權限的人 竊取或洩漏
4 手機照相, 錄影 
5 紙本攜帶出去
6 錄音
7 假冒主管電話要資料
8 同仁嘴巴中 有意或無意洩漏
9 高層主管嘴巴或郵件中 有意或無意洩漏

或許前三項部分系統可以做到,但其他項目則需要靠建立制度嚇阻與員工的品格操守才能防止。

可見資安系統無法防止所有商業機密外洩的可能,這就表示真的有心竊取或洩密的人,一定有方法,那麼,花大錢的投資且造成企業效率不彰產生的大量成本,值得嗎? 因此,如何找到平衡點,避免資安系統成為企業效率 的殺手應該是老闆們該思考的。
 

2017年6月7日

[職場哲學] 鏡子與透鏡

作者: Fred Wang (FW知識瑣記) 日期: 2017/6/7

小林問同樣是主管的老陳,剛才開會時XX部的老李當大家的面直接批評你,你為什麼不反擊,還感謝他的指教,要是我,就當場跟他對槓。

老陳說,年輕時的我也是跟你一樣,後來,發現問題與誤解不會因此有任何的改變。我體會到,很多人都是鏡子,放射出甚麼,就會反射回甚麼,負面的批評只會造成負面的結果。久而久之,我反省自己是否可以成為透鏡,專注做好自己該做的,無愧於這份工作,任何批評與讚譽,對我而言,如同光穿透而過,消失於無形。

Fred F.M. Wang

2017年6月6日

解決苦命MIS的迷思 - 資管(IT/MIS)工作者的辛苦面,如何面對

作者: Fred Wang (FW知識瑣記) 日期: 2017/6/6

       根據筆者二十多年IT/MIS的工作經驗,針對資管(IT/MIS)工作者的辛苦面列出幾點常見的問題,並提供面對與解決方法,供相關工作者參考

問題 1. 常需要假日加班進行設備與系統維護,平日也多需24 hr On-call,非常辛苦
面對與解決方法 : 
  • 如同醫生或設備工程師等很多工作也需要假日加班或on call一樣,這是資管工作的常態。
  • 正視自己工作的重要性,IT/MIS的工作如空氣和水一般重要,如果沒做好,企業部分運作可能停擺。
  • 如何訂定設備維護計畫,事先規劃好加班的時間,才不會影響休假的安排。
  • 學習量化工作的貢獻,並定時報告,否則老闆平常不覺得您有甚麼特別的貢獻,系統出問題就會被責備。 

問題 2. 除了既定的工作外,常有主管的急件要處理及使用者緊急的問題要解決
面對與解決方法 : 
  • 要與主管溝通工作的優先順序,以確保使命必達。
  • 工作優先順序通常以主管訂定的為主,緊急且重要最優先。
  • 養成作工作日誌與待辦事項管理。

問題 3. 訂定的標準作業流程,常因主管要求破例處理
面對與解決方法 : 
  • 注意要用郵件回覆主管,以留下紀錄。
  • 商場如戰場,瞬息萬變,計畫與標準如果不具彈性將趕不上業務變化的需求。
  • 例外處理通常也有例外處理的程序。
  • 計畫與標準程序也要因應變化進行修正,否則淪於僵化。     

問題 4. 需求單位要求完成的時間不合理
面對與解決方法 : 
  • 溝通永遠不嫌少。
  • 跨組織溝通,有時須透過主管。
  • 以體諒的心態與善意的溝通,建立互信及合作關係。
  • 建立標準的需求處理程序。包含需求所需工時評估。
  • 如果人力或時間不足應求助於主管。

問題 5. 需求單位時常變更需求, 卻發生衝突的需求或忘記過去提的需求而責怪IT
面對與解決方法 : 
  • 將需求規格化與文件化進行確認,避免口頭溝通時認知的差距。
  • 建立標準的需求變更程序。
  • 做好需求管理,系統化紀錄每次的需求,包含內容,需求提出人,解決方法,所花工時,隨時可供查閱。

問題 6. 使用者無法清楚描述,要完成的功能規格
面對與解決方法 : 
  • 新流程或不明確的需求往往需Prototyping法設計
  • 透過許多次的需求討論 > 分析 > 設計 > 示範,才能完成
  • 先做業務流程化與制度化才能系統化

問題 7. 辛苦加班,如其完成的系統,用戶卻不測試驗收,甚至取消需求
面對與解決方法 : 
  • 需求處理程序包含需求了解與確認,IT/MIS實作,使用者測試與驗收,應事先開會溝通並留下紀錄,並應知會雙方主管。
  • IT/MIS責任在於如期如需求完成實作其他則是使用單位的責任。
  • IT/ MIS屬於企業資源各單位應有善用企業資源的認知, 將工作成本化,讓使用單位,了解每一次需求所花企業的成本有多少。
  • 如有不合理的情況應該透過主管進行溝通。

看完後,或許你會說,工作已經忙死了,還要做那麼多事; 我認為,如果及早養成好的習慣,也許開始時每天多花10%的時間,長久以來或許可以讓你擺脫IT/MIS苦命的惡性循環。

    [企業管理議題] 阻礙企業發展的一大因素 - 錯誤的稽核制度

    作者: Fred Wang (FW知識瑣記) 日期: 2017/6/6

    企業"稽核活動"常造成員工的困擾, 甚至有企業以稽核結果來處分員工。

    這是對的嗎?

    稽核是根據訂定的制度為基準來檢視員工是否根據制度執行。

    對小公司而言制度的制定者往往就是執行單位主管,因此,在執行過程中,發現該制度窒礙難行,就可以逕行修改。因此,制度的修改比較具有彈性並可執行。

    而大型公司或一些成立很久的公司,制度可能不是執行單位制定,而是策略管理部門,或執行單位的上層主管所制定的;老公司則可能是早期建立,而施行已久的制度。這些情況,加上企業保守的文化,制度的調整修改非常困難,對於跨組織的流程,更需要冗長的過程。

    往往執行單位發現制度在執行上有問題,缺乏彈性或不合時宜時,並沒有權限修訂,甚至沒有發言權。在這種情況,執行單位面對瞬息萬變的工作問題,需要立即應變時,執行單位只能有兩種選擇,第一是違反制度,讓工作順利進行,達到工作目標;第二是遵守制度,讓錯誤發生,或工作無法進行。

    制度制定的目的是避免重複發生錯誤,當制度成為阻礙企業應變,甚至讓工作無法順利進行的因素時,反成為阻礙企業發展的因素。