程式設計師必須養成良好的**習慣
「提問的智慧型」之程式設計師篇
程式設計師必看vb.net case語句拓展篇
為web程式設計師解毒：9個ie常見bug的解決方..
php程式設計師最容易出現的錯誤總結
在過去的幾個星期裡，我作為父親一直在教自己年輕的孩子開車。對於新手司機來說，學習控制汽車的整個過程（把握方向盤、使用各種踏板、換擋、看後視鏡，等等）是比較傷腦筋的。但是所有這些都是相對簡單的事情，大部分年輕駕駛員都能掌握，不會有太大的問題。
新手司機在經過一段時間的鍛鍊之後，當他們跟其他的司機一樣外出上路時，真正難受的經歷才開始。這時才是真正學習開車的時刻，因為僅僅能控制汽車並不能夠成為好司機，雖然這是重要的前提條件。相反，能夠預料和避免一些意外的情況才能成為乙個好司機。不幸的是，你不可能教給他這些技巧。
你可以告訴他們一些潛在的問題。你可以描述這些問題，並告訴他們在那些情況下應該怎樣做。你甚至可以進行一些實地演習。但是，每個新手必須親自經歷過很多普通的駕駛危險之後（而且要倖存下來）才能預料類似的情況，然後採取措施避免這些問題。
遺憾的是，優秀程式設計師的成長也需要經歷乙個這樣的過程。咱們來看一下開發乙個應用程式，功能是在乙個檔案中儲存一些資料，每次使用者啟動這個應用程式的時候都呼叫這些資料。
◆新手程式設計師（已經學過在檔案中讀取和寫入資料的語法）面對這個問題只會簡單的寫幾行能夠讀取和儲存資料的**。
◆如果他們已經有過一段時間的程式設計經歷，他們可能會寫乙個測試程式來確保**讀取和寫入的資料是正確的。因為所寫的**工作了，初學者就認為可以了，他們會認為已經自己完成了任務，也符合規格，並且還對他們的工作進行了測試。
◆乙個專家級的程式設計師，當面臨同樣的情況的時候，他知道這不是一件簡單的事情。當然，寫幾句在檔案中讀取或者儲存資料的**非常簡單——這只是當一切都順利的時候。但是如果要讓應用程式能夠處理所有可能出錯的情況，這就不是那麼簡單了，就算是這種簡單的操作也一樣。因為，檔案可能不存在，硬碟可能滿了，檔案可能損壞了，使用者可能沒有許可權去讀取檔案，這個檔案可能正在被使用。如果檔案不在本地磁碟，程式可能都接觸不到這個檔案。
當然，不是所有這些問題都會同時發生在某個特定的時刻，但是那些已經把應用程式交付給很多使用者的開發人員都知道，經過足夠長的時候，所有的這些問題都會發生，這是遲早的事。
乙個專家可以告訴初學者去檢查這些可能出現的情況，那麼對於這些特定的問題，不是專家的開發人員只能對其進行編碼，而只有專家才能預料並避免他們。就像開車一樣，乙個好的程式設計師不僅要能夠解決已經發生的問題，而且還應該能夠預料一些沒有發生過的問題。不幸的是，專家是靠犯錯誤才學到這些本領的，這對於人類來說是件傷心的事情。每一代想要成為專家的人只有在經歷過上一代人所犯的所有錯誤之後才能成為專家。neils bohr解釋說，「專家就是在乙個非常窄的領域內犯過所有可能的錯誤的人。」
但是當你跟乙個新手駕駛員坐在同一輛汽車上的時候，你可能就會更加欣賞p. j. plauger的這個版本了，「我對任何領域中專家的定義是乙個對什麼是真正可怕的事情知道得足夠多的人。」
充滿荊棘的專家程式設計師之道
我作為父親一直在教自己年輕的孩子開車。對於新手司機來說，學習控制汽車的整個過程 把握方向盤 使用各種踏板 換擋 看後視鏡，等等 是比較傷腦筋的。但是所有這些都是相對簡單的事情，大部分年輕駕駛員都能掌握，不會有太大的問題。新手司機在經過一段時間的鍛鍊之後，當他們跟其他的司機一樣外出上路時，真正難受的經...
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...