在软件开发过程中，大到业务模块的划分，小到技术组件的开发，都属于组件化的思考范畴内。很多时候我们到网上搜索「组件化」关键词，都只会看到关于前端组件化的资料，而对于后台开发组件化的资料却很少，那这是不是代表后台组件化没有意义呢?
后台组件化肯定是有非常大的价值的，对于业务开发人员也有非常大的效率提升。所以本文我将通过自己做组件化的一些经验，谈谈我对后端组件化的一些看法，以及如何进行组件化开发，希望对在一线开发的工程师们有所帮助。
希望通过组件化的方式，能帮助一线工程师们减少对于重复业务代码的编写，提高开发效率，将更多时间和精力放在创新开发上。
如何发现组件化需求?
组件化，顾名思义，其实是通过将重复的业务操作统一起来，对外提供统一的接口，调用方不需要操心内部实现。通过组件化的方式，能统一业务代码规范，减少冗余代码，提高开发效率。
在软件开发的组件化里，要发现需求，你必须深入到具体的业务过程中去，了解整个业务流程。只有这样，你才能知道哪些东西需要优化，哪些东西是重复的。
当我刚刚进入珍爱网的时候，公司开启了精细化运营的需求，很多时候同一个需求对广东地区开放，而对湖南地区不开放。而当需求呈现正向积极效果的时候，需要对更多省份开放。
而这时候如果需要修改开放的测试地区，则需要开发、测试重新参与一次开发，并且走一遍开发流程。不仅仅效率低下，对于开发人员和测试的正常工作也是一种打扰。
针对这种情况，我试探性地开发出了开关服务。只需要再第一次开发的时候预埋上开关，之后如果需要修改测试省份就可以直接在管理后台进行修改，实时生效。
通过这种方式，你会发现原本需要开发和测试参与，耗时将近一天的开发流程。现在只需要产品自己操作，并且只需要几秒钟就能完成，几乎提高了100%的效率。
所以说发现组件化需求的关键，是参与到具体的业务开发中，发现重复的，可统一的业务。
如何开发组件?
当你发现一个可以进行优化的需求后，你下一步需要做的其实就是进行全方位的调研以及设计，从而保证你设计出来的组件能解决问题，并且能为广大需求方所接受。
根据我的经验，我一般将组件分为下面三种：服务、组件、后台管理系统。
服务。这种类型的组件提供一个通用的服务，提供给内部的其他系统调用，从而让其他系统的开发更加快捷。例如之前提到过的开发服务就是这样的。通过服务接口的方式提供出去，调用方能更加方便地使用，并且其中心化的特性也便于后期升级。
组件。这种类型的组件一般是与业务无关的组件，其通过引入 Jar 包的方式提供给其他系统使用。例如我做过的一个 SysCode 组件就是这样的，只需要引入相应 Jar 包，实现特定接口注入数据，就可以调用工具类进行 SysCode 操作。
后台管理系统。这种类型的组件其实就是一个管理后台，你发现客服部门经常用到某个功能，于是你将这个功能做到管理后台里，下次发生同样的问题时，他们就可以自己解决。这也是组件的其中一种。
对于这三种类型的组件，在设计的时候侧重点都略有不同。
服务类型的组件，在设计的时候需要对暴露出去的接口定义非常谨慎，因为接口一旦确定，后期就不能再变化，否则会导致原有使用方调用出错。
而组件类型的，在设计的时候需要考虑的是使用的时候是不是很方便，使用的路径会不会很长。
如何推广组件?
当你把组件做出来后，作为组件的开发者，你肩负着推广组件的作用。
首先，你肯定要让别人知道你为什么做这个组件，做这个组件的背景是什么，用这个组件有什么价值，最后就是怎么用?
而要回答上面所说到的问题，你不可能每个人问你的时候你都从头到尾说一遍，所以你需要针对你的组件写一个文档。我比较推荐的一种做法是写成一个 GitBook，这种呈现方式简单明了，方便阅读。
当你做好 GitBook 文档后，你以为就这样结束了么?
Naive!
这只是一个开始，你需要不断地在日常的开发中去向你的同事推销你的东西，把自己想象成一个热爱工作的销售，把组件当成是你的孩子，见人就说这个东西好，让更多人知道他。
之所以将组件化的推广说得如此艰辛的原因，我相信许多做过组件的人都明白。一开始做的东西别人都不愿意去尝试，因为谁知道你这里面有什么坑呢，我还不如自己弄呢。所以一开始的推广使用注定是很艰辛的，甚至是很苦逼。
所以不要以为做出组件，写完文档就结束了，这其实只是一个开始。
不断迭代!
鲁迅先生说过：好文章不是写出来的，而是改出来的。
在这里我也要说：好组件不是写出来的，而是改出来的。
私以为所有做组件的人，都应该抱有不断迭代的精神去做组件。
因为很多时候你刚刚做出来的东西都是非常简单的，虽然能解决问题，但是对于业务抽象的理解不够深刻，而且会存在多多少少的问题。
这时候你需要在不断推广和反馈中去优化你的组件，让你的组件做得更好。之后再不断地收集反馈，再优化，再反馈。
就这样，也许经过三四个轮回，你对组件的理解就趋于稳定了。
这个时候，你才可以说这个组件做完了!