业务决定思路
- 1 min最近在升级一个一年之前写的广告系统前端部分，除了对一年前自己的思路和代码水平表示骚瑞之外，突然冒出了一个这样的想法 – “业务决定思路，思路决定代码”。
这话看来，绝对是废话一句，“这TMD谁不知道啊！老子写代码不就是为了完成TMD的老板和产品的需求吗？！”。但是呢，“完成需求”和“完成业务”，其实还差得挺远的，尤其是在一些没有产品经理的项目，或者说是产品经理能力不足时（真的不是吐槽产品），很多地方需要程序员自己仔细的剖析整个的业务流程，在任何一个可能出问题的环节，都要做出合适的处理。
说到合适，怎么做才能算是合适呢？这个当然就要说回到这篇文章的主题了，“业务决定思路，思路决定代码”。
站在一些可选择的处理方式很多的环节前，我经常会有一种“站在人生的十字路口”的感觉。往任何一条路走，都不是错误的，但同时，也都不是正确的。说白了就是怎么着都行，但是怎么选择都会有利有弊。所以呢，这个时候，就需要深入到业务中，用自己的逻辑和方法去选择一条适合当前业务的方法去处理。
废话说的太多，来说说我最近在做的这个广告系统的前端部分。
对于广告来说，其实有两点应该是一切决定的依据：
- 不能影响页面的正常功能
- 尽可能多的战士广告
这两点类似于人类社会中的宪法，表明了一项业务(一个政治制度)的根本思路，以后所有的规则都要依据于此。
#####下面来说说细节：
比如有一些广告中，带有css代码，这个时候需要考虑这个css会不会影响到页面其他元素，还有页面上其他的元素的样式，会不会影响到广告位的正常展示。
还有的广告是带有js代码的，这个时候，就要考js出错了的话，会不会影响到页面其他地方的功能。
还有更深入的，广告系统有很多时候，不止是一个异步请求就可以搞定的，可能需要多个请求返回的结果最终生成一个完整的广告。这个时候就要考虑，如果数据出错的话，要怎么处理。
那我手上的这个广告系统为例，一个最最简单地图片广告，需要两个异步请求完成：
- 根据广告位的id和用户id，请求对应的广告数据。
- 根据广告数据，请求对应的广告模板。
这两个异步请求之间，还会包括一些css和js文件的加载。
这个时候，如果在任何一个步骤出错的话，是先让广告显示出来，还是暂时关闭？我的选择是，如果有默认广告的话，则加载一个默认的广告，否则暂时关闭广告位，然后进行再一次的请求。
还有一些更复杂的业务，比如，通过广告位，有时候会推荐一些活动，这些活动，用户可以点击参加按钮进行报名。但是推送出来的活动，有些可能是当前用户已经参加过的，这个时候，在广告位出现之后，还有进行一步验证的请求，如果这个请求出错了，是显示已参加还是未参加？我的选择是将按钮置为未参加状态，当用户点击时，会在进行一步判断。这样可以完成”尽可能多的吸引用户参加”的目的。
除了上面两种之外，还有比如广告位的定时刷新，每隔30s，要刷新一下广告位，但是每一次刷新，并不一定都会取得数据，没有数据的时候，是老老实实的先关闭广告位，还是依然显示当前的广告位，不进行更替，因为业务的目的就是尽可能多的展示广告。
完成了以上这些基本点之后，其实还有很多地方是需要考虑，比如：
- 页面上有很多广告位，为了减少请求，广告请求应该合并。
- 如果广告定时更新的话，那广告的模板应该缓存在本地。
- 所有广告状态的请求，也应该合并成一个。
- 某一个广告位挂掉的话，不应该影响其他广告位的展示。
- 如何能方便的进行调试等等。
#####最后
一个小小的广告位，其实要考虑的事情还是很多的。在着手写代码之前，如果能够仔细的考虑到这每一个环节，在设计整个代码的结构时，就会根据这些需求做出很多优化，减少了后期很多的修改工作量。
作为一个程序员，在很多时候是有非常大的成就感的，尤其是当你根据一个模糊的需求，创造出这样一个完整的”世界”时，有时候闭上眼睛，你会能感到那些请求，数据，程序的每一个环节，就像是一个极简的世界，一切都在有序地运转，即使出了一些错误，也可以在你创造的规则中消解。