注重實效的程式設計師的特徵：是他們處理問題、尋求解決方案時的態度、風格、哲學。設法把問題放在更大的語境中，設法注意更大的圖景對所做的每件事情負責，接受變化，擁抱變化，理解工作的語境。廣泛的知識和經驗基礎交流
我的原始碼讓貓給吃了：在所有弱點中，最大的弱點就是害怕暴露弱點。為自己的行為負責。對我們的無知和錯誤，應該誠實、坦率。預期到超過自己能力範圍的風險，可以不必承擔，若沒有預期到已經發生，則必須承擔。提供各種選擇，不要找蹩腳的介面
任何談話可以先預演一遍，預知一下結果不要說做不到，要想有什麼解決方案
足夠好的軟體欲求更好，常把好事變糟（李爾王）影響我們控制質量的因素：時間、技術、急躁
缺乏職業素養的做法：1）無視使用者的需求， 一味的給程式增加新特性，或一次一次的潤飾**2）許諾不可能兌現的時間標度3）為趕上最後期限而消減基本的工程內容。
範圍和質量應該作為系統需求的一部分規定下來：使質量稱為需求問題給使用者的東西，要及早讓他們使用，他們的反饋常常會吧你引向更好的最終解決方案
如果不懂得何時止步，繪畫會迷失在繪製中（不要因為過度修飾和過於求精而毀損完好的程式）
交流：我相信，被打量比被忽略要好講清楚自己想要說的內容（可以寫出大綱、撰寫文件）了解你的聽眾（了解他們需要什麼）選擇時機選擇風格（讓你的風格適合你的聽眾）讓文件美觀（你的主意很重要，讓他們以美觀的方式傳遞到你的聽眾）讓聽眾參與，做傾聽者，回覆他人，你說什麼和你怎麼說同樣重要。
重複的危害：可靠的開發軟體、並讓我們的開發更易於理解和維護的唯一途徑，是尊徐我們稱之為 dry的原則：系統中的每一項知識都必須具有單
一、無歧義、權威的表示。< 不要重複你自己 >在兩個或更多地方表達同一事物時，若果你改變其中一處，你必須記得改變其他各處重複範疇：1）強加的重複：開發者覺得他們無可選擇 ------ 環境似乎要求重複2）無意的重複：開發者沒有意識到他們在重複資訊開發過程中，會因為效能原因而選擇違反 dry原則，這經常會發生在需要快取資料，以避免重複昂貴的操作。訣竅是：使影響區域性化。3）無耐性的重複：開發者偷懶，他們重複，因為似乎那樣更容易。時間壓力：驅使最優秀的人走捷徑的力量一種最容易檢測和處理的重複形式，此時需要你接受訓練，並願意為避免以後的痛苦而預先花一些時間4）開發者之間的重複：同一團隊（或不同團隊）的幾個人重複了同樣的資訊最難檢測和處理的重複處理此問題的最佳方式：鼓勵開發者相互進行主動的交流（論壇，交流組）
正交性：如果兩條直線相交成直角，他們就是正交，比如座標軸。用向量的術語說，這兩條直線互不影響。沿著某一條直線移動，你投影到另一條直線
的位置不變。非正交系統的改變與控制更複雜我們要設計自足的元件：獨立，具有單
一、良好的定義的目的和。
正交系統的優點：1）提高生產效率改動得以區域性化，開發時間和測試時間降低正交的途徑還能夠促進復用若果對正交的元件進行組合，生產率會有相當微妙的提高
2）降低風險正交的途徑能降低任何開發中固有的風險，有問題的**區域被隔離開使系統更健壯，正交系統很可能得到更好的測試不會與特定的**商、產品、平台緊綁在一起，
在工作中應用正交原則的幾種方式：1）專案團隊2）設計3）工具箱與庫（ ejb，面向方面程式設計 aop）4）編碼5）測試6）文件：座標軸是內容合表現形式
可撤銷性如果某個想法是你唯一的想法，在沒有什麼比這更危險的事情了。< 不存在最終決策 >每當有兩種可能結果的牙合反應發生時，宇宙就會被轉殖。在其中乙個宇宙中個，事件發生，另乙個宇宙中，事件不發生。
薛丁格的貓：在乙個封閉的盒子中有乙隻貓，還有乙個放射性粒子，這個粒子有 50%的機會裂變成兩個粒子，若果發生裂變，則貓被殺死；如果沒有，則貓沒有事。那麼，貓是死是活？根據薛丁格的理論，答案是」都是「。只有開啟盒子時，你才知道你在哪乙個宇宙裡。
曳光彈：< 用曳光彈找到目標 >
曳光**方法的優點：1）使用者能夠及早看到能工作的東西2）開發者構建了乙個他們能在其中工作的結構3）你有了乙個整合平台4）你有了可用於演示的東西5）你將更能夠感受到工作的進展
估算：在進行估算的過程中，你將會加深對你的程式所處的世界的理解。通過學習估算，並將此技能發展到你對食物的數量級有直覺的程度，你就能展現出一種魔法般的能力，確定他們的可行性< 估算，已避免發生意外 >進行估算時，要注意解答問題的語境（精確 / 大概）1）多準確才足夠準確2）估算來自**：已問題模型為基礎
3）理解提問內容4）建立系統的模型5）把模型分解為元件6）給每個引數指定值7）計算答案8）追蹤你的估算能力9）在被要求進行估算時說什麼
但是從開始接觸程式，我害怕暴露缺點弱點的問題得到了很大的改善。因為畢竟如果你不不去改正這乙個bug，你不去直面他，這個程式跑不起來，你的作業工作交不了差。其實我們每乙個人都害怕失敗，害怕那乙個個的bug，可是你終將面對他，解決它。
所以我認為不要害怕失敗，也不要害怕那紅色的警示。當你沒有勇氣面對它時，他是攔路虎，但當你鼓起勇氣面對它時，他卻只是紙老虎。
注重實效的程式設計師的特徵：是他們處理問題、尋求解決方案時的態度、風格、哲學。設法把問題放在更大的語境中，設法注意更大的圖景對所做的每件事情負責，接受變化，擁抱變化，理解工作的語境。廣泛的知識和經驗基礎交流
我的原始碼讓貓給吃了：在所有弱點中，最大的弱點就是害怕暴露弱點。為自己的行為負責。對我們的無知和錯誤，應該誠實、坦率。預期到超過自己能力範圍的風險，可以不必承擔，若沒有預期到已經發生，則必須承擔。提供各種選擇，不要找蹩腳的介面
任何談話可以先預演一遍，預知一下結果不要說做不到，要想有什麼解決方案
足夠好的軟體欲求更好，常把好事變糟（李爾王）影響我們控制質量的因素：時間、技術、急躁
缺乏職業素養的做法：1）無視使用者的需求， 一味的給程式增加新特性，或一次一次的潤飾**2）許諾不可能兌現的時間標度3）為趕上最後期限而消減基本的工程內容。
範圍和質量應該作為系統需求的一部分規定下來：使質量稱為需求問題給使用者的東西，要及早讓他們使用，他們的反饋常常會吧你引向更好的最終解決方案
如果不懂得何時止步，繪畫會迷失在繪製中（不要因為過度修飾和過於求精而毀損完好的程式）
交流：我相信，被打量比被忽略要好講清楚自己想要說的內容（可以寫出大綱、撰寫文件）了解你的聽眾（了解他們需要什麼）選擇時機選擇風格（讓你的風格適合你的聽眾）讓文件美觀（你的主意很重要，讓他們以美觀的方式傳遞到你的聽眾）讓聽眾參與，做傾聽者，回覆他人，你說什麼和你怎麼說同樣重要。
重複的危害：可靠的開發軟體、並讓我們的開發更易於理解和維護的唯一途徑，是尊徐我們稱之為 dry的原則：系統中的每一項知識都必須具有單
一、無歧義、權威的表示。< 不要重複你自己 >在兩個或更多地方表達同一事物時，若果你改變其中一處，你必須記得改變其他各處重複範疇：1）強加的重複：開發者覺得他們無可選擇 ------ 環境似乎要求重複2）無意的重複：開發者沒有意識到他們在重複資訊開發過程中，會因為效能原因而選擇違反 dry原則，這經常會發生在需要快取資料，以避免重複昂貴的操作。訣竅是：使影響區域性化。3）無耐性的重複：開發者偷懶，他們重複，因為似乎那樣更容易。時間壓力：驅使最優秀的人走捷徑的力量一種最容易檢測和處理的重複形式，此時需要你接受訓練，並願意為避免以後的痛苦而預先花一些時間4）開發者之間的重複：同一團隊（或不同團隊）的幾個人重複了同樣的資訊最難檢測和處理的重複處理此問題的最佳方式：鼓勵開發者相互進行主動的交流（論壇，交流組）
正交性：如果兩條直線相交成直角，他們就是正交，比如座標軸。用向量的術語說，這兩條直線互不影響。沿著某一條直線移動，你投影到另一條直線
的位置不變。非正交系統的改變與控制更複雜我們要設計自足的元件：獨立，具有單
一、良好的定義的目的和。
正交系統的優點：1）提高生產效率改動得以區域性化，開發時間和測試時間降低正交的途徑還能夠促進復用若果對正交的元件進行組合，生產率會有相當微妙的提高
2）降低風險正交的途徑能降低任何開發中固有的風險，有問題的**區域被隔離開使系統更健壯，正交系統很可能得到更好的測試不會與特定的**商、產品、平台緊綁在一起，
在工作中應用正交原則的幾種方式：1）專案團隊2）設計3）工具箱與庫（ ejb，面向方面程式設計 aop）4）編碼5）測試6）文件：座標軸是內容合表現形式
可撤銷性如果某個想法是你唯一的想法，在沒有什麼比這更危險的事情了。< 不存在最終決策 >每當有兩種可能結果的牙合反應發生時，宇宙就會被轉殖。在其中乙個宇宙中個，事件發生，另乙個宇宙中，事件不發生。
薛丁格的貓：在乙個封閉的盒子中有乙隻貓，還有乙個放射性粒子，這個粒子有 50%的機會裂變成兩個粒子，若果發生裂變，則貓被殺死；如果沒有，則貓沒有事。那麼，貓是死是活？根據薛丁格的理論，答案是」都是「。只有開啟盒子時，你才知道你在哪乙個宇宙裡。
曳光彈：< 用曳光彈找到目標 >
曳光**方法的優點：1）使用者能夠及早看到能工作的東西2）開發者構建了乙個他們能在其中工作的結構3）你有了乙個整合平台4）你有了可用於演示的東西5）你將更能夠感受到工作的進展
估算：在進行估算的過程中，你將會加深對你的程式所處的世界的理解。通過學習估算，並將此技能發展到你對食物的數量級有直覺的程度，你就能展現出一種魔法般的能力，確定他們的可行性< 估算，已避免發生意外 >進行估算時，要注意解答問題的語境（精確 / 大概）1）多準確才足夠準確2）估算來自**：已問題模型為基礎
3）理解提問內容4）建立系統的模型5）把模型分解為元件6）給每個引數指定值7）計算答案8）追蹤你的估算能力9）在被要求進行估算時說什麼
但是從開始接觸程式，我害怕暴露缺點弱點的問題得到了很大的改善。因為畢竟如果你不不去改正這乙個bug，你不去直面他，這個程式跑不起來，你的作業工作交不了差。其實我們每乙個人都害怕失敗，害怕那乙個個的bug，可是你終將面對他，解決它。
所以我認為不要害怕失敗，也不要害怕那紅色的警示。當你沒有勇氣面對它時，他是攔路虎，但當你鼓起勇氣面對它時，他卻只是紙老虎。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...