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