第一， 度的把握。
專案開發的控制有四個要素：成本，時間，質量，範圍。現在時間，質量已經決定，而且不由我們控制，那麼為了控制成本，我們就只有對範圍進行界定。
首先要制定出乙個這段時間結束後要達到的目標。包括專案的效能，可擴充套件性，可以執行性，穩定性，友好性等等。乙個清晰的目標能指引每個人向這個努力。而且這個目標對制定範圍有著實際的指導意義。
另外乙個是目前最迫切需要解決的問題，這是制定範圍最優先考慮的。
還有乙個是風險。（現在***驅動越來越流行，除了風險驅動之外，還有測試驅動，特徵驅動，資料驅動，use case驅動等等）。怎麼樣制定乙個範圍，保證我們不會陷入泥潭，而又能段時間內拿出乙個讓別人耳目一新的 版本，使我們需要考慮的問題。
如何平穩過渡
小步快跑的方式是乙個安全的辦法，避免一次作太大的，無法**的改動，分成幾個小的階段，步步為營。
接受變化
現在的系統雖然有問題，但是起碼是比較穩定的，正常工作的，在work，right，best這條路上起碼走到了right，要接受而且擁抱變化也是乙個需要考慮的地方。
第二，技術的選擇
對於架構，現在還沒有乙個統一的思想，選擇是和上面範圍的界定息息相關的，確定目標之後才能選擇合適的架構。
焦點主要集中在
表示層和entity的繫結，entity的持久化，各層之間傳遞資料的方式，快取物件之間的依賴關係，物件之間的協作，統一的安全控制的錯誤處理。配置資訊的管理，unit test.
如果不是看了文章的標題，我想我會很容易的接受，並將其放入收藏夾。我不相信像作者這樣有經驗的人會犯文不對題的問題，所以我又仔仔細細將文章看了一遍，似乎也看出一點東西，但對於重構，作者確實是用筆太少。
讓我們按照作者的思路來考慮這個問題，由於成本、時間等多面因素，我們不可能對一切變化做出準備，儘管有很多辦法可以幫助我們刺激變化，及時發現潛在的變化，但難免的，在專案後期，我們還是會面臨需求變更的危機，如果這個變化是我們所未預料的，並且牽一發動全身，那麼，這種情況下，我們是否需要重構？
先讓我們看看《重構》的作者是怎麼定義重構的：「在不改變**外在行為的前提下對**做出修改，以改進**的內部結構的過程。」請注意，重構是在不改變外在行為的優化。這就像人身上髒了要洗澡一樣，是頻繁、小度量的工作步驟。如果在前幾次的迭代中還不能激發變化，我們就需要考慮度的把握，不要奢望在專案後期進行系統級的重構，它的代價太大了。如果你的改動將影響整個系統，那你只能想別的辦法補救，所以，放棄重構吧，至少在當前這個可執行的版本中。
就像作者說的work,right,best一樣，重構的前提是**可以正常工作，目的是讓**更好的工作的。所以更多時候，我會把設計看作系統級的，把重構看作**級，它們是兩個階段的兩種工作，不能混為一團。
重構不是萬能的，不要依賴於重構，也不要誇大了重構的功用，在很多時候，它並不能改善你設計上的缺陷。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上看法是我自已對重構不成熟的看法，並不代表原作者的觀點，可能曲解了原作者的用意。不當之處，望各位高手指正。
Deep Learning 從頭開始
deep learning已經火了好久，有些人已經在這裡面耕耘了好多年，而有些人才剛剛開始，比如本人。如何才能快速地進入這個領域在較短的時間內掌握deep learning最新的技術是值得思考的問題。就目前的情況看，通過網路上的課程及各種tutorials以及各種 來研究這個領域是最佳的途徑。經過一...
git從頭開始
當你本地修改了乙個檔案，而且該檔案被另乙個人修改，並push了，那麼 users terry workspace git練習 git practise git master git pull updating 67e4e18.cdbf666 error your local changes to t...
English 從頭開始
我們有好多事情都不能重新開始，比如我們的人生你沒有辦法把自己在塞回媽媽的肚子裡吧？比如我們的時間在此時此刻只有這乙個時間，全世界不會再有第二個。比如我們後悔的事情.雖然有很多我們無法改變的事情存在，但也有許多我們可以改變的事情。雖然我們沒有辦法從一歲開始重新開始，但我們可以掌握自己的人生，做自己想做...