谈谈技术、业务与交接

最近大量交接，有感而发。
学霸级新人满腹经纶，与资深工程师的区别是什么？
做业务是否就荒废了技术，是否技术研究越深入就能创造更大价值？
整天忙于处理手上交接的系统，处理各种bug，是否技术就没有长进了？
作为一名多年业务一线的开发，在我看来除了极少公司和公司内的极少数岗位不需要懂得太多复杂业务外，大部分程序员每天都会和很多的业务逻辑打交道。
程序猿如果不懂业务，会一直被牵着鼻子走，一味的去实现产品的需求，不考虑整体的技术架构和规划，最后写的代码就会是自己和队友的噩梦。
计算机理论知识，语言、算法和各种系统架构知识都是静态知识，他们就在那里，如果想学习他们来满足我们的工作需要，没什么难度，不需要爱因斯坦式的大脑，对于经历高考磨炼的你来说，甚至轻而易举，只要有耐心。
看到业务问题时将其抽象为纯技术问题来思考，再运用理论和技术做出领域建模、系统建模，考虑出系统边界，系统的扩展点和元数据，这其中又包含了模块拆分、复用和代码抽象。这一系列操作，学校里不会教也教不会，因为必须经过多年的实践经验和总结，以及熟练运用才能达到，也许这就是学霸新人和职场老兵的一点区别。大家拼默写排序算法、os原理估计不相上下，甚至会出生牛犊不怕虎，但解决实际业务问题来说，确实需要不断磨练。
语言基础，代码开发，并发编程，竞争条件分析，理论与技术都很成熟，但实际代码中的坑一个接一个，不是不懂技术，而是业务里有些特殊情况没有考虑到。一个简单的db插入操作，一行代码可以搞定，但如果不考虑db异常，以及怎样包装和跑出异常，上层逻辑就无法做回滚或执行其他补救措施，而异常的包装和逻辑的回滚是和业务息息相关的，同样的代码场景，支付转账和礼品发放有天壤之别。再比如一个简单的发放到账操作，不管是什么接口，一个接口调用搞定，甚至99.9%的情况下都没有问题，但如果是RPC调用，就要考虑调用异常的情况，异常又分为发起调用异常、发起调用成功服务端处理异常，发起调用成功服务端成功结果返回异常，处理这种一致性的方案业界有很多种，但具体到业务实现需采取哪一种，需按业务场景分析。
怎样写出高性能的代码，单纯从理论和demo角度，大家都能摸清楚，但是实际业务代码中还是有很多这样那样的低级错误存在，使得性能低下。为什么呢？不是代码和算法不会分析设计，而是当这些算法被用在复杂的业务逻辑中时，很多问题变得不易发觉了。
即使再资深的码农也不敢将自己的代码直接丢到生产环境，因为实际的业务中会出现各种特殊情况，npl，neterror，特殊业务处理等。其实大部分时候写出90%情况下业务逻辑正确的代码只需要10%的开发工期，而90%的时间或精力是为了让业务逻辑在其余10%的意外情况下也是正确的。无论是设计还是代码，如果不考虑那剩余的10%的逻辑正确，就无法产出真正稳定的线上系统。
业务逻辑中的特殊情况有可能是因为请求条件的不同导致的，也有可能和系统的运行环境有关，这些特殊性可以用一堆if else和hardcode来实现，但这样的系统几乎是零扩展性，任何交接到手上的类似系统都如同散发着浓重味道的酱缸，需要捏着鼻子看好久才能理清脉络，而往往这些代码是不敢动的，有时甚至一行代码一个锅。业务逻辑是一个不断抽象迭代的过程，一开始一段代码搞定，但随着需求的变更，开发人员的更迭，代码中不断出现各种ifelse，这就是代码中的坏味道，闻到味的人，可能会去重构一下，但这又依赖于当事人的能力，可能系统会更加清晰了，也可能只是把各种ifelse摆整齐了一些。代码重构是一个业务强相关的活，业务抽象和归纳其实就要做三件事情，一是逻辑流程梳理，二是业务条件抽象，三是扩展点提取。主流程是无状态的，是业务的高级抽象，有时为了满足扩展性，需要将主流程细化，业务条件是一组有状态的值，这组值在不同的组合下可能会产生主流程上的特殊处理（流程细化），而这些可以特殊处理的地方就是扩展点，扩展点通过接口的形式从主流程中抽象出来，按照不同的业务条件实现。比如我最近接触的直播标签项目，逻辑主流程很简单，不同的客户端在拉取直播封面时需要取一个标签显示在封面。但需求是这样子的，标签按业务分多个一级类，每个一级类又分若干二级类，每个二级类的标签都有自己的生成规则，业务方要求pc端 网页端和移动端在拿标签时，一二级分类的优先级不同，标签的生成规则也不同。这里可以抽象出 业务条件是 请求来源，标签一级二级分类这个三元组，然后扩展点就是标签一级二级排序规则，标签内容生成规则，这两个地方需根据业务条件做不同的抽象实现，当然实际的业务场景比这复杂的多，需要考虑版本号、用户信息等一系列条件，以及参数检验等常规流程。类似这样的逻辑如果用这种扩展架构做，所有的代码只用写一遍，而且可以在不影响主流程的情况下满足业务方的需求以及变更。
在不幸遇到交接到手架构不清晰的系统时，入手的第一步肯定是发现修复各种bug，无论是别人报的还是自己发现的，talk is cheap，just do it。修复bug是最好的理清业务逻辑的方式，而且当你很认真的做这件事情的时候，大家都会愿意帮你来理解业务逻辑。第二步就是发现系统中好的开发模式和优秀代码，经过线上考验的代码肯定是有可取之处的。不断总结和积累更多技术技巧和业务处理方式，在重构和开发新业务时你的思路就会越广阔。
不要觉得光做业务似乎和技术无关，其实只有解决实际业务问题的技术才是真正有用的技术，在业务过程中不断提炼各种开发模式和技巧，不断提高开发效率提高系统稳定性是最大的价值。业务和技术从来都是不分开的，我们要做的，就是要看到他们。