Re: [請益] BUG少的程式 通常有什麼特色?

[ggg12345 (ggg)]

※ 引述《qrtt1 (有些事，有時候。。。)》之銘言：
: ※ 引述《p52189 (皮爺)》之銘言：
: : 從最開始亂寫，到後來聽了鄉民的意見，開始摸設計模式
: : 設計模式確實有效的解決我原本混亂的撰碼習慣
: : 而我自己也在黑暗中一邊摸索一邊嚐試修正
: : 不過
: : 即使一邊寫一邊提醒自己「不要亂寫不要亂寫不要亂寫」
: : 還是會有疏忽的地方
: : 每次都要花很多時間在完工之後的測試和bug修正
: : 甚至會有花在測試的時間比動手寫的時間還多的狀況!!
: : 我很想知道，bug少的程式究竟有些什麼樣的特質
:
: 經驗很淺相對的你有更多的機會經驗到習慣性產生的 bug！
: 這個題目與其去知道世界上最優美的程式是什麼，不如觀察自己如何寫出 bug。
:
: 是對於程式語言的語意掌握不足而產生的 Bug 嗎？
:
: 是寫作習慣有需要調整的部分嗎？
:
: 像是暫時性變數、付予多次意義。
:
: 像是輕忽初始化的重要性。
:
: 以上只是些『一般而論』的情況，但對你來說是否有意義是另一回事。
: 這些東西對你產生意義的情況只有一種，
: 那就是你也用『極為相似』的手法，寫出了 bug。
: 這時候你才會正確地聯結上，原來 bug 是來自於什麼樣的『壞習慣』。
:
: 討論這些也許很細節，但這才是能札實地改正習慣的事情。
: 所以，我會建議你問一些更具體、細節的問題。
: 我們實在不能籠統地討論如何不寫出 bug，而不了解你怎麼生產 bug 的。
: 如果你需要一些糟糕的範例，那你可以挑幾本 refactoring 的書籍。
: 你可以先看看有哪些 bad smell，並且指出自己習慣性產出哪些。
: 看看書上提供哪些建議，你評估一下要採用那一個手法改善。
==========
bug 發生的範圍很廣, 造成的原因各有不同來源.
上面提的都是 programmer 容易忽略的 "習慣" 問題, 此外就是語言的語法
與語意是否全瞭解所用的 compiler 與調用的 function library 的特性.

另一類的問題可能就是來自架構與演算法的問題.
舉個實際發生(1996)的例子:

程式送入資料開始執行, 然後停在某個位置說是該行指述有問題. 但調出原
始碼再看, 那行卻都沒問題. 但是重跑還是跑到某批資料就說程式的同樣那
行指述出問題. 把某些待處理的各批資料換先後處理的次序, 結果問題是換
發生在另一批資料, 出現在另一個程式指述上有問題. 整個大問題就變成無
法順利跑完所有的資料.

輸入的資料是學生選課畫的選課卡, 以班為一批收來處理. 只是這個選課處
理系統有優先次序, 譬如某個課班是某系某年級學生優先. 另外有些課例如
體育可以選很多個但可標明自己喜好的優先. 也就是說這是個有優先權的篩
選系統, 不單純是只用先搶先贏的時間次序做優先. 但同樣的優先權重下,
同優先的是要分派給那一個? 構想的方法是同比情況下就抽籤決定.

這個畫卡的選課系統是由課務主任帶學生完成的, 完成後硬是用了幾年, 但
每學期都是出現類似狀況, 聽說最後都用半人工去善後, 但也備受質疑. 也
不知改正多少次. 但 bug 不能 fixed, 其實也就解不了. 其中硬體的問題
也被懷疑, 譬如讀卡機一直就是有一定的錯誤率, 換機器兩次比對也會有不
同, 此時不同處就要人工核驗. 但也可能都讀錯.

