昨天主管召集開會，講了一些事情，摘錄其中我認為有價值的，在此記錄一下：
1、bug修改之後，在轉測試回歸之前，開發內部要自行驗證。這個是傳統了，不過主管建議不要只依賴現有的dts系統（公司的乙個bug管理系統），因為其內建的流程，只支援乙個人審核問題，這樣往往不夠準確，有可能回歸不通過。所以主管建議自行用excel進行跟蹤，關鍵是進行兩輪審核，這樣可以降低回歸不通過的概率。
這裡有2點值得總結，首先是2輪審核的流程，其次是不依賴現有的bug管理系統。這個是有道理的，如果別的公司沒有bug管理系統，bug是否不跟蹤了呢？所以任何系統只是工具，起到輔助的作用，關鍵還是對bug進行跟蹤管理的意識
2、bug修改之後，在dts中填問題單處理過程，要注意規範。
這點我有些不是很認可，因為我還沒有認識到規範填寫問題單的價值。不過從另外乙個角度想，對於已經比較成熟的團隊，可能可以不依賴這種管理手段。但是鑑於目前我們開發團隊還比較年輕，這些管理手段是必要的。姑且不論規範填寫問題單，給bug管理本身可以帶來多大價值，至少通過要求員工規範填寫問題單，可以培養員工的執行力，這對促進團隊的成熟是很有幫助的。
團隊越成熟，配合越默契，管理成本就越小，所需的管理手段就越少。反之，當團隊還不成熟，員工普遍能力較弱的時候，這些管理手段也就是必要的
3、關於轉測試
主管提到了幾個文件，包括「版本說明書」、「安裝/公升級指導書」、「測試建議」、「冒煙測試結果」、「遺留問題說明」
這些文件，涉及到轉測試流程的管理，以後有空單獨寫一篇帖子來說明
4、版本發布規範
主管提到一點，未經測試的版本，不允許發出。這點很關鍵，值得單獨記下來。
未經測試的版本不能發布，這個原則是很簡單的，但是可以引申
4.1、版本a已經轉測試了，測試過程中發現了乙個問題，這個時候能不能用***.class替換掉呢？
肯定不行，所謂的版本，應該是乙個完整的包。如果直接替換檔案，那麼已經不能保證包的完整性，這個替換後的版本，就等於是乙個新的未經測試的版本。在替換之前的測試，嚴格來說等於是無效的。要發出去，就要重新測一遍。
正確的做法，是把這個問題作為乙個遺留問題，評估其影響，寫在遺留問題列表中。版本還是正常發出去，這個問題可以在之後修改，合入下乙個版本進行測試。如果問題很嚴重，是版本的嚴重缺陷，不能外發，那麼可以增加一輪測試，回歸之後再發布
4.2、版本a轉測試，測試結束之後，測試可以找開發要乙個新的包，發布出去嗎？
不可以，因為這個新的包，不能保證和測試的版本完全一致，那麼這個新的包，也就是乙個未經測試的版本
正確的做法，應該是把測試的版本發出去。即：轉測試時是什麼版本，測試結束之後就發什麼版本
4.3、現場發現了幾個問題，開發提供的補丁只有幾個檔案而已，可以不打標籤，直接發出去嗎？
不可以，所謂的版本，除了「完整性」之外，還需要乙個「可標識性」，就像資料的主鍵一樣，能夠唯一標識乙個版本。沒有「可標識性」，就稱不上是乙個版本。乙個版本只要發布了，就存在需要定位問題、回退的可能。如果沒有打標籤，當需要定位問題，或者日後需要回退的時候，就做不到了
正確的做法，是只要發了版本，就一定要在**庫上打上標籤。可以是用版本號打標籤，比如b010，spc001；也可以用時間打標籤，比如tag_20120719
打了標籤之後，在任何時候，無論是要搭建現場的映象環境，或者回滾，或者比較兩個版本的差異製作公升級包，都可以做到了
主管一席話引發的思考
昨天主管召集開會，講了一些事情，摘錄其中我認為有價值的，在此記錄一下 1 bug修改之後，在轉測試回歸之前，開發內部要自行驗證。這個是傳統了，不過主管建議不要只依賴現有的dts系統 公司的乙個bug管理系統 因為其內建的流程，只支援乙個人審核問題，這樣往往不夠準確，有可能回歸不通過。所以主管建議自行...
《倚天》中張三丰一席話引發的思考
2019第一篇文章！之前看 倚天 有一段是張翠山帶著殷素素來到武當山拜見張三丰。因為殷素素是魔教中人，所以江湖上的豪傑肯定會以為武當派勾結魔教。但是一代宗師張三丰的一席話令我佩服得五體投地，現摘錄原文如下 張三丰仍捋須一笑，說道 那有什麼干係？只要媳婦兒人品不錯，也就是了，便算她人品不好，到得咱們山...
聽君一席話，勝讀十年書
1 乙個人，如果你不逼自己一把，你根本不知道自己有多優秀。2 賺錢是一種能力，花錢是一種水平，能力可以練，水平是輕易練不出來的。3 年輕人不可以太狂。4 乙個人的知識，通過學習可以得到 乙個人的成長，必須通過磨練。5 這個世界上好書很多，可以改變命運的書很少。6 這個世界上朋友很多，可以用一生託付的...