最近發現自己犯的錯誤有點嚴重，實在掛不住臉，希望這裡不要記太多。
1. 你以為
（1）之前有做乙個需求，就是要保持三個模組的某個日期一致，我當時簡單找ba問了下，就去做了。做的時候發現，三個模組有兩個模組的日期始終保持一致，所以下意識以為只需要改另外乙個模組的日期就好了。當然，測試也沒測出什麼問題，上線了幾個月，使用者說你這個模組的日期不對呀，多了一天，然後大家一看，確實，其實應該改另外兩個模組的日期。然後我就背鍋了，更重要的是，這個模組的日期被很多模組和功能依賴，其中還有一些計算功能，除了改這裡以外，還好batch update已存在的資料。天呀，這簡直是一場災難！所以，你以為，請不要你以為了。一定一定要步步小心，步步想，搞的明明白白，搞清楚其中的關係，否則後果承擔不了，gg。
（2）最近用同事發現乙個很嚴重的bug，發現產生的資料會double甚至更多倍，然後另外同事去看**，發現我當初寫的**有嚴重問題，影響了五個模組，臉瞬間就掛不住了，幸好使用者還沒用這塊的功能，不然鐵定gg。總結下來，是自己當初沒注意業務中的層級關係，導致用了第二層資料調取了第一層資料，然後再通過第一層資料調取了第二層資料，就導致第二層如果資料有n條的話，產生的資料就是n*n，真的要被自己嚇死。需求沒搞清楚，關係沒搞清楚，真的不要直接下手寫**呀，會死的。
（3）merge code，自以為可以holder的住，處理了其他人寫的**，然後之後gg，在生產環境發現了比較明顯的介面問題，緊急改了重新上，老臉掛不住呀。merge code，有衝突一定要一起看，即使沒有，也要再看一兩遍，另外merge後的**在code review時也要過下，這樣才能確保merge沒有問題，尤其是從另外乙個分支merge**時。
2. 請謹慎對待db某些資料的刪除操作
（1）之前有做乙個需求，要增加4個字段來替代原來的乙個字段，因為那乙個欄位的資訊太多而且設計不合理，需要把其中的資訊拆成4份。然後我首先就刪掉了這個不合理的字段，然後建立了4個新的字段，之後就傻眼了，之前的資料找不到了，是需要把原來資料恢復到新字段裡的。幸好這只是測試場，幸好這些資料也不是沒辦法恢復，只是這樣會需要很長時間。我嘗試恢復並且成功，用了一整天的時間，真的費時費力不討好。差點就犯了大錯！所以，請謹慎對待db某些資料的刪除操作，寧可不刪，等過一點冷靜下來再謹慎處理。
（2）之前有做乙個需求，要更改某個欄位的型別，我就直接drop掉這個字段，然後建立乙個同名的新字段，後面被同事看到了，結果可想而知，真的無地自容，這種處理方法的結果就是比災難還嚴重，原來的資料就真的沒啦，哇哇哇，寶寶想哭！
3. 請謹慎對待db某些資料的更新操作
（1）上周五臨下班前，接到乙個support，要更新db中的三條record，然後自己根據使用者給的資訊編寫了update sql，然後執行，以為就完事了。結果第二天效果，發現沒效果，然後看了下sql，突然有一種直覺，寫錯了，然後仔細一查，發現我少寫了where條件，導致更新了上千條資料，完蛋了。週末兩天使勁恢復資料，那個心累，那個心驚膽戰。所以，切記要先select再update！！！
4. 對資料migration請再重視、認真、謹慎些
參與的乙個專案之前做了資料的migration，而且是第二次做這件事情，但是做完以後一團糟，我同事的**被客戶打爆了，持續大約一周吧。針對使用者和後面我們自己發現的問題，分為容易發現型和較難發現型，在查問題過程中發現有幾點做的很不到位：
（1） 首先針對較容易發現型。由於我們是週末做的migration，做完以後就沒測試各個模組了，周一使用者就開始用了。乙個是我們的自動化測試指令碼那段時間有些問題，跑不起來。另外乙個是我們沒有做足夠的人工qa test，因為我們這個是比較重大的事情，所以週末加班來驗證功能是完全有必要的，尤其是缺乏自動化測試的情況下。哪怕只是走了一些主要流程也是能夠提前發現問題並且解決的。當時有好幾個問題是因為資料缺失，原來一些必要的資料或者有關聯關係的資料丟失，或者某些module下的小業務的資料沒migration過來導致的，這些完全是可以在介面上看得到的，完全是可以提前發現的。
（2） 針對較難發現型。這個可以通過qa test提前發現一些，或者在之前就準備一些監控作用的sql指令碼，定義一些資料規則，來掃瞄整個資料庫中的表，看資料是否有缺失或者其他異常情況，準備的越詳細，就越容易提前發現更多的問題，把影響降到最小，不過做這個事情要考慮成本，可以先粗粒度，後期不斷迭代新增業務資料規則。
（3） 針對所有。提前現在qa或者uat環境先嘗試migration，如果公司允許的話，然後把測試做足，之後再在生產環境上做migration。
（4）針對所有。針對migration的**做code review或者pair去開發，提高**質量，最好是懂業務的開發一起去做。
不然，會導致對使用者造成很多困擾和資料出錯，進而導致整個業務混亂，而且有些雷沒發現，之後**的時候可能就是致命的了。
5. 測試
5.1 專案migration（遷移）之前的測試
由於測試不夠，導致遷移後使用者指出主要功能的ui出現了點問題，雖不影響功能但是確實看著難受，對使用者有影響，如果使用者量比較大，那麼就會被瘋狂call，而且會降低使用者信任度等。
出現問題我記了下來，link如下：
總結了下，出現這個問題，主要有以下幾點：
（1）在測試場自己沒仔細測，對比測，不重視ui測試。另外，使用者經常使用的是ie，自己測試的時候用的是chrome，沒注意使用者使用習慣；
（2）感覺沒有功能的增加，只是遷移，不需要使用者參與，其實為了以防萬一，或者其實是可以讓使用者去測試的，因為平台和環境問題都可能導致某些變化，多找一些人測，找使用者來測，基本上是可以提前發現的。
（3）而且這次只是出現ui問題，但是如果上線後出現某些重要的case走不通，那就真的坑了，所以認真測試以及找使用者測試真的有必要。哪怕只是migration。
6. 請找到root cause
6.1 應用無法連線新版本db
這個應用的技術架構很舊，是通過powerbuilder去呼叫oracle client的配置資訊進而連線oracle db的。我們公升級了db版本，我這邊嘗試了新版本oracle client去連線，但應用始終無法正常連線到oracle db，我以為是軟體技術太老需要公升級，就找第三方去公升級，隔了乙個月，另外乙個同事發現是我使用的oracle client是64位的，其實應該是32位的，因為之前就是32位的。而我們後面又試了32位的client就可以連線到新db，然後我就被批了，因為沒找到root cause，造成不必要的誤會。我想當時如果拉同事一起，可能這個問題就很快解決了，當時我自己已經認為是軟體本身的問題了，急著下了解決，我想以後盡量找到root cause。
6.2 call不通第三方api
最近發現call第三方api全都失敗了，我當時沒仔細看log，而且週末第三方在維護，我這邊剎那間就認為是第三方的問題，所以就急急忙忙找第三方，讓他們去找問題。結果第二天其他同事一看，這個根本就不是第三方的問題，因為我們api就沒call出去，是在內部就失敗了，我後面仔細看了下log，還真是，就又造成了誤會。後面查到是因為公司安全軟體的公升級導致這個api被block了，放開就好了。這裡也犯了沒仔細找root cause的錯誤，自己真的不能著急了，要先仔細的準確的找到root cause再下結論，否則真的會造成誤會，真的沒必要而且給別人的印象也比較差。
專案管理13禁忌
正所謂新年新氣象，為了改變以往對新的一年列舉待辦事件清單的模式，加快專案的進度，我認為把下一年不應該做的事情簡短列出來會很有價值。列印出這張清單，給它標上記號，並且放在隨手可拿的地方。清單的格式應該一目了然，這樣您在專案的所有階段都能容易地察看，確保自己不會犯下不良習慣。1 不要喪失激情 人們在啟動...
SQL 如何實現一條sql語句插入1000行資料
用 sql的可程式設計性,作為測試資料用是吧 declare i int 申明乙個整形變數i set i 1 設定初始值為1 while i 1000 用 while 迴圈給定乙個迴圈結束條件小於1000 begin insert into tb user values user no cast i...
騰訊筆試題 1000億條記錄中查詢內容
題目 有 1000 億條記錄，每條記錄由 url ip 時間 組成，設計乙個系統能夠快速查詢以下內容 1 給定url和時間段 精確到分鐘 統計url的訪問次數 2 給定ip和時間段 精確到分鐘 統計ip的訪問次數 請描述你的解決方案！解答 首先，1000億條記錄全部放到記憶體肯定不夠，那就是分成小檔...