為什麼我想談談架構，和**的複製貼上這兩個話題呢，主要是前幾天看到一篇文章提到這兩個話題，在這裡想談談我的一些看法。
很多新人，都很談架構，好象貼了架構這個標籤就顯示高檔似的，把設計模式當作聖經，實在可笑。做架構，不是捧著書，然後閉門苦思就能想出來的。
架構，說穿了就是解耦，把變化的東西抽離出來，這個是它的本質。一般來說，越接近底層的東西越是穩定，越接近業務層的東西越容易變化。如果想在業務層上作封裝，也就是說想作架構設計，必須充分了解業務，沒有足夠的編碼經驗是不可能做好的。所以我經常說，架構不是設計出來的，而是做出來的，只要你做完了，整個業務都確定了下來了，了解充分了，你才可能設計出合理的架構。因為，架構是依賴於需求的，都需求沒有確定下來的情況下做架構，需求一變，那些所謂的架構不是要改得一踏糊塗，最後連自己都看不下去了，再推倒重來。事實上，應該是在專案的後期，完工了，業務流程也確定了，這個時候才有架構可談。
架構設計，還要考慮成本，很多新手，往往會忽視這個問題，也就是說，你必須考慮做這個架構要花多少時間，能節省多少時間。如果花費遠大於收益，那就沒有意義了。但是他們往往會解釋，現在多花點時間，後期就能少花很多時間了。但是事實往往是，前期多花時間，後期也多花時間，老是想讓這個架構變得更完美而沉迷其中，不能自拔。我們往往過度沉迷於架構，而忘了做專案的目的。做專案的，是為了解決客戶業務上的問題，能夠提高他們的業務水平，這才是本質。
架構，其實沒啥的，你的**看得多了，寫得多了，自然就會有架構了，記住封裝變化這個核心就行了。其實閱讀**、分析**、編寫**都是真正的基本功，正所謂「練拳不練功，到老一場空」，寫程式也是，作為新人，應該多花時間去閱讀**，編寫**上面，把自己的基本功練紮實才是最為重要的。
很多人都習慣性地鄙視ctrl+c，ctrl+v，好象一旦和它們沾邊，就是爛**，其實大可不必。我們考慮一下，為什麼不能ctrl+c，ctrl+v 呢？因為這些**不好維護，打個比方說，有兩處相同的**，那麼有可能就要改兩處。但是，你們有沒有碰到這麼一種情況呢，我們先來假設一下，有三個地方，a、b，c，都呼叫到乙個函式，這個函式稱為 m 吧。
但是，不久之後，接到乙個需求上的變化，a 的業務改變了，需要修改 m 的函式，但b，c 的沒有變，那麼我們習慣性的在函式 m 裡加個 if 來判斷，如果是 a 的業務，就如何如何。
不久之後，又收到需求變化，b 的業務改變了，那麼習慣性的，又會在 m 函式裡加乙個 if 邏輯塊。
不久之後，又收到需求變化，c 的業務改變了，那麼習慣性的，又會在 m 函式裡加乙個 if 邏輯塊。
請問，這樣 m 函式充滿這麼多的 if ，還容易維護嗎？還不如寫成三個函式呢。
所以，我們大可不必視複製貼上為洪水猛獸，只要在可控的範圍內就行了，當然，如果業務確定下來是不會變化的，還是乙個。什麼是可控呢？我覺得複製只有兩、三個地方，都問題不大。總之，存在這是合理，很多時候，我們總習慣於高估自己，而低估別人。
最後，還是那句話，我現在失業中，想尋找乙份從事研發方面工作，最好和資料庫、編譯技術打交道的，想找技術牛人的可以聯絡。 希望各位鄉親父老多多關照，謝謝大家。^_^
被神化的賈伯斯
賈伯斯去年過世，年紀不是很大，短短幾天內，他簡直被神化了，一直持續了半年多，於是很多人口中叫喊要 改變世界 稍微做出一點東西或者說有了那麼一點點幾乎誰都能想到的想法就要去 改變世界 創業，做產品，好大個泡沫.姑且不說這是由於過度狂熱導致一種迷失，在此我先潑點冷水，除了軍事征服和自然災難，沒有什麼可以...
被神化的海量資料處理和高併發處理
實任何簡單的問題，只要規模大了都會成為乙個問題，就如中國人口多，很多小問題都會變成大問題一樣。但處理這種海量資料的方法無非就是分治和 人海 戰術。使用人海戰術的前提是問題的劃分能夠支援這種人海戰術，其手段無非是切割 縱向，橫向 和負載均衡。縱向分隔主要是按業務 功能 來分，也就是所謂面向服務架構，橫...
被誇大了的失敗經驗，無非是變相的成功學
誠然，我同意失敗這玩意兒程式設計客棧是個好東西，人不可能不犯錯誤，公司也不可能永遠成功，乙個人在失敗面前的反思，乙個企業從失敗中總結，對個人，企業以及他人的發展都會有不言而喻的意義，然而古往今來，人們往往偏重對成功經驗的吸取，而疏於對失敗教訓的探尋。從這個角度來說，正確對待失敗比正確對待成功更有意義...