回想自己剛入公司的時候，也是被安排為公司的乙個專案做日誌新增工作，也許你會好奇，為什麼程式功能結構都基本完工，但是，針對程式的日誌功能遲遲沒有填充呢？這種事後填補日誌功能的做法是否是一種高效正確的思路呢？當時，自己沒有想這麼多，於是就開始深入程式**中，原本打算是對每個較大的函式都做下記錄（當然指的是出錯的時候），當時自己乙個比較「天真」的方法是：在呼叫這些函式的地方，都填補上日誌，想要達到的效果就是，一旦發生錯誤，便能很快地從日誌中得知是那個函式發生了錯誤，同時記錄中包括了函式的類，函式名等資訊，目的性所謂很明確。想不成，領導並不認同這樣的日誌思路，因為，在設計程式架構的時候，已經設定了使用try catch的方法對每個函式進行錯誤捕捉（可能是源於c++程式設計規範吧），而在領導看來，我們的工作就是在這些try catch中新增記錄這些異常的**就ok了，而其中的**則完全沒有區別，只是通過新增一些特殊的字串資訊，作為定位的依據。
於是，「未將物件的引用應用於正確的物件例項」這類通用錯誤，就成了跟蹤錯誤的最大殺手，因為很多種情況，很多個地方都會出現這樣的問題，而你唯一能夠做的就是逐步沿著業務邏輯除錯**，看起來很酷，但其實這樣做是非常低效的，尤其是當產品上線以後，出個這樣的問題，你是沒有辦法進行逐步除錯的，如何定位問題便成了一件只有非常熟悉**的人才有可能「推算」出來的「棘手問題」……
後來，領導也意識到這樣的定位的確是一大障礙，所以，在我被安排的下乙個專案中，特意要求我要使用單元測試，因為使用.net環境，所以，當時對其中的單元測試功能還學習了一番，只是沒有那麼多時間來系統學習，後加上自己的懶惰思想，於是在一拖再拖之後，單元測試也流產了，取而代之的是針對每乙個細分模組的逐一測試，這顯然不是單元測試的精髓……
說來，編寫**也兩年有餘，日益感到上述所說兩方面的壓力，尤其是當乙個系統非常龐雜的時候。在各種框架日益橫行的今天，難道解決單元測試和問題排查就只能通過良好的變成習慣作為重點突破口麼（自己目前的看法，可能有很好的思路，還望指正！）？
於是，自己就自己編寫**的這點小經驗，根據自己目前處理的專案的情況，設想了乙個程式設計「架構」，以解決上述兩大難題，即「三段式」程式設計，其中就日誌記錄（即問題排查）已經做了簡單實現，可能還有待進一步的修正，下一步是想把單元測試也新增到其中……
除了使用目前網上盛行的一些單元測試，我更偏向於設計出乙個能更加「平民」化的測試結構……隨時更新中：
程式結構中的兩點重要元素
編寫 就目前編寫 程式和web form 程式而言，遇到的最棘手的問題，莫過於對程式 bug的勘察定位和對程式 潛在漏洞的排查，而對於剛剛開始編寫 的朋友來說，這兩點可能是既知重點，但是仍無從下手。回想自己剛入公司的時候，也是被安排為公司的乙個專案做日誌新增工作，也許你會好奇，為什麼程式功能結構都基...
LabView程式結構中的迴圈結構
程式結構 1.迴圈結構 2.分支結構 3.順序結構 ctrl n新建乙個子vi。1.while迴圈 左下角i迴圈計數端子，右下角是條件端子 真時停止 繼續 移位暫存器 將陣列從乙個迴圈週期傳遞到另外乙個迴圈週期。a.移位暫存器是需要初始化的。b.右鍵移位暫存器新增元素，新增元素也必須初始化 c.右鍵...
計算樹中兩點之間的距離
題目 要求倒不麻煩，乙個節點資料不重複的二叉樹，設其元素型別為整型，找出最小元素與最大元素之間的路徑長度，即兩個節點之間的連線距離，不是節點個數。過程 以陣列元素來構建二叉樹，自定義陣列為，以 2 i 1,2 i 2 表示子節點，構建樹結構如圖 public class t 二叉樹基本節點資料 tr...