===================================================================
選課系統就是典型的DP, 但從沒聽過這類 批次處理 會有 time dependent
隨不同時間有不同的結果這種現象. 但就聽見的情況言, 錯誤標示在不同指
述位置是隨資料的批次處理次序而異, 是 data dependent. 雖然說是有抽
籤但重跑都出現在同一指述, 顯然這個 pseudo random number 程式都是
開始從同一種子開始的亂數序. 所以結果都相同.

最後重做的系統是網路選課但仍維持優先志願篩選.
1.選課者從網路遞送選課資料, 可以送完即刻查驗送上的資料是否有誤.
2.篩選後可以從網站看到中選與落選者在某課號下的資訊, 譬如 系別 年級
  性別, 志願號, 籤號, 系或教師設定的過濾條件, 還有無法選上的原因.

新做的程式先經過公開試用測試, 同一選課者在不同課號下獲得的籤號都不
同. 不會籤王都是出現同一個人. 除了落選理由有些地方沒有細分說明很多
不合的原因被抱怨外, 其餘的質疑就不見了. 從那個班級或課號先分發, 或
對調批次資料次序, 結果都是順利跑完, 結果都相同.

被過濾掉的有時是很多條件不符, 但不是全面都條件檢查打勾再一併列出, 而
是有一項就被濾出只顯示攏統的條件不符, 質疑時就要費時間口舌去指明了.
發生這個抱怨的原因純脆就是系統規劃設計時, 沒有指明要全面列舉不合的條
件都要一一明白的列出. 不過, 後來也沒要求要這樣改過來, 算是不太友善.

那個 data dependent error 有可能是體育課的排他性志願分發造成的. 她是
要求最多只能選中一門課. 如果先從某課分發起, 就可能讓選該課的較低志願
者中選, 但等到處理某門課時, 同一選課者的高志願在此可能也中選, 這就發
生要到低志願中選的課那裡刪除中選者再補發下一個, 若補發的下一個也連鎖
反應可能又引發要刪除再補發另下一個. 這時候中間要暫記的資訊可能造成
call stack overflow 或其他 recursive call 的問題.

她的正確又有效的快速方法是排他性的體育志願課, 必須將各課號的第一志願
先分發, 然後刪除第一志願中選者的在其他志願課號裡的選課請求, 全部處理
完第一志願再處理第二志願, 逐次降低志願就能不必回溯, 直做到全部體育課
處理完 就是答案了.

====================================================================
資料結構的教科書對 code, data 是不做明顯的區分. 是就著 data 來說明處
理程序方法的效率與正確性.

bug 較少的程式是免不了要針對資料的性質採處理的對策. 忽視資料本身受到
處理需求造成的性質改變, 譬如是否會發生 data dependency 這類問題, 那
就要能認知與能有正確的對策.

再說那個同比抽籤, 若當真是理想的籤筒, 每次重跑應該不同. 這種程式要從
輸入的資料與輸出的結果比對要驗證程式的正確性就麻煩了. 反覆測都可能是
不同的結果.

所以解法是 分發前就不同的課號 依當次選一個種子 給不同課號有不同的開始
種子, 課號的開始種子再對依時序進來的不同選課者的選課請求, 先給不重覆
的籤號以備其發生同比時可以被區別高低優先. 萬一程式重跑或停電續跑都能
從未分發完成的該課號某個階段重跑就行了, 譬如低志願刪除就不受影響, 因
為選課者在同課號下的籤號沒變, 中選者重跑時仍然是中選, 較低志願仍然該
被刪除, 重跑時, 已刪的低志願並不影響結果.

網路收到的選課請求都是每筆 append 到檔案, 才再分送到不同課號下篩選,
重覆的部份會被剃除. 一旦有記錄之後就有複製備援, 都不必再重新重選課.

bug 較少的程式, 若從架構與方法規範看起, 就能先聞出好壞的味道了.

