之前若干
不要完全依賴web端/移動端，期待他們傳正確的值；
第三方介面呼叫是否捕獲異常取決於業務有沒有這個必要；
不傳有預設值或者是空值，不一定要要求前端一定傳；
介面考慮版本相容處理，實在區別很大，可以公升版本。
----------------------------
2023年8月1日
新增字段，需要考慮關聯影響，比如說乙個模組加了乙個新的字段，那麼涉及的功能，比如複製，是否需要把新字段考慮進去。
----------------------------
2023年8月2日
返回給前端的值不是最需要的值。比如訂單記錄中返回給前端當前商品**，而不是下單時的**，雖然移動端可以從資料中計算出來，
但是這時候的**就應該是購買時**，當前**顯示沒太大意義；
資料需要考慮到是否做一定的隔離，包括專案的，或者是使用者的，不然很容易造成不該看到的資料被看到。
----------------------------
2023年8月3日
寫了拋異常的語句，要看下對所以引用這個函式的地方有沒有影響。支援擴充套件是好的，但是擴充套件的影響也要多注意。
使用git，從release到master，需要同時合併到dev
----------------------------
2023年8月4日
看起來完全一樣的請求，實際上可能還是有細微區別的，比如今天碰到的乙個header有指定content-type，乙個沒有。結果乙個成功，乙個失敗。
----------------------------
2023年8月5日
設計方案時，盡量考慮簡單，可靠，可控。
----------------------------
2023年8月7日
子查詢的效能，大部分情況下不如連線。
----------------------------
2023年8月9日
redis值的設立如果是物件最好包含鍵中的關鍵資訊，便於如果日後需要批量取的情形。
當順順利利的開發完成後，發現有需求變更，這時候要改**，就要注意影響範圍了，
最好能通過腦圖梳理下，直接埋頭做的後果，就是可能又出bug啦。。。
----------------------------
2023年8月10日
相比其他方式，單元測試是比較好的提公升質量的方式。
----------------------------
2023年8月11日
差點坑自己。發預生產用功能分支，這步本身就是不對的，還好有比較下**，重新合了分支，正常流程就應該用master來發布預生產和生產！
----------------------------
2023年8月14日
之前為了提高效能，一段程式直接改為從redis中批量獲取鍵。但是忽視了有些鍵還沒有快取到到redis的情形，這種情況需要再請求一次。因為之前依賴spring的cache，認為肯定都有cache，其實不一定，可能編輯的時候，就會先清除cache的。所以思維還不夠嚴謹，考慮要更全面一點才行。
----------------------------
2023年8月15日
執行緒內部變數計算是不會有執行緒問題，當多個執行緒有一起執行資料庫時，就要警惕可能出現死鎖的情況。
----------------------------
2023年8月16日
對於需要對生產資料做大資料量處理的版本，需要把計畫提前安排好，不然就會很被動，可能導致專案發布延期！
----------------------------
2023年8月17日
定位bug的思路都是差不多的：相似的直接根據歷史經驗判斷；其他情況：1、尋找和梳理線索；2、根據線索順藤摸瓜找到大概位置；3、適當假設；4、驗證假設。重複3~4直到問題原因查明。
----------------------------
2023年8月22日
編寫v2版本的介面時，要注意如果v1版本已經實現的功能，如果需要相容，也要補充進去。
----------------------------
2023年8月25日
從二輪到預生產需要先合到master再發布，為的是後面發布可以省時間，一點點時間累積起來還是挺可觀的。
測試驅動開發這件事情，其實當你實際去做的時候，才會發現對提公升軟體質量的作用。比如開發時就要考慮測試的點，用測試角度看待功能。比如測試支付，支付這件事情上基本在qa那裡是不會失敗的，那麼要測試支付失敗的場景，該怎麼辦，就需要開發配合調整程式，加入開關等。
----------------------------
2023年8月29日
對於剩餘天數這種資料不要直接返回到期時間給前端計算，因為前端依賴的本地時間不一定是正確的。
----------------------------
2023年9月18日
字不如表，表不如圖。
----------------------------
2023年10月14日
技術方案一定是基於業務基礎，服務於業務，並且衡量過投入產出比的。
細節是魔鬼。
優化是無止境的。
----------------------------
2023年11月1日
如果將原來扁平的sql拆成多個連線的方式，要注意資料集是否一致
----------------------------
2023年1月17日
**別人介面的時候，要注意看下有什麼限制，比如發簡訊這個....被限制1分鐘內1個ip只能發一條
2023年3月6日
預生產庫同生產庫時，執行生產指令碼的時候，需要嚴格檢查，否則可能出現破壞性變更，造成生產故障。
2023年3月20日
對於有一定時效性的資料，可以儲存到redis中，設定有效期，自動刪除
2023年4月26日
今天定時任務從凌晨開始跑，但是到中午還沒有結束。任務是對錶做查詢，再做統計。由於被統計的表隨著使用者高峰期資料量變大，資料已達千萬，有了效能問題。由於查詢當時連的是主庫，於是線上慢查詢變多，緊急停止了任務。這事告訴我，1：大數量的任務不要直連主庫查詢，而是要走從庫；2、千萬級的資料統計，走mysql是慢的，應該利用現在各種大資料平台來計算。
2023年5月15日
今天收到bug，關於乙個欄位為空，導致查詢不到結果。原來的時候對jpa儲存機制沒反應過來，以為如果資料庫設定了預設值，那麼插入庫的時候會沒傳值或者null應該會用預設值。但是這個資料庫沒設必填被插入了null值，說明就是按null值進行儲存的。以後初始字段值，需要注意到字段的型別初始，在儲存的時候進行攔截。
2023年7月5日
特殊字元&，導致url請求中接收方獲取資料不完整。提醒在遇到網路請求時，必須要注意轉碼問題。
2023年7月26日
針對已有方法或類的修改，一定要考慮他之前所有的引用，否則改了這邊影響那邊，會給自己挖坑。
不要讓showcase形同虛設，要發揮起作用來，沒有show過，結果果然出錯了。
2023年9月6日
在設計api的時候，考慮變化，是否有封裝變化，是否具備較好的可擴充套件性、可維護性。
2023年11月1日
呼叫第三方介面需要catch處理。不然針對對方介面可能出現的502，504等就無法記錄，或者直接導致業務異常。
盡可能標準化的做一件事情，你不知道哪一天標準就起了作用，減輕了擴充套件改造的壓力（儲存json與tostring()的選擇）
bug修復記錄
telnet ping netaddr traceroute netaddr 這是乙個linux下的命令可以通過vmmap觀察程式執行時所需要的依賴庫協議裡面涉及到陣列的，一定要判斷最大值 basegamelibdata stlibbasedata gamelib基本資料 uint32 t dwui...
日常 bug記錄
1 伺服器可以ping通，但無法登入 通過內網連線 先登入伺服器a，然後通過內網ip連線伺服器b。ssh root 伺服器b內網ip新知識get 2 torch tensorboard生成的url打不開。使用命令 logs為自定義的儲存檔案的資料夾 tensorboard logdir logs h...
重要bug記錄
2.使用者未登入賬號進入直播間，在公屏中選擇使用者頭像長按進行 操作，並傳送訊息。問題現象 遊客身份使用者出現了可 使用者並發言的問題，發出去後顯示使用者頭像和null 原因分析 邏輯處理未判斷使用者為遊客時遮蔽 操作 原因分析 因歌友a的異常離開房間，客戶端未能正常呼叫介面上報狀態。伺服器無法正確...