一個條件判斷引起的思考

有一套web系統，會部署到不一樣的服務器上分別運行，這套系統相似於市面上的OA系統同樣， OA開發商會給不一樣的企業客戶部署一套獨立的互不關聯的系統，我維護的這套系統也差很少，分別被部署在互不關聯的服務器上，固然，這些系統的代碼是同一套，功能也都是相同的。

 

前兩天，有客戶反饋，他們系統的某個功能沒法正常使用。我開始排查問題，發現部署在其它服務器的系統這個功能都是正常的，惟獨這個客戶的系統存在問題。而據我所知，這套系統功能上對於全部客戶都是一視同仁的，是不存對於不一樣客戶有不一樣功能的狀況，由於部署在全部服務器上的代碼是同一份。

 

剛開始覺得問題是代碼不一樣步致使的， 後來反覆確認出問題的那套系統的代碼的確是最新。可爲何你們的代碼都是同樣的恰恰就它有問題呢？ 而出現的這個問題是純業務邏輯上的問題，跟服務器環境是不相關的。

 

反覆查看代碼， 反覆檢查配置文件，反覆在開發環境中調試，始終找不出個因此然來， 百思不得其解。

 

最終我不得不祭出只有在嘗試了全部方法後依然沒法奏效萬不得已纔會去使用的殺手鐗：線上調試。

 

我登上服務器，編輯代碼文件，在我認爲容易定位到問題所在的代碼位置加上打印數據的語句， 而後運行出問題的功能，觀察出問題的數據。在這裏我要感謝運維，感謝PHP，沒有他們的幫助，我還要繞個大圈圈才能幹這事。

 

而後以我觀察到的數據爲線索， 一步步的向上追蹤問題代碼， 最終發現， 在某一個很深的角落裏， 靜靜的躺着這樣一段代碼

 

 if($_SERVER["SERVER_NAME"] == "192.168.110.233" || $_SERVER["SERVER_NAME"] == www.xxx.com"){ //問題系統消失的功能的代碼 }

 

看到這段代碼我內心萬馬奔騰， 氣不打一處來， 而且狠狠的罵了一句：CMNLGB。 緊接着，一股深深的無力感涌上心頭。

 

使我受盡折磨，而且付出一下午美好時光的BUG竟然是由這麼一個在正常的代碼中毫不因該出現的腦殘的條件判斷引發了。 不值得啊。

 

我很想懟寫着段代碼的程序員，可是這個任務我完不成了， 由於她離職了，我就是從她手裏接手這套系統的。

 

因而我去除代碼中的這個條件判斷，同步代碼，出問題的系統能正常運行了。

 

冷靜下來之後， 我思考這個問題。 毫無疑問，對於這個問題，寫出這段代碼的程序員當時面對的需求應該是讓某個功能只在部分服務器上部署的系統中體現， 因而這個腦殘的條件判斷應運而生。

 

若是是我實現這個功能，我可能會在配置文件里加一個具備描述性名稱的flag，而後在代碼中讀取這個flag進行條件判斷。

 

然而，這樣作能從根本上解決問題嗎？ 顯然不能。 假如我面對的是這個改進版本的條件判斷，頂多能讓我有概率加速定位到問題所在，也就是我查看配置文件而且眼尖看到了這個配置項目就能明白事情的真相。若是我不去看配置文件，或者沒有看到這個配置項，那麼到達目標的路徑依舊不會有變化，並且這是大機率事件，由於此次出現的問題的特殊性，很難讓人將它和配置文件中的配置項聯繫到一塊兒。

 

那如何作才能從根本上避免這個問題？

 

爲項目維護一份文檔？ 不太現實，代碼都來不及寫， 哪有時間寫文檔。

 

離職交接時把注意事項說清楚？ 不太現實， 離職交接都是交接一些宏觀的內容，代碼上的細節不可能在這個範圍以內。

 

規範化項目管理， 功能迭代流程，更新系統功能須要審覈？ 不太現實，部門中這樣的項目大大小小几十個，這樣作成本過高了。

 

不給作這樣的需求？ 更加不現實，人家需求方分分鐘投訴到大領導那， 讓咱們吃不了兜着走。

 

那究竟怎樣作才能避免這類問題，才能讓我愉快的寫代碼， 求各位大神支招， 在下感激涕零。