44. 不要靠巧合程式設計總是意識到你在做什麼；don』t program by coincidence
只依靠可靠的事物。注意偶發的複雜性，不要把幸運的巧合與有目的的計畫混為一談。
不要盲目的程式設計；按照計畫行事；
依靠可靠的事物（不要依靠巧合或假定）；
為你的假定建立文件；
不要只是測試你的**，還要測試你的假定，不要猜測，要實際嘗試它；
為工作劃分優先順序；
不要做歷史的奴隸，不要讓已有的**支配將來的**，如果不再適用，所有的**都可被替換，不要讓已經做完的事情約束你下一步要做的事情。
知其然，知其所以然；
能工作，要知道為何能工作；會失敗，要知道為何會失敗。
不要靠巧合去七拼八湊。
45. 估計你的演算法的階估計演算法適用的資源－時間、處理器、記憶體等estimate the order of your algorithms
在你編寫**之前，先大致估算事情需要多長時間
46. 測試你的估計
test your estimates
對演算法的數學分析並不會告訴你每一件事情。在你的**的目標環境中測定他的速度。
用大o表示法來分析演算法的效率。培養一種直覺，對一些常見的演算法，一看流程就能說出其大o表示，如氣泡排序o(n^2)，遍歷o(n)。
47. 早重構，常重構重寫、重做和重新架構**－重構refactor early, refactor often
就和你會在花園裡除草、並重新布置一樣，在需要時對**進行重寫、重做和重新架構。要剷除問題的根源。
重複、非正交的設計、過時的知識、效能，需要重構
需要慎重、深思熟慮、小心進行。
1. 不要試圖在重構的同時增加功能
2. 擁有良好的測試，經常執行測試
3. 採取短小、深思熟慮的步驟
我並不同意很多書中宣稱的一定要重構，以及他們的理由。重構始終是一種藝術，你要在理想與現實之間做出乙個權衡。
《重構》那本書介紹了許多重構的方法。但其實我們更需要的是乙個比較可靠、高效的重構器，至少c++方面做的還不夠好，vs本身未提供多少，而va外掛程式的重構功能相當有限。
48. 為測試而設計單元測試可提供：design to test
在你還沒有編寫**時就開始思考測試問題。
49. 測試你的軟體，否則你的使用者就得測試
test your software, or your users will
無情地測試。不要讓你的使用者為你查詢bug。
１.一些例子，說明怎樣使用你的模組的所有功能。
２.用以構建回歸測試，以驗證未來對**的任何改動是否正確的一種手段。
易於測試的**會有非常簡潔的介面，非常明確的約定，從而也有更好的質量。這是從比較細節的，**的角度來看的。
而從軟體角度來看，就應該提供完善的log機制與診斷功能，這樣才能在客戶環境下精確的定位錯誤。
50. 不要使用你不理解的嚮導**如果你只是為了編寫乙個測試程式，你可以不理解嚮導產生的**；但是如果你需要基於嚮導建立乙個軟體，理解嚮導產生的**就顯得十分必要了。我想這也是為什麼《深入淺出mfc》如此風行的原因吧，大家其實都意識到這個問題了。don』t use wizard code you don』t understand
嚮導**可以生成大量**。在你把它們合併進你的專案之前，確保你理解全部這些**。
第 6章 函式
6.1.2引數 2.引數陣列 c 允許為函式指定乙個 只能乙個 特殊的引數，這個引數必須是函式定義中的最後乙個引數，可用params關鍵字定義他們 如 params int vals 3.引用引數和值引數 理解 將本來在函式中引數按值引用的規則改變成按傳遞引用，使得這個引數會改變,定義引數和傳遞引數...
第6章 函式
1.自動物件 只存在於塊執行期間的物件 2.區域性靜態物件static 在程式執行路徑第一次經過物件定義語句時初始化，並且知道程式終止才被銷毀，如果區域性靜態變數沒有顯示的初始值，初始化為0.3.如果函式無須改變引用形參的值，最好將其生命為常量引用。4.使用引用形參返回額外資訊 5.和其他初始化過程...
第6章 小結
在這一章，你學習了如何為應用程式新增儲存層。一開始，使用儲存和恢復例項狀態處理函式來在會話期間儲存 activity 的例項資料，之後，學習了 sharedpreference 你可以使用它在程式的元件間儲存例項的值和使用者的設定。android 為所有的應用程式提供了完整的 sqlite rdbm...