來公司也一年了，專案從早期不斷迭代，到最近臨近交付客戶。有很多值得反思和記憶的故事，我明顯感受到了自己的成長，也明白了產品、研發的重要。
昨晚是封版本的最後一晚，一直加班到了凌晨2點。從晚上開會到不斷修復緊急bug，每個小夥伴們都繃緊了神經，全力以赴地驗證所有的case。最終還是如期交付，但值得思考的問題不少。如果我不寫下這些，我怕忙碌會把這些經驗湮沒。
1. 需求是產品之源，必須深刻理解。
如果有不清楚的地方，在開發之初就應該提出疑問，透過一次一次產品研討，弄清楚所有邏輯。
打個比方，一款銀行理財產品，使用者下單購買該產品後，進行作廢訂單，到底如何處理庫存和銷量等等。這些看起來簡單的問題，對不同的使用者可能選擇不同。有的銀行認為銷量是需要計算真正成交的訂單數，如果作廢，則需要從總銷量裡面去掉被作廢的。有的銀行則認為只要成交過，那麼就持續累積。
對於研發工程師，對於這些可以有自己的見解，但不能直接替客戶做選擇。傾聽客戶的真正的心聲，才能實現真正有價值且符合需求的功能和產品。
2. 全域性檢查，深入所有邏輯分支
不得不相信一句話：任何可能出現的問題的地方，都有可能出現問題。所以每次修復bug的時候，一定要從全域性去思考，是否有關聯性的邏輯已經檢查了，確保算無遺策。
3. 學會跳出常規思路去用產品
在使用產品進行測試的時候，我們不能只想著怎麼正常用這個產品，而是要儘量從各種情況去玩整個系統。擺脫一種產品標準使用方式的思維定勢，像折騰手辦一樣，把它扭成一個意想不到的形狀和方向，然後看它還能否正常還原。如果只是順著期待的結果去準備資料，去測試常規的case，我們很難真正瞭解一個產品的潛在問題。就像如果一直不敢下水，雖然不會被淹死，但是很難真正學會擁有。
4. debug也是需要準備的
之前老闆就提醒過幾次，準備好一些query和一些排查工具，方便在最終測試裡面遇到問題的時候能快速排查資料。我對我們開發的系統過於自信了，並沒有專門準備query。在連續發現一些異常資料的時候，臨時再去寫sql，有些慌忙。提前準備能讓自己更從容，也能更快定位問題，減少不必要的debug時間。
現在已經走出了一百步，也要走向真正的世界，希望輕舟一過，山也向後，我更向前。