【分享】 優秀程序員的代碼是「活的」

 全部的程序都須要某種形式的日誌記錄創建在它們之上，以便咱們能夠觀察到它正在作什麼。這尤爲在程序出錯時就顯得很是重要。一個優秀的程序員和一個糟糕的程序員之間的一個不一樣之處是一個優秀的程序員會增長日誌或其餘工具以便在程序失敗時方便調試。

當程序如同預期的同樣工做時，有日誌和沒日誌每每沒什麼差別。然而，一旦程序失敗，或你獲得一個錯誤的結果的時候，你會當即明白優秀的程序員和糟糕的程序員之間的差異。

例1：「讓咱們作一個可調試的版本」

比 如說，測試關於一個不能正常工做的調用case過來找我。咱們查看了日誌，而後發現問題貌似出在一個相鄰的模塊。對其餘模塊的調用返回值爲 空。而後咱們在那個相鄰的模塊中作了日誌記錄，從新跑了一遍測試case,卻沒有獲得任何更多的有用信息。沒有任何線索代表爲何會返回空 -難道是咱們下錯了參數，或者是某個外部系統致使的失敗，那個相鄰的模塊中是否是存在一個錯誤，又或者？

當 咱們去詢問負責這塊代碼的開發人員時，咱們獲得的回答是：「Oh，咱們必須作一個debug的版原本看看到底發生了什麼」。失敗！從某種意義 來講，從日誌中找到問題所在應該是可能的，若是問題存在一個運行的系統中，添加一個調試版本將會有大量的工做要作。代碼須要包含足夠多的信息在日誌，以便 你至少能夠對失敗的緣由有一些瞭解。

例2：「讓我看看咱們是如何走到這裏的」 ??

我 們的一個產品在工做時會找到一個短信息傳遞到手機最便宜的路徑。依據手機的當前位置和目標用戶所屬的運營商，有不少可能的路由選擇， 每個都有一個給定的成本和其餘特徵。除此以外，能夠有一些例外，好比說禁止一些路線，以促進其餘路線，一般 會有成千上萬的路由被定義，在每一個case中系統找到最便宜的一個路由，加上限定條件，而且傳遞消息。

如今，假想某個SMS信息使用A路線傳遞，可是咱們認爲他應該使用B，爲何A會被選擇呢？若是沒有任何日誌記錄信息，咱們只剩下成百個可能的途徑， 他們的成本，例外，以及一個複雜的算法，那麼祝你好運搞清楚爲何A會被選擇。

在咱們的實現中，全部可能存在的路由以成本大小的順序羅列在日誌中，當路由被不一樣的限制條件排除時，排除掉的路由和緣由就會被列在log中。 隨着算法的輸入，以及採起的步驟信信息列在log中，就會很容易的看出爲何某個路徑會被選取。

爲何不呢？

因此，爲何不是全部的程序員都會寫可調式的代碼呢？我能想到三個緣由：

1. 你必須足夠謙虛的意識到你的代碼會有不按預期工做的時候。我相信不少程序員會對此比較難過。

2. 若是你完全地測試了你的代碼，你應該確保它會在不少不一樣場合工做或失敗。對於每一個方案，很天然地加入日誌記錄，若是你沒有測試 那些狀況，你不太可能會在那裏添加記錄。

3. 不少程序員每每不會在產品系統中修復他們本身的代碼。若是在在線系統中有一個問題，但log並無反饋任何信息給你爲何這裏會有一個問題， 你會有一個很強烈的動機去增長log,以便下次遇到相同的狀況時幫助到你。

你的代碼可調試嗎？

固然會有一些狀況，對於程序爲何會失敗好的日誌信息也不能給你一個確切的信息。你可能仍是要作出那樣的調試版本， 可是你常常作記錄至少仍是會提供給你一些隱藏信息關於問題的可能性。

因此，你準備的怎麼樣了？當你的程序失敗時，log會告訴你哪兒出錯了嗎？

E8工做流平臺是基於源碼架構，圖形化流程設計器，高可靠性流程引擎，具有無限的擴展能力以及豐富的源碼組件，同時還支持手機APP，微信平臺。

歡迎體驗！
http://www.chinae8.net/cn/cpzx/info_4.aspx?subnavID=126

 本文出自互聯網：