框架组件开发流程及坑点

开发流程

第一步：找参考
根据需求从头写是方式之一，但说实在，如果有基本靠谱的代码抄，何乐而不为。因此第一步：到github上搜索现成的star多的代码，以做参考。
第二步：开发避坑
坑一：无论如何，写代码时如果有临时测试的代码，请及时标注todo，避免没空检查代码或遗忘。
坑二：轻量原则
各个组件互相间引用太多，绑定太死，会导致维护困难。
坑三：包依赖问题
为了能够少引入包，框架包在引入外部包时，需常用（什么时候使用？）

<scope>provided</scope>

来避免引入过多的包，以至于导致包冲突

坑四：大风险点规避原则
墨菲定律，当有可能发生问题时，就一定会发生问题。
组件的功能设计，必须保证业务端就算功能参数配置错误，也不会发生大问题。

版本管理

组件有个基准版本比如 1.0-SNAPSHOT, 2.0-SNAPSHOT，各个业务应用如果需要改造组件，则从该版本检出分支，发布比如1.0-mes-SNAPSHOT的版本。然后如果某功能发现基本上全部业务部门都会使用，则升级基准版本，如发布1.1-SNAPSHOT，或者如果对旧功能无影响，则覆盖1.0-SNAPSHOT，各个业务部门采用该新版包。

升级管理

除非一个镜像从开发，到测试到上线都没有重新打包，否则生产的仓库最好跟开发的仓库分离。目标：避免坑点，比如uat环境重新编译时，读取了新版的还没经过测试的框架包，则后果是业务工程生产环境错误。因此，需根据不同的开发流程，来制定组件包升级流程。