最近修改的幾個 bug，問題不大，查找起來卻幾番周折，匯總起來如下。
1.詭異電話號碼
客服郵件反饋，很多用戶服務熱線變成了“0371-45875487”?？吹竭@問題的第一反映是可能因為程序某個地方有人不小心寫死了“0371-45875487”，因為服務熱線對應數據庫為一個字段ServiceTelephone，自然的把“0371-45875487”想象成了一個整體，在web解決方案中查找關鍵字“0371-45875487”，沒有結果，數據庫存儲過程查找一遍，也沒有結果，思路中斷了，就先把數據處理了下，原因待查。
沒幾天，客服又反饋用戶服務熱線好多又變成了“0371-45875487”，再次超找問題，方式和上次一樣，只是搜索關鍵詞變成了“45875487”，沒想到很順利的定位到了問題。出現問題是在個人資料修改頁，截取部分代碼如下：
<tr> <td align="right" valign="middle" bgcolor="#F9F9F9"> 服務熱線：</td> <td align="left" valign="middle"> <input name="mendiantelephone1" type="text" id="mendiantelephone1" style="width: 30px;" value="0371" size="4" maxlength="5" runat="server" /> - <input name="mendiantelephone2" type="text" id="mendiantelephone2" style="width: 50px;" value="45875487" maxlength="8" runat="server" /></td> </tr>
if (!string.IsNullOrEmpty(AgentInfo.MendianTelephone)) { mendiantelephone1.Value = AgentInfo.MendianTelephone.IndexOf("-") < 0 ? "" : AgentInfo.MendianTelephone.Substring(0, AgentInfo.MendianTelephone.IndexOf("-")); mendiantelephone2.Value = AgentInfo.MendianTelephone.IndexOf("-") < 0 ? AgentInfo.MendianTelephone : AgentInfo.MendianTelephone.Substring(AgentInfo.MendianTelephone.IndexOf("-") + 1); }
如果用戶原來沒有填寫服務熱線，在修改頁這兩個控件的值默認成了“0371”和“45875487”，用戶好不知情的情況下把自己的服務熱線修改錯了。問題修改也很容易，直接把默認值去掉即可。
這問題告訴我們看似詭異的問題肯定也有其原因的，查找問題時可以縮小搜索關鍵詞。
2.同名緩存帶來的問題
問題描述：惠州房源信息，同一樓盤對應的區縣、商圈竟然出現了不同值，如小區三千俊林對應的區縣商圈出現了兩組“惠州 惠陽區”和“惠陽 淡水"。查找原因原來是用到了同名緩存造成的，代碼如下：
/// <summary> /// 根據newcode 獲取樓盤字典信息 /// </summary> public DataTable GetBuildingDicByNewcode(CityBase citySite, long newcode, string PRojtype) { DataTable dt = new DataTable(); string oewname = "districtinfo_bus_around" + newcode.ToString() + "_" + projtype + "new"; string cachename = CacheType.housedic + "_" + oewname; //先取數據緩存 if (this.MemCache.KeyExists(cachename)) { dt = this.MemCache.Get<DataTable>(cachename); } else { dt = buildingErrorData.GetBuildingDicByNewcode(citySite, newcode, projtype); this.MemCache.Set(cachename, dt, DateTime.Now.AddDays(1)); } return dt; }
區縣商圈都是根據樓盤編號獲取的，而樓盤編號在全國都是唯一的，不會重復，這段代碼看似沒什么問題，那問題在哪呢？原來還有一個異地樓盤業務，就是深圳可以調用惠州的樓盤，調用的時候惠州就成了深圳的區縣了，相當于深圳和惠州同一樓盤的區縣商圈屬性不同。
這問題出現是因為新業務的出現造成了老代碼出現問題，新做業務時方方面面得考慮周全才行。
3.重復提交問題
問題描述：在用戶進行放心房操作時，有個計數的字段，每設置一條計數字段+1，每取消一次計算字段-1，但這計數字段卻出現了負數的情況。查找問題，最終出現在了用戶重復提交上，而且從數據上看是有用戶發現了這一漏洞，惡意提交了數據。
public bool CancelRealHouse(CityBase citySite, HouSEOptEntity optEntity, HouseType htype = HouseType.Sale) { //刷新房源并設置標簽 rowCount = houseDAO.UpdateRealHouseStatus(citySite, htype, optEntity.AgentId, optEntity.HouseIds, string.Empty, false); //調整操作數,只有設置上了放心房標簽才會去調整 if (rowCount > 0) { this.houseBizMember.AgentPowerUsingBiz.HouseAction(citySite, htype, HouseAction.UnRealHouse, optEntity.AgentId, rowCount, rowCount, 0); } } public int UpdateRealHouseStatus(CityBase citySite, HouseType houseType, int agentId, List<int> houseIds, string infoCode, bool isSet) { int retVal = 0; int isRealHouse = isSet ? 1 : 0; DBHelper db = DBHelper.GetDBHelper(BusinessType.AgentHouseWrite, citySite, agentId); string tableName = GetTableName(citySite, houseType, true); string refTableName = GetRefreshTableName(citySite, houseType); string houseIdsStr = string.Join<int>(",", houseIds); string sql = sql = string.Format("update {0} set isRealHouse = {1} where agentid={2} and status = 1 and isRealHouse != {1} and houseid in ({3});", tableName, isRealHouse, agentId, houseIdsStr); retVal = db.ExecuteNonQuery(CommandType.Text, sql); sql = string.Format("update s set s.registdate = getdate(),s.dtimestamp=getdate() from {0} s inner join {1} h with(nolock) on s.houseid = h.houseid where h.agentid={2} and h.[status]=1 and h.houseid in ({3})", refTableName, tableName, agentId, houseIdsStr); retVal = db.ExecuteNonQuery(CommandType.Text, sql); return retVal; }
問題出現在函數UpdateRealHouseStatus()上，這個函數執行了兩個操作，一個是更新是否放心房，其實這步驟是沒問題的，取消狀態時，如果原本就是取消狀態，這個返回的就是0，但問題出現在第二個操作上，重新給返回值賦值了，致使重復提交了返回值仍然為1，進而造成最終的計數有問題。
這問題告訴我們在重要操作上，一定要做好重復提交的判斷。這問題發現的隱蔽性在于一個函數做了兩件事，也和函數功能單一化原則相悖，合理的函數代碼也有助于降低這種錯誤的概率。
新聞熱點
疑難解答
