神刀安全网

如何看待编写业务代码

原回答见:https://www.zhihu.com/question/269062863/answer/349007152

业务代码的要求和常规意义上的编程有很多不一样的地方。我们在学习编程的时候往往被教导:

  • 代码要有良好的设计。要抽象和封装,要尽量减少重复代码;
  • 代码要有良好的建模,概念清楚,不同实体的关系清晰;
  • 代码要高效,有O(1)的别用O(log n),有O(log n)的不用O(n);
  • ……

但是到了业务上。这些仿佛就变的不那么重要了。

做业务必须要非常了解业务的动机和业务流程细节

比如:你可能要做一个下单支付。你要理解下单支付的细节。账户要怎么设计,支付流程要带那些信息,金额有什么限制,撤单怎么撤,怎么打折/用券,怎么应对第三方支付机构和监管机构……

用P2P业务举例子。P2P是一个撮合贷款人和借款人的平台。那么借款的标怎么来的,怎么根据风险评级的,不同的标怎么打包成理财产品的,期限怎么算,利息怎么算,用户提前解约怎么办,借款人跑路了怎么用备付金顶上,怎么应付国家机构的审计…… 这些都是你必须能够深刻理解的内容。这就好像在编程时你需要知道ArrayList工作一样的。

你可以不是这个业务的设计者,但是你必须清楚这个业务为什么这样转。

如何看待编写业务代码

他喵的怎么回事啊

而这些内容,编程语言,框架,系统是不会教给你的。请好好请教你的主管和产品经理,可以请一顿撸串;如果必要,两顿。

当你大概知道你要干什么后,回过头来看看编程。在业务编程中,编程语言的条条框框其实不要紧,重要的是能让你的业务得到实现和保证的那些东西:

  • 前端界面、布局和交互,让你能给用户看到你的产品
  • HTTP:大概率你的前端和后端会用HTTP通讯,所以你要明白header,body,content-type,cookie……是怎么干活的
  • 安全,包括但不限于注册、登录、认证、授权、密码的管理、相关的运营功能等
  • 业务逻辑:大量的业务流程和规则。就是你说的那些if。
  • ACID事务、隔离性、锁和相关的数据操作
  • ……

有人觉得写业务代码非常low,因为就是一堆if,太没有技术含量了。但我觉得业务逻辑有时比所谓什么高并发,每秒多少多少数据处理要难得多。这是由于很大程度上业务逻辑是人为设计的,复杂的,并且时常严谨逻辑上相互矛盾。同时,业务又是非常灵活的,不确定的,模糊的。这和计算机领域那些确定性的东西截然不同。10多年前好多人还可以认认真真花大把时间做领域模型设计。现在到了互联网时代,今天做的事情明天还继续不继续都不一定。一个业务做几个月没成可能就扔掉换另一个业务了。业务机会转瞬即逝。因此也就没法去做“一套完备的设计,并好好开发测试保证质量”。

如何看待编写业务代码

PM们都是骗人的

在这么难的情况下,能把业务流程拆解为很清晰的组件,并能灵活的组合,还可以表达的很清晰。当发生关键业务事件时(比如监管突然要这样那样,上线的功能出现问题造成了严重的用户损失),可以快速的组织代码在数天甚至数小时内解决问题。这是需要相当强悍的程序设计能力和对业务的深刻理解的。

写业务流程不一定用java。java只是工具,帮你把上面的这些关键的东西串起来。如果可能,js,PHP,ruby,py都是可以的。项目组用什么就跟着用什么就好。

如何看待编写业务代码

最好的语言

对于工具,够用就好,不用太抠一定要满足某个范式,符合某个哲学。你要学会识别你所使用的语言,框架中哪些特性能帮你快速解决问题,哪些其实并没有什么卵用。比如

  • Java从骨子里就是要面向对象,但是业务流程不一定需要面向对象。很多业务就是第一步怎么样,第二步怎么样。这时,弄很复杂的类设计有时并不必要,反而还会带来麻烦。
  • 对于错误处理,Java的规矩是抛异常。但是现实中,和前端交互异常并不好用,还是要定义符合业务要求的报错和处理规范
  • 对于一些排序、筛选、合并一类的算法,可以适当简化,用最容易开发,最不容易出错的方法,而不是理论上复杂度最低,但是极难写对的方法。除非证明真的有必要,再说优化的事情。

我给自己的准则是,业务逻辑是怎样的,业务代码就应该差不多是怎样的。以贴合业务需求为主,以满足软件工程需要为辅。

这样下来,就算之后不再做P2P业务,只要是业务,就还是那套规则:业务的流程和动机,从前端到后端的一套技术体系帮你表达业务需求。万变不离其宗。


如果读过后有所收获,不妨点个赞❤️激励一下大宽宽~

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 如何看待编写业务代码

分享到:更多 ()