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

看板CSSE (電腦科學及軟體工程)作者reader (讀者)時間16年前 (2008/11/26 04:09)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串4/6 (看更多)

※ 引述《ggg12345 (ggg)》之銘言： : 在學校裡面, 一群學生都做類似的問題, 這其中那些人是 code owner ? : 有那些人是兼 code inspector ? 又有那些人又兼任 moderator ? : 根據經驗, 在同一時程的限制下, 獲得老師給最高成績者通常是 moderator : 集大成之外, 又突出特異功能的當了 partial code owner . : 不過, 老師給分數是屬於價格性能比下的最有利標. : 在最低價格標的通常商場情況下, 就相當於是任課老師給最先繳卷又正確者 : 最高分. 此時, 成功率最高者就是 code inspector 兼 modified-code : owner. : 在學校的練習與成績是不具排他性的, 換句話說不像商場開標是屬贏者通吃, : 敗者做奴的獨佔性. 因此, 好朋友好學生就朋黨營私, 互當 code owner 與 : code inspector 但又互留一手, 自當 moderator. : 比較靈巧的就扮演情報收集者 (code & information collector) 當起 : 個體戶. 此時一枝獨秀, 在用情用間之下, 沛然莫之能敵. 但也就造就一堆 : 無法 maintain 的 code producer. : 這才是軟體發展的實況 ! 嗯，難得在軟體工程的討論中，出現一個比較具有現實意義的方向。沒有錯，軟體工程和其他的管理課題一樣，就某個角度而言，都是權力的鬥爭。在很多時候，軟體工程研究會出現一種不自覺的資方立場，將軟體工作者和他們所生產出來的程式碼異化，透過外加的管理方法來解決問題，而不是考慮如何協助軟體工作者。例如原 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: 118.171.85.84