從2012年11月份實習開始，到現在2013年9月已經算是工作將近一年時間了,個人是從工作中學到了不少東西的。剛進公司的時候主要是負責平台服務器開發，后來由於我對前端的一些偏向，所有年后不久就轉到公司前台業務的Web開發。因為我從公司開放平台服務的開發，然后到公司web產品的開發這2個部分都有參與，所以自己對公司的這個架構設計上和業務層面的一些設計也是有了自己比較深刻的感受。其中開發過程中發現公司開發平台設計中，由於一些不合理的設計，造成了公司之后的一些依賴開放平台服務器的項目的開發成本嚴重的增加，並影響了整個開放平台的生態和布局。僅此寫文總結，並無他意，希望對自己之后的工作有幫助。下面讓我細細講解我的一些理解。
- 開放平台的理解
開放平台簡而言之即是一個可提供數據接口的服務器，什么樣的數據就要根據具體的業務了。如今各大公司都有自己相應的開放平台，例如新浪微博的開放平台，百度開放平台等等。開放平台主要是給開發者提供了豐富的數據接口，讓開發者在利用已有的開放平台的基礎上可以輕松的開發出滿足自己業務設計的程序。所有一個開放平台的設計如果不合理會直接導致開發者的開發成本直接翻倍。開放平台本身是為了簡化並降低開發者的開發成本的，如果由於設計的不合理，返回會造成幫倒忙情況。
- 公司的開放平台的現狀
公司開放平台的主要功能是為開發者和公司用戶提供數據支持，其中主要存貯處理的是從遠程硬件設備上面采集過來的傳感器數據，並支持對相應的設備進行遠程控制。當然，平台支持開發者注冊接入自己的傳感器和控制設備的，並提供公司項目和產品的支持。起初，這個平台包含的內容比較少，只是對簡單的傳感器，控制設備進行的管理和數據處理。后來由於公司在開發一些項目時候，由於業務的需求，逐漸抽象了一些新的概念，例如：場景，權限。當時平台團隊為了適應更多的項目，並且為了滿足公司web項目組和手機項目組的接口需求，在沒有慎重考慮的情況下，決定把業務性的東西給設計到了開發平台當中，但是當時只是迎合了當前的項目，對廣泛的需求欠缺了考慮。而后果是可想而知的。下面是平台對外數據支持的一個結構圖：
在平台為了適應項目上的一些需求的同時，由於融入了相應的業務概念后，當為了滿足公司移動端和web產品更多的項目開發需要的時候，平台組不得不為了不斷的需求變動對平台的設計再三的更改，同時也需要提供越來越多的接口。由於平台在業務上過多的設計，導致的一個很明顯的結果就是，發現開放平台總是不能滿足新項目的需求，而平台開發團隊老是要重新的設計和開發。具體后遺症我總結的有下面幾條：
- 開放平台由於不小心融入了過度的業務性設計，開放平台一點都不開放！有強烈的業務定制化性質！
- 平台陷入了重新設計開發的惡性循環，增加了平台團隊后期的開發成本和維護成本
- 開發者發現開放平台並不能滿足自己項目的業務需求
- 公司web項目組每次的開發周期並未得到縮短，反而由於每次項目上的問題，在平台接口上花費了大量的精力
- 開放平台丟失了為開發者提供開放接口的本質
由於整個平台支撐着公司所有產品與項目的運營，同時目標是對外開放，所有由於這些設計上的失誤，對公司的整個產品線的影響是相當大的。個人體會是前期對這種開發平台的設計時一定要慎重考慮，不然后果是相當的麻煩的。