→ specman:說真的, 我看不懂這篇文章再說什麼...
→ bobju:me2..我比較喜歡看[小米加步槍]系列的...
說的是一個實際發生的例子: 就是大學的選課系統, 只是這系統允許就選的
同性質課(如體育, 通識類)指定多門想選的課但有優先意願, 某些課也給某
些學生的系級身份設定優先(如體育大四優先), 有些課可以同時選上(如通識),
有些則是只能擇一(如體育). 篩選比較的條件如果都相同, 那就抽籤決定. 這
是一個選課志願分發系統.

這個系統是由老師帶學生開發的, 碰到的問題(BUG)就是會停在某個指述說有錯
誤, 然後機器停止不跑了(有錯誤), 但那行指述並沒有任何語法或語義的錯誤.
出現錯誤的位置則隨資料處理次序而不同, 如先做A班再做B班再C班,A->B->C不
同於做C->A->B時發出指述錯誤停下來的位置, 但某些資料下, 也可能都沒錯誤
發生.

→ LearnRPG:喵啊 這篇是不是英文直接丟google翻譯出來的 XD看都沒有
寫程式寫出 data depend error 這種 BUG, 也算是偉大的機遇.
相信這裡說的每行字各位都看得懂, 只是沒碰到這種 bug 的經驗下, 就串不起來
到底是怎麼回事. 這個看不懂是出在無從想像這是甚麼東東(也就是不相信).

1.這個會出錯的程式應該是有跑過 test data 驗證. 所以少量測試資料下不出錯.
  大量資料下可能出錯, 但也可能不出錯.

因為找不出程式那裡有寫錯, 當時做的人就發現有下列變通方法:

2.出錯時, 把發生錯誤正處理的那個班調到最後, 再一切重做, 可能就順利跑完都不
  會出錯. 但也可能後面補進的還是在其後某個班出錯.
3.有錯, 就照做2的方式, 把出錯的班調到出錯那堆後面, 依新排的次序再從頭重做.
  出錯那堆那個先那個後, 也有可能都過不了關.

不管最後是否能過關? 教務處就是不肯接收這個程式, 因為不知甚麼時候會不會就跑
不出來.

==========================================================================
這個 bug 發生的現象跟有些程式發生 stack overflow 以致程式亂跑是很像的.

這些選課資料不是處理完一個班就不會再被處理, 因為一個班選該課的意願優先
未必人人相同. 假如以班為單位先按可選的人數分派, 有可能某生的低意願選課
被分派進去, 但到另一班處理時該生的高意願選課可能也中選, 如果規定同類的
課只能擇一不能複選. 先被分派的低優先就得剃除再找候補補上空位, 但補上的
候補可能引發這候補在其他同類課被先選上的低意願選課必須再被剃除. 也就是
演算法如沒事先分析好, 排除這種回溯狀況, 使之絕不發生, 就可能因資料的不
同與處理的先後次序差異, 造成回溯已處理過的班級資料需要再處理, 回溯有可
能又引發再回溯, 處理的班級就回頭引發更多的已處理過的班級. 資料或程式就
有可能回溯自己本身. 通常要正確處理這種 recursive call 就需耗用大量的
stack area 暫存中間結果. 此時若回溯太多層, stack overflow 就隨資料的處
理次序, 看狀況會發生或不發生了.

邏輯上, 寫程式者的習慣就是直接就問題解問題, 甚麼狀況就怎麼對付. 但萬一
最壞狀況碰上了, 譬如這個回溯剔除 補添候補, 補添候補又連鎖發生, 造成系統
給的 stack 或 temp 超用, 就出錯了. 而測試的資料可能沒如此巧合而測不出,
或者因引入抽籤變得程式執行更難追蹤.

→ ah7675:哪來什麼相不相信 是看不出你想表達什麼 又不是聽不清楚
→ ah7675:你把內容重復打一次意義何在？ 只有內容沒有重點

bug多還是少, 可能不比 找不出 BUG 何在 還嚴重.
不是資料多少, 而是某些奇特資料或資料次序變化就出狀況, 這BUG不僅在, 還很致命.
若 bug 隨狀況才出現, 那是算多還是少?

