資源管理：
對於乙個程式最可怕的就是資源洩漏，其中最可怕的覺得是程序執行緒或者檔案的控制代碼沒有被**，這樣的錯誤對我來說真的很可怕也很難發現。
之前在維護乙個系統的時候，因為有人在寫程式的時候使用了tmp目錄，並在tmp下面 建立了檔案。
系統的反映時執行幾天之後，系統突然無法登陸，在過一段時間系統無法提供服務。因為無法登陸服務期所以根本不知道發生了什麼。
使用了2天的時候和運氣才發行這個錯誤。
如何避免：
記憶體洩漏一般使用檢查記憶體的工具，一般感覺記憶體洩漏的時候不是很多，而且如果記憶體足夠大的話一點點的記憶體洩漏在大型專案中很難避免，但是破壞力也不是特別的，可能和我的開發背景有關，一般我們的系統都難持續工作3個月之上，水平啊。
記憶體使用上存在兩種申請和釋放的方法。誰申請誰釋放，其他人申請記憶體，使用者釋放。
感覺都不錯，根據不同的情況使用不同的方式。
一直沒有好的辦法處理其他的資源洩漏，一些真的對所有的資源都做封裝管理才能做到。
如果這樣是不是太複雜了，現在還是手動的檢查。
從小工到專家1
1.如果我確實同意要為某個結果負責，就應切實負起責任，當出現失誤時，誠實地承認它，並給出選擇。2.預先制定應急計畫，原始碼必須備份。3.出現問題不要向老闆說藉口，而是挽回的方式。4.不僅要留心大圖景，還要持續不斷地觀察周圍發生的事情。5.讓使用者參與決定所製作的東西何時是足夠好。6.不要許諾不可能兌...
06從小工到專家6
1 編寫規範是一項重要的職責，但問題是很多人可能會陷在這裡，不斷地增加規範項。我們可以做這樣乙個嘗試，寫乙份簡單的描述，告訴別人怎樣繫鞋帶。這可能是乙份並不能幫助他人的描述，因為對有些事情 做 勝於 描述 因為無意識的行為更快，考慮規範反而會拖慢進度。2 對待開發文件也一樣，不要編寫過於詳細的規範。...
02從小工到專家2
1 可靠的開發軟體，並讓我們的開發更易於理解和維護的唯一途徑，是遵循我們稱之為 dry 的原則 系統中的每一項都必須具有單 一 無歧義 權威的表示。dry 是 dont t repeat yourself 的縮寫。2 重複的產生通常有以下種類 強加的重複。開發者覺得他們無可選擇，其實是有一些方法讓我...