8月1號凌晨的時候，我在夢中被叫醒，讓我立即去公司看乙個問題並且修改。我心裡當然有點小鬱悶，工作還是必須的。到了公司後，聽專案負責人描述了下，有3萬多條出賬的資料無法扣費。原來是通過使用者id進行入賬扣費。局方突然改為寬頻id進入入賬。導致了這個結果。當然寬頻id也必須保證是可以入賬的。檢視了下這3萬條資料的寬頻id都是被截斷了。
這個錯誤非常低階，原來的開發人員把寬頻id定義成20位，超過20位的都被截斷了。所以無法入賬。查詢了一下資料庫，資料庫寬頻id欄位定義為64位。那麼他應該定義成65位。真不知道這個傢伙當時怎麼想的。猜想他可能看到介面文件定義成20位了，然後他就寫了20位，可是介面文件明明也寫著64位。那我就沒辦法了。修改這個問題當然簡單，可是它造成的影響實在太大了，因為這個公司進行了乙個星期的質量版本回溯。浪費了更多的成本和時間。也導致c團隊的信任度下降。導致這樣的問題出現還有乙個原因。就是我們公司c,c++開發人員只有乙個人，在沒有競爭的環境下，乙個人是非常有惰性的，也有非常強的隨意性。為什麼公司長期都存在這樣的情況，那就不是我可以解決的了。
這個時候我想起了華為的做法，se在做設計的時候，對於設計到重要變數都會有乙個標識，連名字都很準確，長度也是固定的，這樣就保證了開發人員有依據。而不是根據自己的判斷或者喜好進行編寫。這就是細節的做法，並不是因為開發人員的水平低的問題。開發人員每編寫乙個語句都需要仔細斟酌，好好推敲。每乙個語句都有它存在的原因，如果你自己都無法解釋清楚，那這**的質量就有待檢查了。**自查大家都知道，但真正做到的卻非常少，之前我有個同事，也是我的導師，他的做事方法讓我非常佩服。編寫完**後，會進行優化的處理，然後會自查幾遍，然後再自己自查，然後讓同事幫忙檢查，最後提交**的時候，還會和其他版本比較一下。他做什麼事都必須找出乙個原因。模擬兩可的答案在他那裡更本不存在。
雖然只是乙個定義問題，可是嚴重到無法用缺陷率來衡量。這次的經歷讓我真正體會到了一句話：「編**的是門藝術」，什麼時候你把這門課**的讀仔細了，那才算入門了吧！
乙個引數引起的血案
問題產生實際情況 資料庫被強制乾掉，空間漲到100 分析 經觀察發現是由於pg log目錄增長過快導致磁碟空間被爆。pg log是如何產生的？記錄資料庫執行日誌，內容可讀，預設關閉，需要設定引數啟動。1.error資訊。2.定位慢查詢sql。3.資料庫的啟動關閉資訊。4.pg系統相關警告資訊等。根據...
乙個ID引起的血案
最近用asp寫程式時，剛開始支援的資料庫是access，程式裡有一段 是往資料庫裡新添一條記錄，方法為先建立乙個recordset，然後用addnew和update方法來實現資料新增。addnew之後便能取得新增記錄的id號。後來程式移植到伺服器上時，由於伺服器安裝的是sql server 2000...
乙個BOM引起的Hessian血案
6月11日下午專案上線乙個新的功能之後，12日上午發現，與外部服務通過hessian互動的功能失效。一邊與兄弟部門的同學一起查詢一邊進行 回滾 也是我到公司一年以來第一次 回滾 發現呼叫hessian時候會報錯 1 2 3 4 5 6 7 8 9 10 12 jun 201506 47 44utc ...