无脑业务开发入门指南

是的，每个人都讨厌那些自己不喜欢的业务。无聊的分支判断，搞不明白的需求，或者厌恶甲方的无理需求，比如五彩斑斓的黑和基于手机壳改变app主题等。写再多的if和else都不能提高编程能力，带来的只是无尽的痛苦和撕逼，让你再也不想写代码了。

怎么办？

毕竟还是得靠编程做业务吃饭，又不想让自己每天这么糟心，怎么才能站着把这个钱给挣喽？

“代码未动，系分先行”吧。

在**公司做开发的过程中，和我之前实习的工作过程有一项非常不同的地方，就是在开完需求研讨会之后，需要开发者书写系统分析文档，我们一般称为“系分”，最开始我很不理解，觉得多此一举嘛，在开发的过程中就能够在脑中完成系统的分析，或者部分思路也会写在代码的注释里。

哎问题就出在这，如果按照以前那种随意的方式，假如代码发布之后出现了问题，而且是属于业务逻辑或者功能上的问题，比如’老用户在***条件下进入了新服务导致数据不一致’，这个时候怎么办？那就只能去查代码咯，打开整个项目，在万千代码里面找到处理这块的逻辑部分，可能你会发现少写了if做条件判断，然后加上了。这个过程十分繁琐，假如你还是一个不喜欢写注释的coder，那么光凭记忆去寻找代码，低效且不可靠。

所以，“系分”可以闪亮登场了，先讲讲系分是什么，第一次听到“系统分析”四个字，恩，感觉和“软件工程”，“软件体系结构”，“软件架构”这类词属于同类词语：高大上，平时开发用不上，能拿来当（zhuang）谈（bi）资。但是，其实系统分析就是分析我们开发时的逻辑处理部分，比如什么条件下调什么接口，它的回调或者响应是什么，再比如用户有哪些活动，对应的是哪些处理方式等。说白了，就是那些让你需要思考需要画草稿而导致不能够顺畅编码的东西。所以，如果你的系统分析做得好，且你对当前的开发技术栈熟悉，那么编码过程就是无脑搬砖过程嘛，开开心心code，轻轻松松下班。那么，下面就认真说下我对“系分”的认知。

从业务角度来看，系分最重要的是能够帮助开发者更加了解业务。而且业务本身是一个对风险控制要求极高的业务（毕竟涉及到基金和交易），所以容不得程序员的低级错误（比如传参不做类型做判断，页面不做兜底，不判断空指针，忽略了部分的分支处理等）。coder在写系分文档的时候，会尽可能地考虑所有分支情况，并且如果发现业务逻辑上有问题，也会告知（怼）PD，避免了开发到了一半，突然发现业务逻辑有很大的问题，然后推倒重来的问题。同时，如果仍然在发布后出现了问题，也能够通过系分文档查看自己的系分是否忽略了什么地方，查错然后去代码直接更改，毕竟比起直接看代码，看文档还是容易懂很多。

从技术角度来看，系分过程实现了’思考业务逻辑’和’编码过程’的解耦，两者耦合，给程序员带来了很多痛苦，一边想着业务逻辑一边还要想着怎么去实现，不仅精力分散，注意力无法集中，而且可能最后业务逻辑不完善且编码难看（bad smell code）。解耦后，还能专注于代码的规范以及思考更优的方法去实现，既实现了技术的成长也实现了业务的推进。一举两得啊。而且啊，系分也是要排期的，不耽误开发时间的。

说了这么多，简单run一个小demo，假如现在要完成“用户通过手机号和验证码进行登录注册”的前端系分。

1. 统计需要调的后端接口，其传参是什么，会透出什么数据。这里会调登录接口，传参手机号和密码 。获取验证码接口，传参手机号。注册接口，传参手机号和验证码和密码。

2. 画用户的时序图，比如注册用户首先会调后端服务，而后端会去调第三方短信服务等。

3. 画用户的活动图（UML)，发现用户有两个活动，第一个是登录，第二个是注册。

4. 因为前端涉及到不同状态的dom渲染，画流程图或者状态图进行分支判断。

5. 整理前端所需要的数据，观察数据是否还需要裁剪和聚合，定义需要用到的数据类型和字段。

画图不分先后顺序，你觉得合理即可，这些过程的核心目的是要让你无脑编码，能达到这个目的即可，方式不限，上述仅供参考。仍然还想强调一下：要做正确的事，而不是正确的做事。说大一点，战略上的勤奋胜过战术上的勤奋。别傻乎乎的一天盯着自己的那点儿代码。

有一句老话说的好：“系分做得好，编程可无脑”。

话糙理不糙，如果真正想要开发业务的时候还能专注于技术上的优化，就好好儿写系分。如果你感觉写了没啥屁用，那说明你写系分写得糟透了。

下次做业务开发前，不妨试试？走两步？