程式碼BUG之曲線救國

清明節放假前工作最後一天，協助同事解決了一個BUG，這個BUG對於所屬的程式而言，可以說不是痛不癢，完全不影響使用，只是看起來有點變扭而已。然而， 對我而言， 解決這個問題的思路卻是比較有代表性的，頗有一種曲線救國的味道。

 

事情大概是這個樣子的。有需求部門反應，我們部門負責的某個專案的頁面上資料顯示有問題。有10條資料，每頁顯示4條，那麼正常情況下第1頁應該顯示4條，第2頁4條，第3頁2條。因為某一處程式碼抽風，現在資料被顯示成了第1頁4條，第2頁3條，第3頁3條。儘管不是什麼大問題，但是我們寫程式碼做產品向來秉承著精益求精的作風，只要是個問題， 就算再小，也要修正。然後， 一幫程式設計師手忙腳亂的想抓住這個BUG消滅之。為什麼是一幫程式設計師？修個BUG用的著這麼大動干戈嗎？大家有所不知， 因為這個BUG的當事人是一位萌妹子，大家幫忙出主意修BUG是不假，但是去揩個油那也是真的。一陣忙活之後， 問題出在哪裡是找到了，卻沒法子下手改。因為這個專案依賴一個第三方分頁顯示外掛，程式本身的邏輯沒有問題，問題出在這個外掛裡面。去修改這個第三方外掛的BUG顯然不太現實，靠譜的解決方法就是把這個外掛給換了，但是專案的程式碼跟互動和這個外掛結合的非常緊密， 哪能說換就換，再說當時已經是晚上七點了，這一搞非得到凌晨不可，因此，大家都像洩了氣的皮球，無可奈何，這都放假了還出這檔子事，明天還要去給祖宗上墳呢，加班和對先人不敬，到底應該選哪個呢？心塞塞呀！

 

本來這種閒事我是不太喜歡管的，但是因為這個妹子明天必需要回家，車票買好了， 所以要把這個問題解決就必須在今天晚上， 讓一個妹子加班到凌晨，我有些於心不忍， 一個如花似玉的小姑娘， 半夜一個人回家， 要是碰到壞人， 場面不敢想象。 於是我也上前去湊熱鬧了，說不定能幫上忙呢。

 

瞭解了問題來龍去脈後，發現這個問題在自己的技術認知範圍內的確沒有靠譜的解決方案，除非修復外掛BUG或將外掛替換，但是這兩種方案都不是短時間內可以完成的。我閉上眼睛思考，既然是個BUG ，那肯定不是必現的，如果不去觸發這個BUG ，那也算是把問題解決了。我腦子中靈光一閃，似乎抓到了一絲線索。我開始調式程式，總共10條資料

 

設為每頁顯示4條，顯示結果為4條3條3條

 

設為每頁顯示3條，顯示結果為3條3條2條2條

 

設為每頁顯示2條，顯示結果為2條2條2條2條2條，一切正常， 沒有觸發BUG

 

我找到了規律，不觸發BUG的情況是資料總條數必須能被每一頁顯示條數整除，這也就意味著，每頁4條不能變，那隻要把資料總條數變為12就可以。為驗證我猜想， 我在原有的基礎上加了2條資料， 測試執行， 原來的BUG消失了， 分頁顯示變的正常了。找到解決方案，接下來的事情就簡單了， 只要讓資料總數保持為4的倍數，再加上一些收尾的工作，問題完美解決， 整個過程花了不到10分鐘的時間。

 

外掛的BUG還在那裡，根本沒有被修復，但是使用者反饋的問題卻修好了，能用的舒服，程式設計師也不用加班了，兩全其美。事後我仔細思考，我沒應用什麼別人不會的高大上技術，只是轉變了一下思路，就輕鬆巧妙的將問題解決了，很有一種四兩撥千斤的感覺。那是不是也可以把這種解決問題的思路推廣到其它方面呢？

 

回憶過去，我以前也經常以這種思路在解決問題，只是過程與成果並沒有顯得非常的尖銳和突出。

 

