**********實用主義**********=
不知什麼時候國內的技術人士開始流行大話技術了，不少《大話***》的書出現在世面上，這些書中最早也是比較經典的一本應該算是《大話設計模式》了，不得不說用這種方式來說技術問題，讓不少人更容易理解，這種方式傳遞的應該是一種思想：實用！
從《大話重構》試讀的兩章中可以看出這本書應該也是本著這樣的思想，正如書中所說關於重構的書籍很多，各公司的技術大佬們看的時候「激情洋溢、熱血澎湃"，但是到了實踐中」卻無所適從，經過一番苦苦掙扎之後，從此作罷「，所以看任何書都應該本著實用的角度去看，有用的我們就拿來，如果是沒用就捨棄，等到有用的時候再拿出來用。
最近我們的團隊在推敏捷開發，我們是乙個小團隊，總共也就10來個人，還分成了三個組，個別成員還是身兼多職，所以很多好的敏捷開發實踐、理論、方法在我們的團隊中並不實用，我們堅持」持續改進「，堅持實用主義，對我們有用的我們拿來嘗試，嘗試過效果不好的，就要果斷捨棄，尋求更好的方法。
對於重構，我們還沒有大範圍的開展這項工作，但是這個計畫已經提上了日程，不久的將來就會遇到這些問題，我想對於這本書或任何書應該持同樣的態度：實用主義。
正如武俠大師金庸所說的「無招勝有招」，如此多的重構方法不是要讓你去生搬硬套，而是應該對其進行深刻理解以後，最終變成你自己的重構方法。我們在實際工作中不要過於介意我們用了什麼重構方法，哪次重構是用的哪個方法，只要是合適的設計就ok。但是，在無招勝有招之前，我們必須要有招，即學會了、理解了各個招式，在實際工作中你才能想起這些招式，去運用這些招式。
**********過度設計**********=
第二章中講的例子很好，開始的時候，本著看看這書中用什麼樣的重構方式的態度來看，當我隨著筆者重構的思路走下去的時候，發現乙個簡單的例子居然用上了介面，這裡不得不說介面讓程式的擴充套件性，但是對程式的可閱讀性、可維護性卻大大降低。
很多時候閱讀**看到引數什麼的都是介面，文件中也講到什麼地方用什麼介面，可是應該用介面的哪乙個實現卻沒有說，這讓程式設計師們情何以堪。讀到最後才發現原來筆者用了乙個反面教材，原來這裡是想說明什麼是過度設計。
就這一章中的例子來說簡單的業務應該不需要這麼複雜的設計，如果真的需要，那麼就必須要說明介面的各種實現，並且要在這個介面的說明中編寫。我覺得在公司內部wiki中可以這樣來做：
建立建口的時候除了要說明這個介面之外，還要說明這個介面目前有哪些實現，每一種實現分別在什麼情況下使用。這樣無論是新程式設計師還是老程式設計師一看就能明白這個介面的用法了。
*****====小步大步**********
小步還是大步是個問題。
大步往往是推倒重來，很少有人有這個勇氣和這個能力。我見過乙個50多歲老程式設計師，經常有勇氣推倒重來，人家可以說是共和國高考恢復後第一批大學生，而且是數學專業，功底不是一般人能比的了得，隨著一次次的重構，對業務、需求了解的深入，設計思路會逐漸的成熟更加科學，重來對他來說不是難事。
而對於大多數人和很多從其它程式設計師中接手過來的程式設計師讓他們來重構的風險可想而知，推倒重來也好，小步快跑也好，都要做到很細小的細節，沒有對需求的充分的認識，小步也好，大步也好都有風險，相比之下小步可能更容易控制一些。所以小步還是大步，視情況而定，大步的重構需要做好充分的準備。
如果沒有底氣，不如敏捷一點，定乙個大目標，分解成若干個小目標，做成乙個乙個小迭代，每個小迭代完成後分析一下目標是否需要修正。（曾經聽過乙個管理高手說過一句話，計畫做的好不是高手，計畫改的好才是高手）
以前的乙個領導的做法我覺得可以借鑑，重構前要先明確目標，是提公升**規範性，還是提公升效能，還是提公升擴充套件性。
1、資料庫命名規範
2、頁面命名規範
3、變數命名規範
4、業務處理規範
每一種規範例舉幾個反例，例舉幾個正例。
這樣一來有了最終目標，有了階段目標，而且目標清晰，有條理，無論誰來做都很清楚明白。下來就開始劃分階段，第一階段開始資料庫命名規範調整。完成以後全面測試，然後再進行下一階段的任務。
而我所在的團隊正在採取這種辦法，目前所做的手術還沒有遇到過提公升擴充套件性、重構為外掛程式式結構之類的大小術，都是以提公升效能為主，之所以沒有做提公升擴充套件性之類的重構是因為目前的程式還沒有達到效能的需求，這個時候做那樣的重構先不說對效能有沒有損失，效能優化達到目標後是不是還需要再重構擴充套件性都不知道。
所以我們訂下了最終目標：每執行緒每秒鐘處理7筆業務。（我們的產品涉及到多執行緒處理）
有了最終目標，那先要了解目前的情況，經過測試我們知道當時的情況是平均每秒鐘處理4筆業務，
我們把這個目標的達成分解為：
1、單執行緒每秒鐘處理10筆業務。
2、實現多執行緒處理業務。
3、多執行緒環境下每筆業務處理平均耗時達到100毫秒以內。
4、多執行緒情況下達到與cpu顆數的最佳匹配。
目前我們進行到了第5步。但是最開始的時候並不是這樣。
1、單執行緒每秒鐘處理10筆業務。
2、實現多執行緒處理業務。
3、每執行緒每秒鐘處理7筆業務。
之所以現在的目標分解比原來多了是因為我們每進行一步的時候發現了很多問題需要去解決，隨著測試的深入對於多執行緒的理解也更加深刻，每乙個目標達成後我們都會討論下乙個要解決什麼問題，從而調整目標。
雖然我們沒有規範的文件，甚至**都不規範，但是我們正一步一步向著更好的方向前進。
重構的目的很簡單，就是為了讓產品更好，更強，但是具體下來怎麼才算更好、更強，誰也說不出個標準。
只要能證明比以前好，就要用，無論是技術層面的規範、**、需求、過程，還是管理方面的績效考核、激勵方式、文件、制度，都要遵循乙個規律：世界上唯一不變的就是變化！
而敏捷開發就是應對變化最好的辦法：持續改進。而重構也是一樣，不變是等死，變也許死得更快，也許不一定死。借一句古話：千里之行始於足下，無論怎樣重構，都是一步乙個腳印走出來，想要走的穩，每一步都要扎扎實實。
工作其實就是這麼輕鬆
好多上班族，在工作的時候都有這樣的感覺，每天都有做不完的事情，並且一天忙得天昏地暗的，回頭想一下，也不知道一天下來自己幹了什麼。但很多的公司的老闆，看到員工在不斷的忙呀忙，也感到些欣慰，因為請你過來是幹活的嘛。現實。所以很多都是被真忙和假忙累倒了自己。不過還有另一類人，上班看起來是沒有事幹的。其實說...
產品經理其實就是「客服」
經過這幾個月的體驗，我覺得產品經理是需要對這款產品的品質和使用者體驗負有不可推卸的責任，除了要做原型設計和管好進度之外，如何跟客戶溝通，獲得客戶需求反饋和修改意見也是產品經理的頭等大事。畢竟我們不可能閉門造車，開發出來的產品是給客戶使用的就需要了解客戶的需求和用法，這個時候你就要化身成為一名高階客服...
其實就是那麼回事
哥哥從北京回來了，終於我們還是一如既往的聊了很多，但是我冷血的對待了每次聊天內容。我想讓他看到 感到我的成長。不再是去年那個小孩，不開心就找他哭訴。本來以為他會一開始就很高興，看到我的成熟，他的失落讓我覺得自己真冷血無情。他儘管是替我高興我的成長，但是他覺得自己再沒有以前的價值了。或許有些東西就是這...