2015-7-1 記而隨，隨而記

 

今天仍是在改BUG，使用的是BUG管理系統是禪道，此次在修改BUG的時候，養成了一個好習慣就是把每一個BUG所對應的修改的文件與涉及的模塊關聯了起來。解決的問題是

1. 解決好的BUG又被激活了，不知道修改的哪一個文件，哪一個模塊，不能快速定位，這樣定位快多了。
2. 打包時，能夠統計都有哪些模塊更新了

 

我想BUG改完以後，還須要對這一期的BUG進行下總結、統計。有什麼好處呢？首先，能夠根據功能性、樣式區分。

根據嚴重性與通常性等等幾個方面來區分，來看下分析下BUG的分佈狀況，統計BUG所涉及到的知識點。對發生的BUG進行總體性的分析，來指導從此的編碼工做，提早爲本身打好預防針。同時，發現本身或公司在知識地圖上的

不足，進而找到彌補的方向與目標，本身能力的提高點也就找到了。

（本身想了想，其實這能夠歸入到公司的工做流程，畢竟，這是有好處的）

 

說到知識地圖，咱們每一個人都應該有本身的知識地圖，而公司獲取也應該有一份知識地圖，這是你們共有的知識地圖，你們共同去完善，共同去交流、共同去成長。（關於知識地圖這方面的東西，我是從《如何高效學習》這本書學到的，這是本很是不錯的書，我想之後有了孩子，我應該教他這個的）

 

而後，就我修改BUG的狀況，來談談一些想法，首先，有這樣一個前提，就是修改的大部分模塊我是不熟悉的，基本沒有接觸過，業務邏輯是不知道的。每修改一個BUG，定位其緣由我都須要從頭至尾，甚至每一個細節都要查看，對，每一個細節都要過一遍，按道理說，這是沒有必要的，緣由就出在全部的業務邏輯放在一個大大的函數裏面，我不得不一點點查看，沒有業務邏輯層的函數致使理解起來就很是花時間，同時BUG定位，也很是的困難。因此，一直要強調職責明確，職責明確，每一個函數就應該幹一件事。而系統中充斥着這種大函數，也只有那些對這些大函數了如指掌的人才能快速定位BUG，找到緣由所在，然而，人得記憶是有限的，隨着時間的流逝，咱們對這些大函數也會漸漸淡忘，也會愈來愈陌生，當有一天咱們再看見他們的時候，若是仍是摻雜許多業務的話，咱們就真不認識他們了。因此說，請寫小函數，請寫職責明確的函數，程序員何須爲難程序員。（有關這些方面的知識我是從《代碼整潔之道》《重構 改善既有代碼的設計》中學到的）

 

再說說另外一個問題，在修改BUG的過程當中，是否有着一個把BUG改好就好了的想法，我想，大部分是這樣的，我也這樣，畢竟誰也不想由於本身的其餘的改動而引入其餘的BUG。然而，在改BUG的過程當中，我想有一件事仍是有必要作的，那就是重構，若是發現了壞味道（此名詞見《重構 改善既有代碼的設計》）咱們就應該將其去除掉，若是你想之後輕鬆維護他的話。任其爛代碼的存在，咱們增長了哪些成本：時間成本，咱們須要耗時間去理清業務邏輯，工期加長。維護成本，爛代碼很是容易引入BUG。何況，修改BUG時，順便重構，是重構的最佳時間，由於畢竟咱們還有測試，在確認BUG的過程當中也就同時保證了咱們重構的正確性。

 

今天重構了一個登陸錯誤時，顯示錯誤消息的代碼，代碼很長，而且在修改密碼頁面還有完完相同的一套代碼。也正好修改一個錯誤消息提示不合理的BUG，果斷就重構了，把這段抽到一個地方，兩個地方使用一套代碼，瞬間就簡單許多了。關於代碼，改天再貼吧，想一想也是頗有意思的。