Re: [討論] 有人公司會故意埋蟲嗎?
※ 引述《phantom400 (魔彈射手)》之銘言：
: ※ 引述《ggg12345 (ggg)》之銘言：
: : 這種事, 從有軟體服務以來就有聽說.
: : 有看過原始碼類似 dirty code 的寫法, 就是不針對錯誤處做處理, 讓其
: : 留著不動, 後面再補加個程式片段對錯誤結果, 再從新處理蓋掉錯誤部份.
: : 這種原始碼不容易從流程追蹤發覺最終的資料處理片段.
: : 這只是不容易讓後手就原始碼維護, 但不是 "埋bug".
: : 很好奇 埋蟲 怎麼做又不會被發現 ?
: 單純回這個........
: 笨蛋蟲: 處理序號欄位時 , 只做了五位數的處理
: 資料筆數破十萬時就爆炸了........
: 更早以前還有碰過笨蛋百年蟲
: 去掉 yy/MM/dd 的斜線時用的是substring(3,2)之類的函式
: 99年沒事,100年之後就........
^^^^^^^^^^^^^^^^^^^^^
講到這個,又讓我燃起熊熊烈火了!!
客戶的需求是顯示日期用"民國"年來顯示,
而輸入時是用"西元"年來輸入(很矛盾)
然後不曉得是哪位天才,在資料表中宣告一個欄位來儲存日期,
欄位型態為 varchar , 進來的 yyyy 會先扣掉 1911
所以會產生 '99-01-01' 這樣的"字串"存在資料表中
要修改時再把 99 切割出來轉型態 +1911 再轉型態組合為字串
還原成 '2010-01-01' ... (好忙啊)
問題來了, 當SQL語法下了 order by 時 (不管 asc 或 desc)
出現 '99-12-31' VS '100-01-01', 悲劇就來了...
-----
不是只有一位這麼做...
: 不過看起來不像是故意埋的啦~~~~
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.127.139.239
推
09/29 22:54, , 1F
09/29 22:54, 1F
→
09/29 22:58, , 2F
09/29 22:58, 2F
推
09/30 00:45, , 3F
09/30 00:45, 3F
→
09/30 00:45, , 4F
09/30 00:45, 4F
推
09/30 19:51, , 5F
09/30 19:51, 5F
→
09/30 21:18, , 6F
09/30 21:18, 6F
→
10/01 00:05, , 7F
10/01 00:05, 7F
→
10/01 02:29, , 8F
10/01 02:29, 8F
→
10/02 11:13, , 9F
10/02 11:13, 9F
討論串 (同標題文章)