之前，我的一個網站被惡意攻擊者注入垃圾資訊，整個網站滿屏不堪入目的內容。我迫切需要解決這個問題，但網站的原始碼在家中電腦上，我沒有辦法通過修改程式漏洞解決問題。現在手頭唯一擁有的是資料庫操作許可權，但是把資料刪了，惡意程式立馬又注入新的，治標不治本啊。正愁眉不展間， 腦中靈光一閃， 方案出來了， 我可以在那個被注入表上加一個before觸發器， 觸發器的程式檢測被寫入的記錄， 假如是來自惡意攻擊的資料，就執行回滾操作，不讓資料寫入表中。花了十分鐘寫了十幾行SQL，問題解決。程式的BUG還在那裡，注入者的機器人程式還在不停的攻擊，但是管他呢，我的最終目的達到，用什麼方法根本不重要。鄧爺爺都說過：能抓老鼠的就是好貓

 

還有一次，碰到一個不靠譜的需求，需求方發給我一個網站，說對這個網站不滿意，讓我改上面的功能。網站原始碼沒有，網站伺服器許可權沒有，總之是什麼都沒有，完完全全是一個別人家的網站，讓我改上面的功能，這尼瑪任性的可不是一點點，真把程式設計師當神仙了。換作別人，估計一巴掌就把需求給搧回去了。但偏偏是我，真就把這個問題給解決。你們是不是以為我把人家網站的伺服器給黑了，把程式碼down下來，改成自己想要的樣子。當然不是，我是一個法律意識很強的程式設計師，不會幹這種蠢事。我的做法是為那個網站開發一個chrome瀏覽器外掛，外掛裡面有想要的功能。只要使用者裝上這個外掛，每當訪問這個網站，外掛功能就被啟用，供使用者使用。可以把這個外掛想象成遊戲的外掛，只是功能沒那麼複雜。

 

上面講的這些便是軟體開發中灣道超車，曲線救國的做法。我對於程式開發理解是，寫程式就是解決問題，問題擺在那裡，不哭不鬧不動不跳，因為在我眼裡它就是死的。而解決問題的方法卻是活的，只要願意去發掘，就會有無數種， 而且這無數種方法中，優劣好差各不相同，程式設計師要做的就是在這麼多方法中選擇一種最合適的。通常情況的問題，程式設計師並不用為選哪一種方法而糾結，因數解決問題的方法就像電梯裡的美女，一眼就能看的到，連選的力氣都能省掉。然而， 在極端情況下， 解決問的方法匱乏， 而且都是歪瓜裂棗， 要找到合適的真的不容易 。在這種情況下，光靠腦子靈活眼光獨到還不夠，程式設計師需要能在這些爛方法中找到一種最好的，然後駕馭之。會找好方法和駕馭這個被找到的方法，這是兩種能力，相互依賴，相輔相成，如能掌握並融會貫通，那麼程式設計師的戰鬥力將會被髮揮到極至。

 

我自己也在一直朝這個方向努力，所以我解決問題的指導方針是，用php不行我用java，用nodejs不行我用go；用電腦網頁不行我用windows客戶端，用手機網頁不行我用手機原生應用；目標是解決問題，至於解決問題用什麼方法，我從來不會被某一種技術給綁死。很多同學認為， 學這麼多語言這麼多技術有什麼用， 有的語言技術已經如萬能仙丹一般， 沒有什麼問題不能解決的， 如Java。 然而， 我覺得掌握多種技術帶來的好處並不僅僅是掌握技術的本身， 更重要的好處在於解決問題時不會受到侷限，說的直白一點就是會有更多的方案可供選擇，可供選擇的方法多了，那自然就有更大的可能選擇一種更好的方案，這便是前面說的兩種能力中尋找方法的能力。然而，光會尋找方法還不夠，還需要能駕馭這種方法，這便是一個深度問題了，想必所有程式設計師都知道，浮於表面的學習某樣技術，意義不大，打嘴炮吹牛逼的程式設計師會被人看不起，只有真正能解決問題的程式設計師才值得尊敬。因此，如能做到這兩點，你解決問的方法在別人眼裡就是神奇的不可思議。

 

最重要的是，這種方式持續久了，解決問題的思維習慣就會發生變化，思維習慣的變化致使考慮問題的方式變的不同，考慮問題的方式變的不同致使解決問的方法變的不同，解決問題的方法變的不同致使解決問題得到效果變的不同。從此， 你便是別的程式設計師眼中的超人。