Re: [分享] 輕鬆談軟工--code inspection的代價

看板CSSE (電腦科學及軟體工程)作者ggg12345 (ggg)時間16年前 (2008/11/26 11:12)推噓2(2推 0噓 1→)

留言3則, 2人參與討論串5/6 (看更多)

※ 引述《reader (讀者)》之銘言： : : 在學校的練習與成績是不具排他性的, 換句話說不像商場開標是屬贏者通吃, : : 敗者做奴的獨佔性. 因此, 好朋友好學生就朋黨營私, 互當 code owner 與 : : code inspector 但又互留一手, 自當 moderator. : : 比較靈巧的就扮演情報收集者 (code & information collector) 當起 : : 個體戶. 此時一枝獨秀, 在用情用間之下, 沛然莫之能敵. 但也就造就一堆 : : 無法 maintain 的 code producer. : : 這才是軟體發展的實況 ! : 嗯，難得在軟體工程的討論中，出現一個比較具有現實意義的方向。 : 沒有錯，軟體工程和其他的管理課題一樣，就某個角度而言，都是權力的鬥爭。 : 在很多時候，軟體工程研究會出現一種不自覺的資方立場， ======== 工程一詞較現代的用法是 Engineering , 這是蒸汽動力機械 Engine 出來後的用法. 工程師就是製造與運作那台很有威力的 Engine 的人. 引擎的出力與耗資源程度都是工程師該 "估算" 或 "實測" 出來的. 若是推到更古老一點, 此時的工程對象就是 "土木". 水利築壩, 防禦築牆, 遇水架橋, 遇山開路. 這些都要 "一群人" 去做, 而且很大一部份的原因是軍事上的生存需要. 在一群人的分工運作下, producer , inspector, moderator 很自然地就出來了. 工程師的任務就會像打戰的將軍那樣, 要在有限資源的情況下, 估算出需要的投入(物質與人力), 並在最短的時限內完成某種要求的成果( 例如道路的運輸量). 限時限物下, 工程師就可能照搬 pipleline 生產線來組織人力與運作, 畢竟他得要估算各種方案在時限下完成. 如果是人做事從來就沒有不需要 review 與 check 的, 至少也得自己做這份查驗工作. 但自己做跟分工做在時效與核實上就因使用的機制(如 pipleline)會有所不同. 假如工程是為了爭戰(商戰)贏利, 戰敗之下, 工程師開了馬路造了城牆又有何用 ? 此時工程師在估算前總不免會問為何而戰, 為誰而戰 ? 這種參與群眾的疑問, 小至小兵與工人都會發生. 在我們現在的體制下就稱為政治與管理問題. 工程師顧名思義在分工體制(就是階級機制)下, 大概是當不了將軍與政治領袖的權責的. 軟體工程對象是 "software", 用的就是 "組裝的工程辦法與估算法". 通常打戰的將軍會懂工程辦法的作用, 譬如火砲, 防禦工事與人力的數量與素質, 而且是像中國兵書說的 "多算勝, 少算不勝", 也是很會估算的. 現代的將軍在運用資源與 "動員" 方面, 就可能不是只會 "兵多馬壯砲多" 者勝, 會來個出其不意, 攻其不備, 還會鼓舞士氣摸黑夜襲. 吃了這種招式敗戰隊伍裡的工程師當然是猛怨嘆, 算馬路造半天還猛檢驗有何屁用 ? 工程製造與軍隊都是免不了組織與動員人群去 "做事", 但假如 "多算勝, 少算不勝" 這原則是成立的, 算計不到(例如想不到對手夜襲)就會是敗. 因此, 工程估算與預案還是很基本的教育養成. 就打戰的軍隊言, 動員士氣與資源協調的俄式"政委", 美式"憲兵與牧師", 德式 "黑衫軍", 日式 "天皇", 都屬組織機制與管理問題, 都是階層式架構的階級組織. 工程師只能就大架構下的分工做時程與資源需要估算, 並不上升到 "國家存亡" 的領袖權責. 就任何組織裡的所有成員言, 在政治上, 整個群體的組織分工與運作法都是要協助所有成員的, 包含確保必勝(有待證明的宣傳語)的 "督戰隊" , 只是 "督戰隊" 是否有誠信並受到信任 ? 萬一在資源欠缺下, 能否"自願性" 的督促自己 ? 當然, 這樣做已從可估算可照搬照做的 "工程" 變成了 "政治" 管理. 世界上最講政治的軍隊一定是裝備差, 資源缺的窮人軍隊. 賣命賣力的光天化日下幹, 當然是不如靈巧的埋伏夜襲. 但夜襲也是要能先估算, 先探與事先模擬的, 還是要有方法可以讓多數人照搬照演. 工程學系畢竟不在法商學院裡, 對待人的政治性管理絕對是重要, 隨時都要最先考量. 但架不了橋, 築不了工事, 遇到障礙就解不了, 時程內無法保證到得了, 那能不吃敗戰 ? 軟體工程沒那麼神, 但還是要講要有的, 畢竟這世界日夜交替, 世界的道理不會只站到某一時某一邊. 當然, 軟體產業起不來, 不會是只有軟體工程教育有問題 ! : 將軟體工作者和他們所生產出來的程式碼異化， : 透過外加的管理方法來解決問題，而不是考慮如何協助軟體工作者。 : 例如原 po 的這一題，行之有年的 peer review 制度到哪裡去了? : 我們如何能將程式碼視為一種以行數做單位、具有平坦思維深度的產品? : 不是軟體開發團隊的人，要怎麼有效理解一個軟體的內部邏輯? : 程式碼之外的文件準備，是為了開發而做的，還是為了檢視而做的? : 甚至，軟體檢視工作是一種可以在眾多巨大變因下量化的東西嗎? : 這還是淺層的問題，更深一層的問題就是權力問題了， ====== 這些疑問都是該問的. 但一個社會群體是甚麼關係呢 ? 有生物群就有分工互依, 就有人所認為的階層階級, 但生物鍊的底層斷了, 上層的猛獸也會隨之滅種. 拔尖的教育思惟, 讓大家無法互信, 就實際的世界言, 不應該是這樣的. 問題根源就是來自政治領袖的惡習, "領袖因替部眾製造敵人而存在". 工程思惟的優勢就是排除政治背後的猜疑, 純就時間與資源考量. : 在這個生產體系中，對於 programmer 而言， : 他要怎麼做才是最有利的? : 例如有一些軟體工程方案，會造成 code 愈難閱讀對 programmer 愈有利， : 那麼這個軟體機構的生產成本就會幾近無限制地上昇， : 因為 programmer 不是笨蛋。這是心理動機與政治協商的問題, 當然也是不可完全被忽視的問題. : 軟體工程方案如果只從資方的角度來製作，這種情況是很容易發生的。 : 像這個 code inspection project : 如果讓 programmer 認為外來的 inspector 會讓他損失價值， : 那麼所有的文件和準備工作都必須專為檢視而做， : code 當中難解的部分也將得不到合宜的開發者支援， : 軟體檢視成本將很可能高過軟體開發成本，於是這個檢視方案就註定失敗， : 任何人都算不出一個可行的軟體檢視成本。 : 反之，若是 code inspection 對於 programmer 有利， : 那麼 programmer 就可能會自行利用 peer review 的方式來處理， : 甚至不花費額外的成本，僅僅是開發工作的一環， : 其實我並不認為 code inspection 是一件需要外部的 inspector 來做的事情， : 一旦出現這個情形，就表示軟體開發團隊已經出問題或根本沒有組織好， : 不然在軟體開發過程中， : 每一行程式碼本來就應該是經由許多方面一次次檢視的。 : 我從來就不認同那種將 coding 視作是軟體開發過程中最不重要的部分的 : 那種舊式軟體工程觀點， : 我認為愈想降低 programmer 的重要性，就愈得不到高品質的軟體。如何把人分階級高低與級別待遇, 是政治問題. 例如只看出生地與種族, 但軟體工程不可能涉及這種認定. 一個組織的分工組成當然是涉及其團體目標與利益, 在市場交易制度下, 成員可以用腳選擇甚至動手參與改造, 可是這很難成為軟體工程的探討對象. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.4.12