如何看待编写业务代码

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

• 代码要有良好的设计。要抽象和封装，要尽量减少重复代码；
• 代码要有良好的建模，概念清楚，不同实体的关系清晰；
• 代码要高效，有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业务，只要是业务，就还是那套规则：业务的流程和动机，从前端到后端的一套技术体系帮你表达业务需求。万变不离其宗。