到今年已经工作十一个年头了，把这些年自己出现在自己身上或者同事身上的问题记录下来。

手里有锤子，看神马都是钉子

新人程序员很容易手段目的化，战术战略化。学了一门新技术后，不管具体的技术场景，哪里都想拿出来比划两下。在新手里面很常见，掌握一门技术需要不少时间，导致主观情绪上有明显的偏好倾向，内心自然想急切的用上。
曾经接手的一个业务，梳理业务流程的时候，发现多个业务会用MQ调MQ再调MQ，很困惑为何不用DUBBO这样的RPC。于是在该业务系统的9个工程里找rpc的配置，发现根本没有dubbo的配置。大抵开发同学把MQ当RPC用了。

软件开发没有银弹，任何技术都有其适用的场景。数据库领域很多开发都擅长MySQL，曾经做一个新业务每天要写8000W条记录，如果我当时不做技术选型直接用自己擅长的MySQL，这个系统恐怕只能正常运行几个小时。技术工具的选择要考虑场景，不能因为手里有把锤子，看到啥都是钉子。最近接触了 “道法术器” 的做事思想，某个具体的技术仅仅是器这一层面的内容，想把事情做好还得跳出来思考。不关注工具层的东西容易务虚，但过于迷恋器层面的技术，容易练功走火入魔。纠结于“PHP是最好的技术”就属于这一现象。

代码写好了就够了吗

毕业的第一份工作在京东。大促期间，每天都要人工巡检系统的多个功能点、机器负载、系统异常日志等等。我当时并不理解，我们把代码写好了，考虑了各种边界case，通过了严苛的测试，不就好了吗。读大学的时候，老师们十分强调代码的鲁棒性。后来巡检异常系统日志的时候，发现自己的代码导致的生产问题。如果不是每天的生产巡检，那得等到用户投诉才能意识到问题。自此之后，养成了新功能上线后，定时巡检系统异常的习惯。

测试人员执行的测试用例，只是真实世界的一个子集。我们的代码虽然能通过测试，并不能保证测试用例子集在真实世界全集中的补集里正常work。除了写好代码，还需要良好的巡检、监控意识。

离代码很近，离用户很远

在钉钉审批团队的时候，每周三全组一起解决用户反馈的问题。有些问题需要加用户好友，甚至需要打电话联系用户了解情况。用户提的问题多的时候，需要花上整个下午处理问题。刚去审批团队的时候，对这个例行工作比较抱怨，直到我很得意的一个性能优化导致的一个issue才改变我的观点。
审批团队有8台server是专门处理Excel下载和pdf下载的，每天的下载量并不大，小几十万。8台机器高峰时刻的cpu负载能高到80%，我很不解，为啥这么耗性能。用arthas定位到了问题——每次渲染会加载3个十几MB的字体文件。不改一行代码，就删删了一个字体文件，优化之后，cpu水位下降了34%。于是乎洋洋得意地在内网ATA社区发了篇贴子炫耀，得到了一些技术大佬的点赞。几周后，我接到了用户的一个issue，原本的纸张没法打印全以前的报销单了。我意识到了是我删了一个字体文件导致了样式变化了。用户不会因为我为公司省了一点电感谢我，反而因为功能出了问题，选择用脚投票。
很多工程师往往会沉溺于代码的世界无法自拔，着迷于高性能、技术流的东西，不考虑用户的痛点，往往容易做出反人类的东西。最终的结果是公司流失用户、流失订单。技术要跳出技术的视野，多从用户的角度出发，多解决用户的痛点，让用户的产品使用起来更爽。而不是抱着自认为牛逼的技术孤芳自赏。技术是创造价值的必要条件之一，而非充分条件。脱离用户、脱离业务的技术，注定是空中楼阁。

闭门造车，不学习竞品

曾经负责一个金融业务的SaaS化项目，负责加签验签功能的同事给出的技术方案：前端传来的json串经过spring mvc转成的对象后我们用FastJSON框架json化，然后进行验签。这个方案评审被毙掉了，因为不知道接入方是用什么工具转成json的，调用方和我们的系统json化出来的字符串一旦不一样，就验签失败。我们内部讨论了好几天，想了好几种在JSON化这个方向的方案。有一天我想到，加签验签这种基础的工具，支付宝微信支付应该早就有解决了方案了吧。于是搜索支付宝和微信支付的接口文档，柳暗花明又一村，直接抄作业就行了。
阳光底下无薪事，大公司早就把路走出来了。大公司摸着石头过河，我们摸着大公司过河。学习先行者的经验，能少走很多弯路。

缺乏数据度量意识

做技术优化的任务，是否能带来业务质量的提升？具体能提升多少？能否用数字衡量。阿里西溪园区的一个电梯口贴过一副对联“No data no bb” “You can you up”，言辞戏谑，但是表达出了对数据的态度。
曾经的团队有个系统是负责封装全公司几十个外部供应商的接口，一年有几千万的调用量。这个系统经常出现外部接口调用不通的问题，在大部门公开复盘过几次生产故障。为了解决这个问题，引入了多渠道路由机制，譬如个人三要素验证功能，如果cfca接口失败了，就调公安的接口，再天威的，直到某个接口成功或者全部失败。技术评审的时候，我提出，能不能出一份数据，做完这个技术优化后，能为接口成功率提升多少个百分点，每天能拯救多少个本来会调用失败的case。产品经理同意了我的观点，但是负责这个系统的毕业两年的开发当时质疑：“要花好几天做这功能就为了出一个数据？有啥用”。无奈只好作罢。第一期给少量接口做了多渠道路由功能，上线之后并不如人意，依然是每天好几个告警。我感觉不对劲，根据多次生产环境调用不通的排查经验，断定主要原因是供应商上线先机器未通知我们，或者内部网络策略的问题。于是参考DUBBO failover的思想，借助Spring Retry，把几十个访问外部接口的HTTP调用全部都加上了retry。花了2天时间。这个功能上线后，生产环境外部调用失败告警从每天几次降低到了一周一两次。做完这件事后，团队的产品和这个系统owner依然在大力推动多渠道路由的优化，并且推动上游系统改用多渠道路由功能。多渠道路由的二期、三期一步一步的推进。
团队在错误的路上越走越远，怎么办？对了，打日志，简单的统计多渠道路由功能被使用了多少次，用数据说话！于是在多渠道功能被使用到的时候，我输出了一行日志。上线后，我人肉用关键字搜索这行日志的行数。统计了一个多月，0次！！！我跟这个系统的年轻owner和产品同步了这个数据，至此，投入了3个多人月还要继续投入的多渠道路由功能才戛然而止。
及时用数据反馈自己的优化工作，到底是正优化、负优化还是无用功。如果是负优化或者无用功，就得立刻调转船头了。那么如何评判是负优化或者无用功呢？DATA！用数字指标衡量。语言可以花里胡哨，但死数字不说慌。

悟已往之不谏，知来者之可追，实迷途而未远，觉今是而昨非。技术人的成长就是不断的发现过去的做法不完善，还能改进之。