會出 bug 的程式, 就是分析的狀況不夠深入, 根本問題就出在架構與算法.
也就是只看表面處理的邏輯好像沒錯, 但就是沒想到"怎會這樣?", 因為觸犯
到系統支援的底線, 因沒整體感覺, 所以除不了錯, 也不認識到這種錯的特點.

程式須在硬體與系統的框架裡執行, 好的程式就是 bug 最少的程式, 也就是
讓程式搭配硬體系統去擴展軟體使之配合要解決的問題型態, 不致發生系統
無法適合搭配問題, 也就是軟體加上硬體不致於發生兜不出問題的解決方案.
這種搭配就顯現在架構(Architecture)及其上的算法.

這個特色就是展現在 架構的簡潔與針對問題的有效性上.

推 atpx:其實大家都知道你在講什麼問題, 只是你的文章打完最好自己再
→ atpx:看一次, 有些語句斷頭去尾導致沒有邏輯性, 讓人不知所云
這個問題 發生的狀況與現象 就是 看起來 像是發生 data depend crash. 這在
一個成批處理的DP裡是很難被認為會發生的, 處理後的結果可能會出錯, 但不會
造成 program crash. 所以, 成因是甚麼? 我不想武斷的猜測, 敘述上是收到的
訊息原狀, 推論與矛盾是並存的.

這現象造成的原因不清楚. 這個程式並沒有被找出真正的錯誤排除, 所以很難被
界定(bug not fixed). 這系統經過多次的實際使用, 企圖去除錯是一定的, 可是
沒有達成目標, 應該就是 bug 不明. 這個程式在解決不了之下, 先以原平台系統
老舊, 要求引進新的軟硬體平台, 其中一個合理猜測就是認為硬體不穩, 容量不
足. 引進新硬體與系統的事也在進行中, 只是使用單位在換了領導人之後找了其
他的教授專家們開始檢視軟體的需求與最終在平台的實現要如何進行.

    原來發展的團隊並不肯拿出原程式讓別人去測試. 只解釋了使用單位因 data
depend crash 現象, 不肯同意完全接收使用. 團隊成員只是想將運作工作交給電
算中心承接. 他們並沒有認為 program crash 是程式而起, 甚至認為學校怎麼使
用如此不可靠的 "國產讀卡機", 經常會有不同辨識結果. 但錯誤的資料只是產生
錯誤結果, 在有data type range查核下就能事先檢出, 但要造成 crash 那是另
一回事.

    同條件抽籤篩選跟多拿一個條件來比較並無不同, 只要不公布是用那個條件?
在使用者搞不清楚下就如同抽籤現象. 這個發展團隊雖不明說, 但承認發生crash
時若再重新做, crash 還是發生在同一班同一指述, 所以這現象不受抽籤的亂數
影響. 這個抽籤需求, 從系統使用以來, 一直也就被質疑不是那麼無序. 換言之,
是被質疑過 crash 原因之一, 不全然就是亂碼抽籤.

    事情的直轉而下, 就是該軟體被新任的課務組主任拿去找校外的單位, 透過
不同的硬體系統處理該學期的選課資料, 然後跑不出選課結果, 最後以緊急加人
的人工系統善後. 事情就演變成學校的電算中心要緊急重做一套新系統.

bug 多還是少, 那就是兩種系統的比較. 新做的放棄劃卡改用網路, 使用者要上
網查看送上的選課資料, 可以看見抽的籤號, 可以看見其他選課者與自己設定的
優先狀況與處理後結果, 也可看見最熱門的課經篩選後的情況.

新系統針對優先採用不必回溯的演算法, 每門課的條件都改為可用事先選擇的代
號與設定表設定, 以配合每門課的不同需要.
========
data depend crash 或 time depend error/crash 絕對是電腦系統要排除的狀況.
因為沒人能接受這種系統. 但軟體若觸犯硬體系統的極限, 可能就會發生, 好的
或 bug 少的系統會事先儘量排除這種可能性.

※ 編輯: ggg12345        來自: 140.115.4.90         (05/05 17:51)