OSGi 的扯皮

關於扯皮, 請先看這裡:
http://www.infoq.com/cn/news/2010/11/osgi-no-thanks

做了大約半年的 OSGi project 後, 已經逐漸感受到為什麼有人以扯皮來描述他們痛苦了. 確實存在這種情形, 我想可能的幾個原因是:

  • 對 OSGi 機制瞭解不足就開始進行(小弟就是一個例子…Orz…), 時間浪費在 try & error.
  • 工具支援度(如 IDE, build tool等)不足或是本來可以自動化的, 變成需要手動進行.
  • 分工模式(或工作切割模式)未調整. 在享受模組化之前, 其實是需要把 architecture 把 design, dependency 處理好的, 否則 member 之間的工作很容易陷入混亂.

個人認為最關鍵的地方在第三點, 在使用 OSGi 時, 團隊未能改變分工模式, 此時 OSGi 非常可能變成負擔. 模組化的優勢在於每個模組之間的低藕合, 因此工作可以同步進行及調整, 互相影響的情形能有效降低. 若是無法調整, 將會更容易突顯這個問題.

反向思考, 在做足功課之後, 團隊可以借力使力, 逐步調整分工方式, 提昇整體效率, 也能發揮 OSGi 的精神. 這個皮指的就是模組的 interface, 其實不是只有 OSGi 才有扯皮, 許多地方都有, 從 Windows 的 DLL, Java 的 Jar, Web 世界裡的 WebService(SOAP or REST), 不都在扯皮嗎 ?

此外, 自動化 及 Unit Test 蠻有幫助的(畢竟 bundle 其實也是個 jar), 在扯皮過程中, 儘量找到可以自動化的部份, 減輕一些負擔.  最後想提醒的是, OSGi 確實的不好搞, 要用在實戰上最好做足功課, 初期的 schedule buffer 留多一些.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s