Re: [請益] BUG少的程式 通常有什麼特色?
推
05/05 15:11, , 1F
05/05 15:11, 1F
→
05/05 15:12, , 2F
05/05 15:12, 2F
BUG 少 或 BUG 多, 最主要的比較法就是有兩個同類性質功能的程式可以 計數
比較.
有bug, 其實沒有多嚴重的問題, 怕的是不知道 bug 在那裡.
造個橋只能承重 20 頓, 偏要開個 50 頓的坦克過去, 橋垮了那未必是造橋者
的錯, 如果他已經給了警示的話.
找到 bug, 一時改不了, 總是可以想辦法或要求閃避不用. 所以 bug 少的也可
以說限制使用的情況比較少. 或是想要的功能沒有發生部份不能用. 程式全然
沒有實現, 那是全都不能用. 程式寫了若大部份都可以用, 偏就是某些狀況不許
用, 相比之下, 可能就是 bug較多, 解決不了做了迴避.
bug 少, 顯然也不會只是限制 不能使用的數量 多寡問題. bug 少或沒有嚴重
失誤的bug在內, 就是不能發生無法預期的 program crash 現象. 但這種會有
program crash 發生的程式, 就是不容易追查.
=====================================================================
這個選課實例 發生的狀況與現象 就是 看起來 像是發生 data depend crash.
這在一個成批處理的DP裡是很難被認為會發生的, DP處理後的結果可能會出錯,
但不會造成 program crash. 所以, 成因是甚麼? 我不想武斷的猜測, 這裡敘述
的是收到的訊息原狀, 推論與矛盾是並存的. 所以不存在確認的 bug 原因.
這例子造成的原因不清楚. 因為這個程式並沒有被找出真正的錯誤排除, 所以很
難被界定(bug not fixed). 但這系統有經過多次的實際使用, 企圖去除錯是一定
的, 可是沒有達成目標, 應該就是 bug 不明. 這個程式在解決不了之下, 先以原
平台系統老舊, 要求引進新的軟硬體平台, 其中一個合理猜測就是認為硬體不穩,
容量不足. 引進新硬體與系統的事也發生進行中. 只是使用單位在換了領導人之
後找了其他的教授專家們開始檢視軟體的需求, 檢討最終在平台的實現要如何進
行.
可是, 原來發展的團隊並不肯拿出原程式讓別人去測試. 只解釋了使用單位因
data depend crash 現象, 不願完全接收使用. 團隊成員只是想將運作工作交給電
算中心承接. 他們並沒有認為 program crash 是程式而起, 甚至認為學校怎麼使
用如此不可靠的 "國產讀卡機", 經常會有不同辨識結果.
輸入錯誤的資料只是產生錯誤結果, 在有data type range查核下是能事先檢出
的, 但要造成 program crash 那是另一回事了.
同條件靠抽籤篩選跟多拿一個條件來比較並無不同, 只要不公布是用那個條件.
在使用者搞不清楚下就如同是抽籤現象. 這個發展團隊雖沒有明說, 但承認發生
crash時若再重新做, crash 還是發生在同一班同一指述, 所以這現象不受抽籤的亂
數影響. 這個抽籤需求, 從系統使用以來, 一直也就被選課學生質疑不是那麼無序.
換言之, 對抽籤可能質疑過是 crash 原因之一, 試過改成不是亂碼抽籤.
事情的直轉而下, 就是該軟體被新任的課務組主任拿去找校外的單位, 透過不
同的硬體系統處理該學期的選課資料, 然後是最後跑不出選課結果, 變成以緊急加
人的人工系統善後. 事情就演變成非要學校電算中心緊急重做一套新系統.
==========================================================================
bug多還是少, 那就是兩種同類系統比較之後才能明顯判斷. 新做的系統放棄劃
卡改用網路, 使用者要上網查看送上的選課資料是否跟原來的相同, 這就排除了讀卡
機的正確率與輸入卡片的核驗問題. 上網可以看見抽的籤號, 可以看見其他選課者與
自己設定的優先狀況與處理後結果, 也可看見最熱門的課經篩選後的情況. 就是讓選
課學生可全面查驗處理結果是否照規範進行, 是很透澈的測驗. 這系統完成時有經過
模擬試用, 但修改處很少.
新系統針對優先採用不必回溯的演算法, 每門課的條件都改為可用事先選擇的代
號與設定表設定, 以配合每門課的不同需要.
不必回溯是能快速有效, 但後來在做大學招生分發時, 也試過按個人資料分發還
是按系班為單位分發, 結果是全相同, 只是時間上差異很大而已. 並沒有 program
crash 現象發生.
========
data depend crash 或 time depend error/crash 絕對是電腦系統要排除的狀況.
因為沒人能接受這種系統. 但軟體若觸犯硬體或系統的極限, 可能就會發生, 好的
或 bug 少的系統會事先儘量排除這種可能性. 這種系統會在架構或算法上就呈現
設計思惟, 事先的認知會驅駛程式工程師 儘量使系統 在這類bug上不致發生.
bug少的程式, 在架構或算法上會在其設計上就展現出明顯特色.
有圍牆的平面屋頂與雙斜面屋頂, 在發生屋頂漏水的機率上就是不一樣. 但如果
真的做的很牢靠堅實, 有圍牆的平面屋頂也是能做到不漏水. 可是就簡潔有效言,
斜面屋頂就是容易防漏水.
*********
這個架構與事先預防的例子在十多年後又明顯的發生.
這個重寫的網路選課系統用了超過十年, 也配合對課程的評量管制做過修改.
一直都愉快無事.
但最近因配合外籍生 需外語顯示 就又大改了一次. 可是改之後就出一些 bug.
原先的系統使用 網頁的部份 只是下載課程表, 點選的加退選課 是在 client
端自行準備好, 與server是可以脫離的. 要加退選時才將點選過的課用 e-mail
形式送給一台要辨識帳號密碼的 mail server, 需先輸入帳密驗明身份才會發
送選課單. 所以沒有選很久時, web 連線斷線的問題, 也不會發生點選後, 弄
不清楚有沒有送出的情況.
送進的資料經 file redirection 送到收集的資料庫(dbm) 貼到 BBS, 查閱
顯示可以是 web browser 的 html 格式. 資料進入都是採 append & log
所以不怕斷線, 重覆或蕩機, 也能復原.
當時的考量就是 web 適合查詢瀏覽, 而且是 stateless 用法. 一般的 資
料異動就得用 3-tier 的 databse 當後台. 那時因資料庫採用那個系統爭
議未決, 所以是不與資料庫直接連動, 而用 BBS 與 db/dbm 代用, 資料要
互抄與真正的教務處資料庫是隔離的.
但新做的系統就採時下流行的 web 作法, 結果一使用就是掛上的連線太多,
經常發生點選的網頁下不來. 加退選的資料用 http 訊息傳送, 就發生在
client 端網頁看見的, 點選的, 與server 不同. 也就是沒有發送給server
做記錄.
這個問題可以說又改回原先不想採用的架構, 就發生這一堆的困擾, 變成使
用者忘了一些必須做的動作, 系統也沒有去查出提醒, 實際就是沒有送出.
相較之下, 新系統就帶來一些惡評, 還得去除會造成誤會失誤的 bug.
好的架構與演算法 就會事先排除掉可能發生的失誤.
※ 編輯: ggg12345 來自: 140.115.4.90 (05/07 02:10)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 10 篇)：