行业资讯

程序员如何避免写过多的业务逻辑代码

对于"程序员如何避免写过多的业务逻辑代码"这个问题,职场新人时期也感同身受,往往意识到问题时,应该已经花费很多时间,深陷庞大复杂的业务逻辑迭代过程中而苦恼。

没关系,下面我来通过几个方面不论开发语言的通用解决方案帮你答疑解惑,助你抽丝剥茧,化繁为简,优雅的开发、迭代业务逻辑。

我的观点有以下几个方面:

项目前期:三思而后行,做好开发前的“设计”工作

项目中期:严格区分和抽离业务逻辑和通用逻辑

项目中期:解决重复、机械化的工作利器:面向对象、抽象思维

项目后期:善于”发现“工作中"收获"

项目未来:核心业务服务化 项目前期:三思而后行,做好开发前的“设计”工作

编程只是软件的具体实现,软件设计才是重点工作,决定项目的实现方向,前期的系统设计、概要设计、详细设计也能一定程度避免后期开发中的思路不清晰实现方式问题提前预判。在软件工程理论中,前期的需求分析、系统设计、详细设计也是占了很多比重的,实际工作中也是如此,真正按标准化软件开发流程的公司是需要开发人员编写概要设计设计、详细设计文档的。我经历的工作也是如此,设计文档很重要,一方面工作团队能够通过文档讨论可行性实现、是否存在问题和改进及后期的维护交接和需求迭代,另一方面可以帮助开发者整理思路流程,罗列所需资源。

 项目中期:严格抽离业务逻辑和通用逻辑

坚持严格抽离业务逻辑、通用逻辑,可以从是否具有可移植性,不同类型项目是否可以使用来思考。比如,我们需要一个方法是否为金额,那判定是否为金额的方法在本项目中可以用,在其他项目中也可以用。我们就可以抽出为独立的文件、方法。具体的语言实现可能不同,但思路相同。JavaScript语言可以抽离出为方法,Java可以抽离出为通用静态类。当我们严格按照代码逻辑性质区分的思想工作时,你会发现前期的封装,抽离,就是为了后期能够方便调用做铺垫,代码量也减少了,业务也清晰,开发效率得到提高。

业务逻辑代码

 项目中期:解决重复、机械化的工作利器:面向对象、抽象思维

主流的编程开发语言都是支持面向对象,用设计模式把业务抽象能够有效避免重复工作,汇集通用的逻辑。比如,我们想要批量造车,车子又有不同的颜色、外形,如果纯手工一个一个造会花费很大成本,而实际工厂造车,肯定是先设计模型,根据市场需求造出不同类型车子的样板模型,然后再批量根据模型制作。编程开发也是一样,如果按照面向对象的思维去思考问题,基本不会有太多重复劳动,重复的逻辑只需要写一次,其他都是调用。

 项目后期:善于”发现“工作中"收获"

只要努力付出工作肯定会有所得,只是缺少善于发现的眼睛。工作中无论是做什么事,我们都是可以从中有所收获,但需要你善于总结和发现,其实收获不仅仅是物质上的、精神上的,还有经验、做事的经历、方法、心得,只要对你有所帮助,对未来有意义,及时是潜在的提高也是收获。发现问题,改进问题,不正是让我们软件开发人员不断前行的所在,不被外在的评判约束羁绊,善于发现工作中的收获。

业务逻辑代码

 项目未来:核心业务服务化

核心业务”服务化“,让核心业务应用独立运行,方便不同系统调用,用当前热门的概念来说就是SAAS(Software As A Server)软件即服务。打个比方,原先实现判断金额,前端是通过js写方法调用,Java端是通过Java代码实现,其实这个逻辑前端、后端都是需要判断,在以前大家各自写各自的,同样的逻辑,但因为平台不同无法复用。此时就出现了服务化思想,比如我们用Java端的逻辑实现了金额判定,单独我们把这个逻辑的项目抽出为”服务“,通过传参返回响应,标准化的restful服务,这样前端不同的项目可以通过http请求调用。

 总结

总之,通过以上我们系统化、工程化从软件开发生命周期中,认真做好项目前期的软件设计,项目中期的面向对象、抽象思维开发,抽离业务逻辑,项目后期的及时总结,以及对未来核心业务服务化的思考和实践,我们一定可以化繁为简,优雅的开发,有所收获,有所提高。