今天收到其他开发人员流转给我的一个bug，说实在的，我对bug是很重视的，所以对流转过来的bug我是很敏感的。
这几轮的项目开发，从代码提交测试以来，除了有两个其他人员的bug流转到我这边，又被我转走之外，我还没有收到测试真正提交给我的bug。毕竟我对自己的开发能力和自测水平还是比较自信的，更何况我是边开发边测试，对细节把握的也是比较到位的。我的自信不是源于盲目，而是反复的自测。
而今天收到的这个bug是什么原因引起的呢，是测试错误地理解了产品需求，那么为啥其他同类的需求开发没有收到类似的bug反馈呢。那是因为其他同类需求的开发人员也都跟着错误地理解了需求。只有我一个人正确理解了需求并进行了开发，于是这种多数错，只有我一个人对的情况下，我反倒被认定为有问题的那个人，是不是很搞笑。说真的，我还是第一次遇到这种情况。
感觉好笑之余，这件小事也引起了我的反思。因为我在开发这个需求的时候，也是差一点错误地理解需求。正是事后在自测过程中，我才真正理解了需求。所以我可以肯定说，那些错误理解需求的开发，肯定没有好好自测，更没有仔细对照产品需求文档，要不然这个问题其实也是可以发现的。
在我开发过程中，发现需求有点容易让人误解的时候，我意识到基础组件提供的能力，并不能很好地支持该需求的实现。然而我当时并没有真正认识到所有相关需求都是在使用基础组件提供的这个能力，对于这一点我并没有足够重视，所以我并没有想到要去反推基础组件去改动，而是我自己使用了基础组件更底层的方法去实现了自己针对需求的理解。
而针对需求存在的不合理和容易存在歧义的点，我只是确认自己理解对了，并去进行了开发，并没有针对这一点不合理之处，同产品和开发人员进行沟通。
虽然这背后有时间紧任务重的原因，但对于这一点上的表现，我自我觉得自己的责任心不是非常强，主人翁意识也不到位，自己关注的更多只是自己开发的进度，是自己的一亩三分地。
事后虽然我正确开发了需求，但其他所有开发包括测试都错误地理解了需求，最终导致的结果就是我收到了bug。所以现在再来看，我收到这个bug，也并不亏，因为只要我负责一点，这个bug就可以避免，而且包括组件在内的其他开发人员也都不用做调整。
现在已经到了发布用户验收环节了，所以这个bug提出的时间已经很靠后了。但毕竟bug背后的影响面不小，所以反推着我不得不去和产品沟通，和组件的开发商量，最终就是让产品需求中改正了存在歧义和不合理之处，原本想着赶进度省调的时间，还是没有省调。
