初级程序员常见问题

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

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

新人程序员很容易手段目的化，战术战略化。学了一门新技术后，不管具体的技术场景，哪里都想拿出来比划两下。掌握一门技术需要不少时间，导致主观情绪上有明显的偏好倾向，内心自然想急切的用上，人之常情。
曾经接手的一个业务，梳理业务流程的时候，发现多个业务会用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，原本的纸张没法打印全以前的报销单了。我意识到了是我删了一个字体文件导致了报销单表格变宽了。用户不会因为我为公司省了一点电感谢我，反而因为功能出了问题，选择用脚投票。
很多工程师往往会沉溺于技术的世界无法自拔，着迷于高性能、技术流的东西，不考虑用户的痛点，往往容易做出反人类的东西。最终的结果是公司流失用户、流失订单。技术要跳出技术的视野，多从用户的角度出发，多解决用户的痛点，让用户用产品用地更爽。而不是抱着自认为牛逼的技术孤芳自赏。技术是创造价值的必要条件之一，而非充分条件。脱离用户、脱离群众、脱离业务的技术，注定是空中楼阁。
微软有句管理名言：“eat your own dog food!” （吃自家的狗粮）,提高产品在内部员工中的使用比例。产品好不好用，不需要培训，哪里不好用，用一下立马就能感受出来。员工要用自己开发出来的产品，并把不好的点反馈给产品经理，群策群力一起改进。开发人员使用自己开发的产品，才能构建用户视角，收获来自真实世界的反馈。

闭门造车，不学习竞品

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

缺乏数据度量意识

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

缺少业务sense

业务视角不应该是产品的事吗？跟我一程序员有什么关系？程序员不就是把代码写好就行了吗？
缺少业务sense，是否能完全理解产品讲的需求，并还原产品需求本质，做需求的时候能让动作不变形？理解了需求的本质，有的情况下，技术开发同学可以提出更优的解决方案，直达需求本质。

没有全局视角

不了解业务或者技术整体情况，解决问题只能用局部最优解。

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