0
附上其他JOIN的关系图
Posted on
Wednesday, May 14, 2014
by
醉·醉·鱼
and labeled under
sql
其实,SQL里面的JOIN等效于INNER JOIN。不知道为什么我的脑子里面一直记的是LEFT JOIN。
在sqlfiddle上面做个简单测试,一目了然。
http://sqlfiddle.com/#!3/d9ed9/5
在sqlfiddle上面做个简单测试,一目了然。
http://sqlfiddle.com/#!3/d9ed9/5
附上其他JOIN的关系图
0
周四要给team做presentation,topic是关于bug report的。上周五匆匆赶着写完了PPT,自己还小得意了一把。至少,这个算是工作一年来的小心得了。回到正题吧!
Posted on
Wednesday, May 14, 2014
by
醉·醉·鱼
and labeled under
Bug Report
注:请原谅我的散装英语,只是习惯了这样表述,能够更快一些。有时候,连bug的中文都不知道该怎么说。
- 什么是bug?
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.--Wikipedia - 什么是bug report?
关于bug的描述。 - bug report很重要么?
肯定的,必须的。一个好的bug report需要把bug描述的很清楚,能够说出问题所在。此外,bug report是reporter本人的一种体现。你是通过你的bug report和别人打交道的,沟通的,请善待你自己的bug。 - 谁会看bug report?
Project manager, Product manager, Dev manager, QA manager, Dev lead, QA lead, Dev and QA, etc. - 为什么bug summary显得尤为重要呢?
很多人不会将bug一一看完的,他们很希望能够从summary里面拿到足够的信息。所以,一个好的summary,就是好bug的一半了。 - Bug summary需要包含哪些信息?
Where? How? What? 什么地方,做了什么操作,出现了什么问题。 - Bug report需要包含哪里?
环境配置:包括OS,browser version,系统配置。
软件版本:软件版本号,URL
问题描述:对于summary的补充,让dev看到这里就基本上了解90%的信息了。
问题重现步骤:小心你的步骤,因为可能一个新来的dev在修你的bug。
attachment:error log, screenshot, vedio
comments: 必要的信息包括,有没有work around,business impact, further investigation update。
在我的特定环境下,没有必要每个bug都这么严谨,尤其是在开发后期和测试前期。但是,到了产品快要结束的时候,就需要小心了,尽量把bug包括足够的信息,一是自己的体现,二则是免得被人chanllege。至少,对于我来说,我是很讨厌被人发现bug的。