我總是覺得，開發者需要一個開發的態度，我在另一篇博文裡細說了這個問題。普遍來說，一旦開發出現了問題，開發人員都會編造藉口。只要這些理由是真的，這並不是什麼問題。但是，一旦這真的只是個藉口，這就會成為整個團隊的的問題所在。我自己也會對自己做過的那些藉口偶爾感到羞愧，在改正的同時並思考著如果在未來避免同樣的問題。下文列舉了一些常見。
0. 在我機器上是可以執行的
拜託，這可是開發人員最常用的藉口，《程式設計師給測試人員的20條高頻回覆》中的第一條就是它了。我們總是覺得測試或者使用者有著某種神奇的電腦，能在我們的程式碼裡填充著原本不存在的程式錯誤。這，完全不是真的。
唯一可以避免這種藉口的方法是意識到開發，測試和產品執行環境。想要做到這點，第一你需要問的就是，這是什麼樣的產品執行環境，得到更詳細的問題諮詢，並進一步檢視這是不是一個合理的問題。另一種方法是，建立一個持續整合的環境，同樣的程式碼，在同一個環境內的某些機器上開發，另一些機器上測試。
1.你用最新的版本了嘛？
這是另一個藉口。沒有使用最新的版本，或者測試了錯誤的版本是一個頗為常用的藉口。這也並不是不可以避免的事情。
去避免這個藉口的唯一方法，就是建立一個過程，驗證測試使用的是最新的版本。在一個持續整合的環境裡，程式碼自動歸檔，生成新的版本並在同時部署在測試的機器上。另一個方法去驗證正在測試的版本和開發的版本相同。
2.一定是配置問題
如果你告訴我這個，我一定會說，“對啊，可能是個配置問題。所以，你能告訴我是哪裡的配置出了問題了嘛？”如果你遇到相似的情況，你也很有可能問類似的問題。正如你所預料到的，人家在這個問題是尋找一個確切的答案，而不是泛泛之詞。
避免這個藉口的最佳方法，是把所有配置相關的引數都定義在分開的配置文件裡，並把動態值寫進日誌中，所以一旦出現混淆，總是可以參考配置文件裡的說明，來避免分歧。在執行的過程中使用文件規定的格式，可以使錯誤率降到最小。到時候，即使問題真的是由配置產生的，我們也可以輕鬆發現並找到解決方案。
3.請建立一個錯誤報告，我等下去查這個錯誤
從我的角度看，在確定是否是錯誤前就直接建立錯誤報告，是個蠻大的問題。這個問題，既可能是在過程中被追蹤著，也可能在測試人員和開發人員中間的協調問題。一般來說，測試人員和開發人員可以聯合作業，以防測試並不能真的追查到是否是開發錯誤。
避免這個問題的方法是，建立良好的測試人員和開發人員之間的關係。這樣子，開發和測試之間會溝通，討論並積極的尋找解決方案。
4. 試試重啟機器
殺手級的藉口。我也做過同樣的事情。確實，這真的能解決不少微軟相關的技術產品上（比如說，.NET），而且在某些特殊的情況下，重啟還是很起作用的。科學有效解決了相當多的微軟相關的開發軟體的某些錯誤。當然，更多的情況下，這樣子是沒啥結果了。
避免這個藉口的方法和上面列舉過的某個方法很類似： 我們需要注意開發環境、功能性、架構和程式碼設計。通過這些，我們可以確定這是否是一個真的軟體開發錯誤。
5. 我不確定這是否能執行，讓我看看
我個人非常討厭這個藉口。作為開發人員，如果你不確定某個特定功能是否能執行，這表示，要麼你根本沒有準確的明白這個開發的功能，要麼你沒有明白這個程式的設計。
解決方案：建立模組在心中的對映，一旦被告知問題，開發人員能立刻去分析問題，並找到問題的根源。如果不能確定問題根源，要麼是沒有設計好的程式碼，要麼就是對功能或模組沒有完全理解。
6. 五分鐘前它還能正常執行
多可愛的回覆。我猜你剛剛放下了一個定時炸彈在那裡，確保了這軟體5分鐘以後一定不能正常執行。
解決方案： 意識到時間並不能改變程式，除非這是段專門處理時間的程式。因此任何其他的功能都不能應該受到時間的影響。
7. 我覺得我的程式沒有任何問題
我一般不會給出這個答案。我相信在一個團隊中，沒有一個東西可以被稱為是我的東西。我寧願說哪個模組也許錯了。這個藉口是在嘗試著去找個人背黑鍋，絕對不利於團隊的最大士氣。
解決方案： 建立團隊文化，並輪換開發人員的開發模組，確保沒有一個開發人員只負責某一個特定的模組，保證每個團隊成員都對整個專案有了解認識。