起因
其实最近一段时间，就是一直在写前端业务代码，很多人可能觉得前端业务代码，就像是茅坑里的石头又臭又硬，写这种代码并不能获得太多成就感，而更愿意去写那些所谓框架性的代码，更能够从中获得成就感，满足感，这种观点我不做评论。只是想结合我自己最近的经历，谈一谈写前端业务代码遇到的问题。
我认为最常遇到的问题，其实就是各种异常处理了。一个比较规范的产品流，应该由产品经理，设计师，前端开发，后端开发，测试人员这些成员共同完成，产品经理在考虑产品的时候，往往也只是会从最正常的产品使用过程去考虑，设计师在接到产品经理的需求后，设计产品的时候，也往往是按常规操作流去设计产品。举个例子，说一个我自己曾经遇到的产品例子，比如想要实现一个门店自助下单结账的产品，我们通常最先想到的产品使用流程是，
顾客定位门店 =》 扫描商品条码 =》 将商品加入购物车 =》去结算商品，下单 ＝》 支付 ＝》 离开门店
这样一个流程，如果顺利的话，可以很顺畅。但是世事难料。我们也会发现，产品也像人生一样，并非一帆风顺，所以，很可能出现各种各样的情况。比如说，
- 如果顾客定位错了，定位到了其他门店怎么办？
- 如果顾客扫描的商品，没有在线上商品数据库里怎么办
- 如果顾客下单支付失败怎么办？
我这里只是列出来了几种情况，事实上还有很多种情况。 我印象当中，当四年以前，我的同事在考虑这个产品的时候，这些坑，都是实际遇到过的。由于一开始并没有想到会有这些坑，他在写代码的时候，就是有遇到这些坑，本来他是按照一个正常的工作流去做的，后来才考虑到各种异常情况，实际结果就是在处理异常时，花费了很多时间精力。
其实我后来做了很多业务开发，也是总结了一下，一半正常工作流的开发时间往往只占整个开发周期的很小一部分，估计也就是1/3的时间。剩下的大部分时间精力，都是投入到了处理各种异常，或者特殊情况当中。
那么都有那些异常呢
接口异常
当现在越来越多的项目采取前后端分离的工作模式去做的时候，接口异常也就摆在了前端工程师的面前。前端工程师，不要以为接口报错就和自己没有关系，身为前端工程师，当然有责任在接口报错的时候，给用户一个比较清晰的提示。这个时候，又要分情况去考虑。首先，也许我们的前端项目为了省事，或者说为了框架性地处理，会选择在框架内部进行全局性地接口报错异常处理，一个常见的例子，就是只要报错，就给用户弹出弹窗提示，这本身无可厚非。然而，也有很多业务场景，我们并不需要给用户弹出弹窗提示。因此，我们首先需要将弹窗提示禁掉，接下来还需要对这些异常处理做额外的工作。
比如，我们的接口报错，我们根据接口提示，发现数据已经被删除，或者没有权限访问，那么，可以基于此判断，给用户一个404的提示。直接显示在页面当中，而不仅仅是给用户一个弹窗。
我自己前不久，写了一个列表页的业务，左侧侧边栏是一个列表，通过选中列表中的某个项目，可以在右侧查看这个项目的具体详情。这个业务，有点类似于Youtube的订阅列表页面，当我在订阅列表中选中一个Youtuber 的时候，我就可以在右侧看到他最近上传的视频。
这个工作流看起来也并不复杂，但是也会有坑，比如左侧列表接口数据访问失败怎么办，右侧单个项目详情数据访问失败怎么办。Youtube 的效果在我看来有一点不完美，但是其实是让开发简化的，他如果出现左侧列表数据访问失败的情况，左右两边都会出现一个页面加载错误，please reload。我是觉得这样的设计有些啰嗦了，其实一个please reload就足够了。我是后来才发现youtube这样设计的，而我们当时的做法，就是只在右侧出现一个please reload。
理想情况之下，我们是可以根据接口的报错状态码来大概的得出一个结论的。如果是404，我们就直接在界面上提示用户这个资源已经被删除了。如果是403，可能就是没有权限访问。通过这些状态码，可以让我们给用户更清晰的提示，也就能够让用户得到更准确的反馈。
表单提交异常
很多时候，接口并没有异常，但是如果按照某个表单数据提交，后端就一定会报错。这个时候，我们往往会防患于未然。这是由某个表单的特征决定的，这些特征往往包括，对数据数量的限制，对单个数据长度的限制，对可选项必填项的限制等等。举例来说，如果我们有一个项目，要求最多只能有10个人参加，那么当我们选中了10个人之后，就不应该再选中第十一个人了。前端如果已经知道了后端的校验规则，就完全没有必要让错误的表单数据提交上去送死，而应该在前端就进行校验。所以 ，前端的很多工作，就是在处理表单提交的各种异常。我们熟悉了这些异常，不惧怕它，甚至能够运用一些公共组件去更好的应对他，才是取胜之道。
结论
如果能够在思考前端业务开发的时候，就想好可能会遇到的业务上的各种坑，其实是能够避免很多问题的。而这里的坑，其实也就是我上文提到的各种异常情况了。我个人的判断是，在前后端分离的大背景下，接口异常这个错误，是最经常遇到的问题。能够在思考业务的时候，就优先想到这一点，并基于此，推动产品和设计进行完善，其实是很重要的一件事情。事实上，也的确如此，前面已经提到产品经理和设计师往往只会去考虑最普遍的工作流，而很少去考虑各种意外。我们则是需要在这个时候给他们提个醒。这样也能够推动这个产品的进步。