我先提出幾個問題：
第乙個問題：假設你給a客戶加了個功能1，給b客戶加了個功能2，給c客戶加了個功能3。那麼這3個功能要不要合併呢？如果合併到一套系統裡面了，你的這套系統會非常龐大，隨之帶來的不僅是後台選單選項的增多，導致易用性下降。而且整個系統的執行效率就會變差，功能越多，維護起來也越恐怖。
第二個問題： 對於企業建站的公司來說，大部分都是小規模的。所以能不能做到設計製作**的可以不考慮程式，甚至他可以完全不懂程式，只要設計出來，這個**就完成了。一些建站系統追求的就是這種目標，視覺化建站，拖動完成這些都是這類系統的賣點。
第三個問題： 由於企業**的每個客戶的版面都是不一樣的，有些是全站flash的，而有些要特別的加某個功能的，而有些要和第三方系統協調，還有一些是wap**(目前我們還沒碰到這種)，那麼所採用的建站系統能不能適應未來的這種多變的需求呢？對於flash**其實就可以甩掉網上的一些cms了。
現在網上的cms以模板型的居多，模板型就是製作人員做好頁面後，然後通過cms特有的標籤來呼叫資料庫資料從而完成資料的顯示。這種模板型cms的問題是系統提供的標籤能不能滿足實際建站中的需求，比如有些cms在綜合頁中只能呼叫產品分類和新聞分類，而如果要呼叫其它功能，就需要自己修改cms了。還有個不足是與第三方系統的整合，比如有個客戶要加乙個電子報系統，那麼這個電子報系統如何很好的結合就是個問題。優點是這種系統所採用的模板可以很快速的建立乙個**，也可以很快速的進行改版。但是隨著功能的積累，整個系統的選單項會越來越多，易用性肯定就會下降。
對此我提出的解決方案是 框架型系統+外掛程式 的模式
框架型系統指的是原生建站的方式，但是把一些常用的功能都封裝成模組了。製作人員只需要複製貼上一段**就可以完成資料呼叫了。比如客戶想在首頁加個產品分類選單，那麼首先把呼叫產品分類的**封裝到乙個table或div中。然後直接複製過去再修改下樣式就可以了。下次某個地方要用，就再重新複製乙份過去。雖然所有的模組第一次的時候，需要預先寫好。但是後面的幾次使用就可以直接拿來用了。而不用考慮我這段**是做什麼的，只需要改改寬高和顏色這些樣式就行了。而框架型提供的封裝過的函式，可以簡化這些功能模組的開發。而且這些功能模組也不會使整個基礎系統的後台選單變的龐大，只需要按照客戶的要求不斷的加入模組就行了。 對於客戶來說，只有他們自己要用的到的幾個功能選單，這樣易用性就比模板型的那種全部都是沒用到的選單項要來的簡單。
而且框架型另乙個好處是，可以滿足多樣的建站需求，比如對於全站都是flash的**，框架型系統肯定是可以滿足要求的。因為他是原生的開發模式。
那麼外掛程式的作用是 提供一些特殊的功能，這個是用來解決問題一的。比如a客戶要加的功能1，可以做成外掛程式，只在客戶a的系統中使用，如果要用在b客戶中，那麼只需要複製外掛程式過去就可以了。
但是這種解決方案的不足在於不能夠很好的加快建站的速度和快速進行二次改版。但是實際是企業**的頁面必定不會很多的，再加上一些標頭檔案include這種方式，其實做乙個**也不花多少時間的。
本文首發於 關於企業建站系統的總結和思考
關於微型企業建站的想法
目前我國微型企業經過多年的發展，已經成為促進國民經濟增長的重要力量，但是在微型企業的發展中仍然面臨著許多困難，包括資金短缺 融資困難以及在經營管理 市場競爭力方面的不足等。在這樣的大環境下，微型企業除了依靠 的扶持外，還應該提公升自己的競爭力，開闢新的營銷市場 網際網路。許多微型企業主都認為自己企業...
關於cms系統建站的方法
2.我們都知道現在市面上cms框架有很多，比如dedecms 帝國cms phpcms 蘋果cms 極致cms等等，其實我要說的是不管這些cms框架再多，我們只要掌握其中一種，其他自然也就會了，其實不止包括cms系統，當然像現在的fastadmin thinkcmf等等，這些比如做企業 之類的，需要...
關於Spark中RDD的思考和總結
基於spark core 1.2.0 本來這篇想結合自己的經驗討論shuffle，但是shuffle討論之前還是準備先討論一下關於rdd的問題。網上介紹rdd的我看過的有 0 spark 這個是設計時候的 1 2 乙個介紹rdd甚好的ppt，之後我會發在我的雲盤。rdd學名resilient dis...