三个 bug 引发的思考

雨翔河

首页列表关于

三个 bug 引发的思考

2019-04-08 16:01

> 第一个bug： 登陆模块的扫码登录出现遗漏一段逻辑，和正常的登录不一致导致一小部分用户利用这个漏洞做一些事情。
这个bug隐藏的优点深，是因为这个逻辑涉及到的范围非常小，不是大规模的。

这个bug是清明节放假期间的晚上9点找到的，我翻了很多遍代码发现扫码登录这一块遗漏了一小部分逻辑，
问题的起因是有用户发现登录失败，问题开始上报到客服，客服上报到研发，然后解决问题。
首先可以肯定的一点是用户体验是绝对有问题的，理论上用户在登录失败的时候就应该知道问题出在哪里了，至少用户收到的不应该是失败这种消息
因为当用户收到 失败 这种结果第一想法必然会是你的程序有问题。
再者问题是，这种bug真要去测试的话，是百分百重现的，问题的关键是居然没有产品知道这段逻辑，因为问题爆发的时候并没有传达到产品经理，也没有相应的产品人员作出回应
所以这就直接把问题抛到了开发。
我觉得研发人员作为编码人员应该是解决问题的最后一道防线，如果这种问题大量的直接抛到研发，那可以说明的是第一，逻辑不清晰过于复杂，第二，用户体验极差，第三，产品经理不作为或者不熟悉业务。
这个问题值得思考，一个需求下来是不是做完了就完事了，研发编码完毕，测试通过，产品试用下没问题，生产上线，然后就进入下一个流水线重复开头的动作。
我觉得一个团队一起去做一个应用，研发本身要对业务熟悉，同时产品经理也应该是熟悉业务的，也应该全程跟踪这个过程，体验，后续负责，而不应该是为了做这个需求而做这个需求，做完了就完事了。
如果仅仅是做完了需求就完事了这就太可怕了，铁打的营盘流水的兵，谁还会记得做过什么，有过什么呢？这样做出来的应用没有灵魂，生硬，毫无体验可言。

> 第二个bug：分布式锁的问题

这个是放假前一天的晚上发现的分布式锁的一个问题，在某后台系统的修改配置的接口出现了一段分布式锁的代码，
这段代码是利用redis来实现的分布式锁，但是这把锁有一个很神奇的地方就是，没有给这把锁加上一个超时时间，
这意味着当在拿到锁的时候开始处理逻辑，在处理逻辑的过程中机器如果宕机了，这就会引发死锁。

这种bug要重现也是有点难度的，但是写分布式锁的时候理应该想到这种问题，我觉得这是很基本的。
如果有codeReview机制的话，可能也许可以避免这种问题发生，即使不能避免也可以减少这类事情发生。
这也暴露出了一个问题，技术团队本身的技术上的良莠不齐（这种问题无法避免），对于一些基本功能组件没有做相应的封装提供公共使用，遇到什么问题都是直接造轮子，
导致解决1+1=？的项目代码比老太太的裹脚布还长且臭。
当然我反对过度封装，大道至简，以至于我现在看到项目里对redisTemplate再包装一层的行为很排斥，虽然这并不一定是错的。

> 第三个bug：权限控制问题

a项目本来是一个后台管理系统，但是因为一些原因，开发了b系统来替代a系统。
但是遗憾的是，因为很多原因，b系统的开发完成并没有像当初理想的那样替代a系统，反而导致了a和b同时存在的局面。
a系统是个老项目，它的项目名字和它本身的功能就是雷锋和雷峰塔的关系，以至于新人都会问为啥叫xx名。
回到正题，因为a项目比较老，所以在权限控制这一块做的不够完善，可以说a项目作为一个非常重要的后台管理系统。
它的权限控制可以说形同虚设，只要复制链接或者抓取接口，什么权限都能访问，虽然只有内网才能访问，其实这是一件很恐怖的事情。
这说的只是权限控制，还有比如csrf这种漏洞是否存在也没有真正去看过（我也没去看是否存在这种漏洞，0.0），以前在做一些面向用户的应用的时候是非常注重这个的，感觉这不仅仅是对公司的产品负责或者对用户负责，这也是对自己的负责。

产生这种问题的原因是啥，我们可以细想一下，如果大家都要求高一点，要做就努力做好，节奏慢一点，多想一点，这种问题是否能避免。
现在的情况是来一个人都能搞它（这个项目）一下，没人当它是个东西，久而久之，破罐子破摔，食之无味弃之可惜，甚至有的使用者（提需求的人员）对a系统某功能在哪里都忘却了。

我一直在思考，软件研发和软件工程之间到底应该是个什么关系，在追求效率的同时，你会发现，有时速度快了，做出来的东西差了，甚至连灵魂都没有，就像一具尸体躺在哪里，
对于流水线似的开发我觉得是很恐怖的，并不是说重复做一件事情的恐怖，而是我觉得软件工程本身并不是一件流水线的事，而是一件需要精雕细琢，慢慢打磨的过程，
而软件研发应该是这打磨过程中的技术的体现，一个应用的成长过程，不应该是做完了一个功能就可以不管了做下一个功能，这种事情应该是掌舵者要有一个大的方向，大家为之去鼓足干劲。
不管是研发也好，产品经理也好，测试运维等等也罢，都不应该置身事外，只是守着自己的那一亩三分地来搞。
如果是为了规范化，也不应该把线划的太死，因为水至清则无鱼，在问题来临的时候，如果人人都做到‘不属于我的管辖范围我不管’，那么问题很可能变成一个死结，我经常看历史，抗日战争日本人打中国人，中国人又分北方人和南方人，真要打了北方，南方不管，唇亡齿寒啊，哪来的中国。一个整体在某些时候可以拆分，但是在某些时候他们理应该是一起的。

还有一个想说的就是微服务，其实对于微服务，这里的第二个bug，分布式锁，就是解决多机器部署的时候的一些问题，我们目前的很多微服务并不能称之为微服务，

微服务在我的理解是，小巧，功能规划整齐，最重要的是可以横向扩展！现在我们的应用没有做到小巧，光是启动过程就得一分钟，部署的包大小100m+。

横向扩展更是无处谈起，当你横向扩展一台机器的时候，你需要开通机器的防火墙，安全策略，数据访问权限等等，这些流程走下来，24小时能扩展一台机器就谢天谢地。如真正的流量洪峰来了，我们拿什么来扛？拿离职申请？

总而言之，这些问题都是可以解决的，脚踏实地一点，把起服务的脚本准备好，演练好，这些应该是最实在的吧，邮件能规范化，流程化，它本身没有错，但是邮件本身并不能马上解决生产问题。

###  随笔杂谈，不一定对，年轻气盛，半夜三更，就事论事， 望海涵勿喷，哈。

类型：工作标签：bug,java