※ 引述《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