當程序不工作時，開發者常用的借口

都說態度決定一切，良好的態度也可以成就一名優秀開發者。但在現實生活中，尤其是遇到問題、功能實現失敗或不能正常運行時，大家就會開始抱怨或者尋找一些借口，這些借口完全是沒用的或者是阻礙你前進的攔路虎。而真正專業的態度應該著眼于項目和團隊的積極結果，關注個人和團隊的成長，并且圍繞當前的工作積極展開各項任務。

本文作者Rajaraman Raghuraman是一名擁有8年開發經驗的軟件開發人員，他總結了程序員遇到問題時經常找的借口或理由，大家不妨看下，不知各位中槍了沒，如果沒有，大家不妨在移步看看“ 程序員遇到Bug后的30種常見反應”。

圖片來自：cheatcc.com

1.在我機器上還運行好好的

開發人員常會遇到這樣的問題，他們感覺測試人員或者客戶的電腦有一種神奇的魔力，可以給程序注入bug。因為程序在他本人電腦上可以很好的運行，為什么到他們那就會出現問題。

想要避免這樣的借口發生，開發人員需要弄清楚開發、測試、客戶的運行環境。bug是在何種配置/環境下出現，當你弄清楚這些，相信你就不會再發出這樣的抱怨了。另外一種避免方式是擁有持續集成環境，檢查每一段代碼，并且把代碼編譯和部署到一些測試機器上。

2.你這是最新的build嗎？

當測試人員告知開發者有bug或者提交bug時，程序員常會問，你測試的應用程序是最新的構建狀態嗎？其實，這種情況一般很少發生，一般提交的bug都是在最新的build里發現的。

想要避免這種情況發生最好有一個進程，可以驗證測試人員使用的代碼是最新最有效的。另一個方法是有一個持續集成環境，代碼可以自動build和部署到測試服務器上。

3.肯定是配置問題

如果有開發人員這樣對你說，你可以回答：“或許有可能，你能告訴我是哪個文件的配置出現問題了嗎？我需要讓它運行起來。”正如上面的對話，用戶需要一個確切的回答，而非通用、模棱兩可的答案。

最佳的做法是把所有配置文件里的相關參數定義在一個單獨的配置文件里，把所有的動態值寫在某個日志文件里，以防在引用時發生混亂。

4.先提出一個缺陷，然后我再確認它

個人角度來看，一個未得到確認的缺陷是很令人煩惱的。開發人員要么在開發過程中對缺陷進行跟蹤，要么就是程序員和測試人員之間協調，通常情況下，開發人員和測試人員應該攜手來進行缺陷的確認，以防弄出一些模棱兩可的缺陷出來。

要想避免這樣的情況發生，最好的方法就是測試人員和開發人員之間有良好的團隊士氣和協作。這樣，他們就會很容易進溝通討論，并且對缺陷進行確認和跟蹤。

5.重啟一下機器看看

這可以說是程序員殺手級的擋箭牌了，偶爾這個會奏效，但通常都是假的。想要避免這種情況發生就要弄清楚架構、代碼以及相應的開發環境。

6.我不確定它為什么不工作，讓我檢查一下

相信用戶最討厭開發者說出這樣的借口，作為一名開發者，你竟然都不確定某個特定的模塊/功能為什么不工作，那么你是否正確地理解了該功能和代碼設計呢？

想要避免這種情況發生，開發人員應該對各個模塊有個清晰的思維導圖，一旦問題發生，應該立即進行分析并且找出可能導致問題發生的原因。如果對問題出現的情況不知所措或者根本不知道原因所在，這很可能是因為代碼設計不良或者缺乏對相應功能模塊的理解。

7.5分鐘以后再試試

好吧，難道你對程序設置了計時炸彈，好讓它5分鐘以后再工作。

這個借口真的是很可笑，開發者應該意識到代碼不會隨著的時間的改變而改變，除非你設置了某些特定的定時代碼功能。

8.我不認為我的代碼有錯

有些程序員在面對缺陷時，通常都會說：“我的代碼沒錯啊。”作為開發團隊里的一員，應該沒有“我的代碼一說”，還不如換種說法更好，比如可能是某個模塊出現了點問題，我去檢查一下看看，最后再找到相應的開發人員，這樣更加有利于振奮團隊士氣。

想要避免這種情況發生，最好的方法就是擁抱團隊文化，每個開發者都要清楚各個模塊的作用和功能，并給予相應的權限。

除了以上八句話，開發人員在聽到自己的程序有缺陷或者功能失敗時還會冒出哪些借口或者擋箭牌呢？大家不妨分享下吧。

來自： Java Code Geeks

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