跟风。。。
http://ww4.sinaimg.cn/large/3de5d218gw1ehl3gx2cyxj20h10dp75r.jpg

看前半句还以为是介绍你自己的

@beanmoon 那好吧。。。再干净的稿纸也不能让你写出漂亮的文章：P

再贵再牛的钢笔也不能让你写出一手好字。

两个粽子， 每年一样， 妥妥的。

今天陪女朋友去做头发， 坐了一会儿， 想想要不我也剪一下吧，遂洗发。 洗发妹问我“你女朋友烫的是XXX烫吗？”， 我表示没听说过。 过了一会儿， 洗发妹说， “哦， 那你是程序猿吧”。

@akfish 有一种“说出来都是泪啊”的感觉

@griffinqiu 那是怎么做到的， 是有严谨的测试团队吗？

@ivvei 压力测试是也必要的。那单元测试与用户量有毛关系呢： 单个用户的行为往往是很有限的，用户量到一定程度时可以覆盖大部分功能点，这时因没有单元测试或 qa 而被掩盖的问题就会暴露出来。

@hxgdzyuyi 哈哈， good point

@akfish 是这样的，我所希望的情景也正如你所说。 至少在 daily build 完成后自动测试， 很多问题都可以马上发现。 悲伤的是， 由于现行代码中那一点残缺过时的测试代码， 自动编译脚本中不得不加上选项"-x test"忽略测试。

目前产品的可靠情几乎完全是靠需求组的“不完整黑盒测试”保证的。 当然，即使是这么做， 还是有修不完的 bug 的。

@akfish 是的， 流程规范化可以保证最低的标准不被打破。 而强调人个能力的观点更多的应该是怕教条的流程规范限制了开发效率。

@sunus 人是不多，但是时间久。 代码量累积下来， 隐患也会一点一点累积下来吧。

@MasterYoda 以前还有 QA 现在是需求团队直接测了，他们当然是最理解需求的，但是对软件上的测试要点又能知道多少 。

@MasterYoda 写错了， 是2位数； 计算量是有点大，目测不到 100 人用就能把它搞崩掉

不就是蹭个网吗？至于吗？ 在 QoS 设个限速 10KB/s 随便用啊～

另想起大学时的一个笑话：

一同学用 BT 花了几个小时把隔壁寝室的 wifi 破解了， 高兴的啊， 突然看到旁边室友也在用， 惊奇趣问道
“你用的什么网？”
－－“隔壁的”
“那。。。你怎么破解的密码？“
－－”破解？ 我刚才过去问的“
”。。。“