Re: [討論] 有人公司會故意埋蟲嗎?

[gname ((′口‵)↗︴<><...<><)]

※ 引述《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
推 phantom400:寫個DB function轉成datetime再比吧
→ leiyan:遇到這種客戶只好佛心一點2種都寫
推 lance70176:這個有遇過 100年的時候警局一堆系統當機
→ lance70176:當年寫的人還有佛心的留下註記 100年要改哪...
推 onear:就直接在資料庫把99改成099就好啦..
→ wa120:在開一個西元的dateime欄位跟民國的共存
→ gname:嗯...解法很多,問題是...原始的設計概念...
→ ggg12345:假如都沒有source program能改嗎?
→ gname:沒有原始碼只能進DB硬幹了...= =