結束一周的緊張工作，難得的休息時光，坐在電腦前瀏覽部落格、聽聽歌、看看大片，這也算是一種享受。
因為年度的開發任務已經開始了，所以最近會特別忙，新人的成長又沒有想象中的好，經常在他們身上看到自己去年的影子，對什麼都不了解，自己去學習這個框架又不知從何入手，問也不知怎麼問。當時專案組也缺人，就這麼加入專案，開始了不斷地加班不斷學習的過程。這種成長的經歷記憶深刻。現在帶新人，也會從去年自己的經歷吸取教訓，巴不得把自己了解的所有的東西都教給他們。
言歸正傳。上週一，一上班就接到任務，在這裡暫且稱其為a需求吧，是在原來的基礎上根據使用者要求變更的功能點，然後公司上下開了個小會討論如何實現，最後決定讓小楊進行編碼，我進行測試case的設計和**測試，一切安排就緒。**的編寫過程中確實也碰到了困難，但是兩個人一起討論，最後加班趕出來，也經過確認沒問題了。下班時，已是晚上九點。
第二天便進行**的走查，前後花了半個小時，對新做的**進行了討論審查，並未對以前版本的**進行檢查（因為大家一致認為，以前的**是ok的，並且這次變更的東西跟以前的**不會有衝突）。完了我開始做**測試，結果問題b產生了。
產生的問題是，以前的**裡有錯誤的邏輯直接拿過來復用，因為時間關係，小楊並沒有逐行**進行分析，而在**走查的過程，大家也過於相信就版本的**，認為其不存在邏輯問題。於是，問題就出現了。
究其原因，這次bug發生的最主要原因是，大家都把注意力集中在需要變更的需求上，而忽略了其對其他模組的影響，或者上層呼叫的介面是否一致問題，過於相信前人留下的**，審查過程也是被**走查主導人帶入誤區，盲目地認為只需要審查變更到的模組。
沒有調查就沒有發言權，很多時候，人的認識能力存在很多缺口很多誤區，在專案deadline之前，專案組成員可能因為高度的精神緊張和壓力而忽略了其他事情，轉而專注到更為重要的事情上去，不是說其他的事情不重要，而是優先順序2的事項很有可能就對優先順序1產生影響。過於自信，往往是出現bug的重要原因。
記一次調bug記錄 15 4 17
bug描述是這樣的,為了描述的方便,我先定義幾個變數 a 客戶端a b 客戶端b a send 傳送的a a recv 接收到的a 這裡的a可能和傳送的不一樣 有2個客戶端a和b,他們自己應該是可以傳送和接收的.但是接收端接收到了,但是無法開啟.a傳送a send給b,b收到了a recv,但是無法...
記一次bug修復過程
我的建議，究竟有誰會看，以我的位置，到底能推動到哪一層 可行性，可能性 問題 使用者的資料丟失了。以為是修改操作 有bug，但檢視了後端介面和前端校驗，都沒有發現問題。但是input資料沒有日誌 日誌級別是debug 不能自證清白。並且一些沒有辦法輕易證明的猜測也有 是不是併發問題，乙個insert...
記錄一次可能的坑爹bug除錯記錄
data publish time date y m d h i s 因為h 的範圍是0 12，之前寫 是在上午，所以不會發現問題 最後做了這樣的實驗,才發現了最終問題 正確寫法 data publish time date y m dh i s date default timezone set ...