1.作為架構,抽像是重要的,但是技術實現更重要,必竟有些效能問題不是光加機器可以解決的.比如松耦合,用佇列最好,但佇列需要資料庫監聽,分布式大量的資料傳輸,大量的序列化和反序列化都是效能瓶頸,非同步需要大量的日誌讀寫,多執行緒自身的損耗,負載勻衡自身的損耗,以訊息機制還會導致資料庫讀寫成倍的增長,而這以前很多資料可以存在頁面上,或記憶體裡.
2.同樣,必須考慮到程式設計師的感受,window服務肯定沒有exe檔案好除錯,remoting肯定沒有wcf好用,新增乙個小功能要寫一大串**,肯定會讓人不滿,比如,加乙個功能,要改介面,加引數類,改配製檔案.環境搭建複雜,又是服務,又是wcf,又是反射.全列隊導致要分析大量日誌,而分布式日誌又寫在不同的伺服器上,無法快速定位問題,無法除錯,環境難配.
3.要考慮到上線的難度,這時,各種集中配置,動態訪問配置檔案,配置檔案的管理,上線是否要掉線等.
4.公司各部門的利益,各個人的利益平衡.就拿我們來說,始終不能比較完美的去做一件事,比如有一種新的架構,從別的部門那裡有現成的**,我認為其實可以利用先進的架構思想,做一套新的適合本部門業務習慣的**框架,可是因為時間,因為人員,就直接把別的部門的**拿過來,用的時候有諸多不適.怕是今後用的人也不多.各種思想不同一,而導致的**差異.想學習的,想做實驗的,想盡快幹完的,想省事的.領導的立場和程式設計師的立場是不一樣的,領導一般要求抽象,因為可以把系統了然於心,把所有邏輯寫在按紐裡,對領導來說,就是個黑盒.程式設計師則希望省時,省事,省心.好改,好調,好上線.
5.複雜的問題簡單化,專業的問題通俗化.而現在則有一種感覺,簡單的問題複雜化,通俗的問題專業化.我覺得不管是什麼公司,一定會有把資料庫**寫在頁面上就能完事的應用.
設計模式沒有優劣,只有適用場景,對於給中小企業做小專案的公司,把sql語句寫在頁面上是最為合適的開發方式.
大資料時代基本觀點
今天晚上我要看大資料時代這一部巨作，我決定用這篇文章來記錄裡面挑逗我神經的話語。1.大資料洞察 社會需要放棄它對因果關係的渴求,而僅需關注相關關係。也就是說只需要知道是什麼,而不需要知道為什麼。這就推翻了自古以來的慣例,而我們做決定和理解現實的最基本方式也將受到挑戰。2 如今,資料已經成為了一種商業...
關於現代OS（作業系統）的四種基本觀點
2 從內部看os 每天我們都在和手機，和平板，和電腦打交道。大部分人都聽到過 作業系統 這幾個字。我們的電子裝置一開機就會進入到作業系統中。那麼，究竟什麼是作業系統呢，我們是怎樣定義作業系統的呢？在現代觀點中，我們主要針對不同的角度與不同的使用者來定義作業系統。我們會從兩個角度來定義作業系統，內部，...
我的觀點 類的設計思路
公共部分 過渡部分 私有部分 如果沒有辦法劃分出明確的區域,則可以使用過渡區來 放置這些東西，如果說將來發現 放錯了地方，可以從過渡區里把它拿走 私有部分應該是各個類自己特殊的 怎麼判斷要構造哪些類，他們應該放在 首先需要明白寫這個類是為了做什麼 為了實現功能 這個功能是業務功能還是基礎設施功能？為...