基于构件的软件开发模型为我们带来了很大的成功，个人认为其背后的原理是构件中成功的商业价值能够被不断复制，因而带来更大的商业价值。
“复制”不但能够降低开发成本，还能够提高单位产出，提升系统的整体稳定性，降低bug率。
以开发一个App为例，Swiper，ScrollView，Image等等都是常用构件，我们通常以这些构件为基础来实现复杂的商业逻辑，从而产生价值。在这个过程中，我们对实现Swiper和ScrollView的成本几乎为0（当然可能需要一些license费用）。我们的成本主要集中在实现复杂的商业逻辑这一块。
但如果能够将“复制”的范围扩大，例如对复杂的商业逻辑实现进行复制，那么我们的成本会降低，收益会增大，市场竞争力也会变得更强。
可是这“复制”实现起来并不容易，这里包含了技术也包含了管理思想。
从管理的角度，基于构件的开发模型包括5个阶段：
需求分析和定义体系结构设计构件库建立应用开发测试
从技术的角度分析，基于构件的开发模型至少包括3个支持：
构件存储与管理构件测试自动化构件应用自动化
构件库的建立不是一蹴而就的，需要架构师和开发人员的长期合作。
举一个前端开发，微信端H5页面分享的例子。
要实现微信端H5页面的分享，要完成以下步骤：
配置微信的jssdk，注册需要使用的功能页面加载时，调用jssdk的hideOptionMenu页面加载时，注册onMenuShareTimeline，onMenuShareAppMessage点击按钮，打开一个半透明引导层，引导用户点击右上角的"…"，与此同时调用jssdk的showOptionMenu用户点击半透明引导层时，调用jssdk的hideOptionMenu，同时关闭半透明引导层分享回调执行时，调用jssdk的hideOptionMenu，同时关闭半透明引导层
上面这些步骤可以是开发人员的经验，即每做一个具有分享功能的页面，开发人员都要重复上面6个步骤，如果开发人员某一天忘记某个步骤，那么这个分享功能可能就不能正常工作，从而耗费更多的人力去debug。
如果能够将上面6个步骤封装在一个构件中，通过继承让新创建的页面具有分享功能，通过简单的api来实现交互，那就能够达到降低开发成本，提高单位产出，提升系统的整体稳定性的目的。
上面聊了基于构件的软件开发模型的优点，难点和具体实践举例，它能够带来商业上的成功，但从实践上看，它需要基于架构师，开发人员以及其它相关人员的紧密合作。
