推 KanoLoa: @_@ Push ! 11/28 17:43
推 MelLynce:戲面訇술 01/10 00:48
→ MelLynce: 推 葉 教 授 01/10 00:49
※ 引述《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