程序員的踩坑經驗總結（二）：如何用巧力解決問題

昨天寫完如何把Bug的偶現變必現，後面想了想，好像沒過癮！再細細考慮了這些年的踩坑經歷，有幾個方法很是值得一提。

 

四兩撥千斤

我印象中，用這種方法解決過好幾個問題。這個會頗有成就感，曾經在微信上表達過喜悅之情（見後面截圖）。總的說來，不要從正面來解決衝突，從側面加小量代碼，改變正規思路，就能夠解決一個大問題。

這裏能夠舉一個較近的例子。年初，回放的視頻動態變化頻繁的時候，在啓動的前2-3秒會感受明顯的慢，過了這個時間點就正常了。這種慢就至關於慢放的感受。在視頻動態不明顯，即比較靜態的時候，是感受不到的。咱們行業大部分是後面這種視頻，測試模擬視頻源也換成了菜市場門口的了：）

總之，這能夠說是性能優化的問題或者說平滑過渡的問題。通常性能優化的問題，能夠日後一點，對一個軟件系統來講，穩定性最重要！如今有時間了，年初疫情之時，正好能夠思考下。

怎麼改？從回放機制來講，並無大問題，由於後面立刻能達到正常速度。真正緣由是由於前幾秒秒沒有參照物。具體是這樣的，回放的速度雖然有個默認值，可是能夠根據計算前面幾秒的速度是偏快仍是偏慢來進行微調！而剛啓動的時候只能根據默認值來進行控制速度了。機制沒問題吧，考慮仍是比較充分的吧。可是如今問題也要解決，既然機制沒問題，也就不能動。可是這個開始幾秒的速度也是機制的一部分。這裏就產生了矛盾，開始有衝突了，左右不是！難道就由於這1-3秒改下機制，退一步，改下前幾秒的機制呀！很差改，懂視頻的知道，1秒有25幀呢，2秒有50幀，改前面這50次？明顯不合理。並且計算機處理的速度更快，納秒級處理一次數據了。邊看代碼邊思考，後面想到了之前作過一個項目音頻的淡入淡出，人爲的讓開始和最後幾秒漸變的方法。那就反過來了，從快漸變到正常速度！方法有了，在哪一個位置改？之前的代碼已是一個總體。又回到了前面的問題，改機制不可取，幾秒鐘幾十幀好屢次循環呢！看代碼，速度有個時間相關參數，又有方法了：加函數傳參數就能夠了！後面寫代碼，十來行！固然，既然要作到平滑，就須要通過大量測試，來作微調！

最後，還能夠提供另外一種思路，客戶端來修改。例如客戶端能夠推遲半秒鐘解碼播放，這個問題也許就更容易了。

  

圍點打援

在我印象中，用這種方法解決過一兩個問題。也是不要從正面來解決衝突。用這個方法，每每是緣由比較複雜，不易搞定。正面改動又太大。能夠考慮從外面多處着手，多處的小改動，最終達到解決問題的方法。我記得當時的感覺是，跟建房子同樣，須要外面的支架支撐，即從多處着力。因此這種方法能夠解決問題，可是算不上一種上乘的方法。但最終仍是能解決問題，主要是不須要改動原有的機制。

問題過去時間有點久遠，之後應該有機會碰到，再做補充！

 

以上兩種方法，看似不一樣甚至有點對立，實際又是一致的：

1.都是少改動，儘可能減小修改代碼的量即不動原有機制而能達到一樣的效果。

2.在對相關原理以及對做者的原意要有充分了解的基礎上。

3.具體問題具體分析，突破思惟定勢。

4.用巧勁，而不是用蠻力。

固然，若是要能用得上巧力，前提是設計的架構沒有大問題。保證穩定性是基本的，解耦也是基本要求，最好還能考慮可擴展性和可維護性。例如第一個案例加個函數傳個參數沒有多大影響。

 

 

最後，咱們再來看看曾經的（當時的）喜悅心情，有圖有真相：）

　　　　 

　　　　 

我想說，應該還有更早的Bug，不搜索了：）。說實話應該上Bugfree搜，好了，不作評價，不展開了哈。

但是我又忍不住多說一句，Bug也是分質量的，即Bug也分好壞的。上面的Bug固然是好的，那什麼Bug是很差的。有的Bug就是食之無味、丟之惋惜的那種吧，讓你啼笑皆非的是還把Bug級別定的很高。讓我不得不又提及HW的經歷，可能大家都煩了，我本身都煩，好漢不提當年勇，不是嗎？當時做爲測試，提Bug是有很是專業的培訓的。有些約束，記得最清楚的兩條。

1.提Bug必定要找開發人員定位，由於當時環境及其重要，同時要和開發人員確認是否是問題，只有開發人員默許了，才能提Bug。

2.Bug的級別仍是掌握在測試人員手中，可是對Bug如何劃分級別有專題培訓。並且Bug流程須要通過主管審覈，必定是流程上主管經過了，才能走到開發人員那裏。若是級別總是把握錯了，那你就遭殃了，談話去吧。

固然這和HW的績效考覈也有關係，一個高級別的Bug，對測試人員來講是很是有利的，而對開發人員來講倒是至關不利的！

 

 

後續對踩坑經歷還有專題介紹：內存泄露和死鎖，敬請期待。