夏天的雨

从Anti CNN说起

SummerRain — Thu, 08 May 2008 23:47:20 +0800

Cafferty的事情让人很生气,看看我们的抗议行为:

网上投票
攻击网站
不让CNN报奥运
政府交涉等

但是CNN的态度并没有给出令人满意的答复.

看看邵亦波的分析文章：从Cafferty在CNN说中国人流氓说起

发现是我们的斗争方法不对：

Cafferty的“恶劣言论伤害了中国人” - 不应该是抗议的重点。恶意伤害在中国儒家文化可能是一件大事情，可是在西方文化里不是。西方文化注重个人自由。我们沟通的重点，应该是歧视。

这也许是文化的差异。

果然CNN状告案取得进展：

纽约华人状告CNN案取得进展律师收到道歉公函

与天奋斗,与地奋斗,与人奋斗

SummerRain — Wed, 30 Apr 2008 21:07:40 +0800

与天奋斗,其乐无穷!

与地奋斗,其乐无穷!

与人奋斗,其乐无穷!

这几句话是毛主席说的,但是总是有人说成这样:

~~与天斗,其乐无穷!~~

~~与地斗,其乐无穷!~~

~~与人斗,其乐无穷!~~

我想起中的含义是大不相同的!不要瞎省略!

专业不是卖弄

SummerRain — Thu, 24 Apr 2008 20:18:16 +0800

今天的赢在中国第三赛季商业实战利郎，这一回合，贺欣浩那一队输了．

一个专业选手（贺欣浩是做广告工作的）被业余选手打败了．

这是个太经典的案例，我们自己也经常犯这样的错误．

写程序有时总想用什么新技术，反而不用心想想能解决什么业务问题，也什么商业价值．
带着思维定势，觉得文档写得漂亮，ppt讲得好才是真专业，反而忽略了解决问题本身．

．．．．．．

时刻牢记此案例吧！

照片管理

SummerRain — Mon, 21 Apr 2008 00:05:22 +0800

需求是在发展的,以前相机的像素很重要,现在这么管理照片让人头痛!

你如果管理你的照片?

1.存放在硬盘中

遇到病毒损坏,自己还有误操作

图片太大,占空间

2.刻录cd

cd读不出来

丢失(我有一张cd包好像被人顺走了,555555)

3.Flickr国外服务

被GFW挡了,好多照片都下不来(我的很多私人照片都在上面呢)

4.Yupoo国内服务

目前暂时用这个,但是担心以后收费,不交钱照片都不让下.或者搬家巨麻烦.

5.打印

太多了,很费钱了.挑一些重要的打出来,还是打出来比较踏实一些.

痛苦和泪水是无法学习的

SummerRain — Fri, 18 Apr 2008 20:50:35 +0800

经历了地狱般的项目后，最近有空再重新审视开发过程，遇到了很多疑惑。比如：

设计到底该写些什么东西?设计到底要做到多详细?

我们对合作伙伴的开发人员没有合同约束的前提下,软件的质量怎么保证?

。。。。。。

于是都找了一些书来看，自己发现<<代码大全2>>这本书的错误都清清楚楚的写着呢!

记得第一次看<<代码大全2>>的时候,是在卓越工作的时候,网上评论说这本书很不错,就找来看看。那个时候还还没有什么工作经验，很好学。看完了基本上没有任何感触，没有学到任何东西。

为什么今天来看觉得这本书真是经典啊！因为你没有经历过苦痛，对他说的话没有一点共鸣。书上说这么多，但是不知道如果不这么做，会有什么后果。毕竟痛苦和泪水是无法学习的，经验是无法复制。

公交一卡通支付

SummerRain — Fri, 11 Apr 2008 13:42:53 +0800

昨天去龙凤成祥买糕点的时候,发现可以通过公交一卡通支付,于是试了一下,是可以用的,但是和想象的有点差距.

使用有点像银联卡,需要上去刷一下,不过不需要输入密码.而不是象公交车上那样,商家输入一个数,你把卡一靠近,嘟的一声就刷掉了.

现在支持这种支付的商家还是少,公交部门不知道能量是否足够大,能否推广到全社会,大家形成一个标准来使用.如果等到那一天,小额支付就方面多了.

驾照年审这些事

SummerRain — Mon, 07 Apr 2008 15:43:00 +0800

我的驾照是2004发的c本,有效期6年,到2010年到期..最近lp听说什么年审的事情,什么不审的话,要过期重考什么的.我也不懂,别重考就麻烦了.如是就查了查:

首都之窗的是这样写的:

机动车驾驶人应当于机动车驾驶证有效期满前九十日到有效期满后一年内，申请换证和审验；

所以,我应该不用着急办这件事情.

顺便赞一下:这个首都之窗还真不错,我办很多事情都是这上面查的,蛮方便的!

总结软件开发过程

SummerRain — Sat, 15 Mar 2008 22:05:11 +0800

MVM在他的blog中谈到如何用正确的方法来写出质量好的软件的75条体会，刚刚做完了一个项目,我也来审查一下吧。

1. 你们的项目组使用源代码管理工具了么？
CVS

2. 你们的项目组使用缺陷管理系统了么？
MQC

3. 你们的测试组还在用Word写测试用例么？
写在MQC中了

4. 你们的项目组有没有建立一个门户网站？
没有

5. 你们的项目组用了你能买到最好的工具么？
不是买的,免费的eclipse

6. 你们的程序员工作在安静的环境里么？
条件有限,但是也不算吵

7. 你们的员工每个人都有一部电话么？
大家都没有电话

8. 你们每个人都知道出了问题应该找谁么？
基本上知道了.有时问题不明确的时候,开发人员不积极去跟踪.

9. 你遇到过有人说”我以为…”么？
要消灭”我以为”。开发人员爱说这么说.

10. 你们的项目组中所有的人都坐在一起么？
需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。

这个项目就是由一个开发人员在公司,我们在现场,出了好多问题.

11. 你们的进度表是否反映最新开发进展情况？
应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

这个项目进度表不准确.太粗了.

12. 你们的工作量是先由每个人自己估算的么？
自己估算。但是开发人员估计得过于宽松,需要施加压力使得他们的工作量饱和.

13. 你们的开发人员从项目一开始就加班么？
要求加班,但是开发人员多半磨洋工,因为开发人员是其他的公司的,我们约束力不够.后来就不加班了进度有点紧张.

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

15. 值得再多花一些时间，从95%做到100%好
值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

16. 登记新缺陷时，是否写清了重现步骤？
有的测试人员写得比较好,看每个人了。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。

17. 写新代码前会把已知缺陷解决么？
没有,不会安排很多时间给他解决以前的老代码,要求他加班解决.缺陷多半是个人不太认真负责引起的.

18. 你们对缺陷的轻重缓急有事先的约定么？
必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

19. 你们对意见不一的缺陷有三国会议么？
没有

20. 所有的缺陷都是由登记的人最后关闭的么？
Bug应该由Opener关闭。Dev不能私自关闭Bug。但是有的缺陷没有提交给测试人员,自己测试了.

21. 你们的程序员厌恶修改老的代码么？
有问题的代码必须要求修改

22. 你们项目组有Team Morale Activity么？
没有,大家基本上不是一个team,几个公司的人在一起,也不统一由我管理。

23. 你们项目组有自己的Logo么？
没有

24. 你们的员工有印有公司Logo的T-Shirt么？
没有

25. 总经理至少每月参加次项目组会议

高层更关心的是项目进度,自己汇报的也比较少,以后要勤汇报.

26. 你们是给每个Dev开一个分支么？
没有

27. 有人长期不Check-In代码么？
没有

28. 在Check-In代码时都填写注释了么？
没有写,其实自己有时都不写,以后要求写.

29. 有没有设定每天Check-In的最后期限？
没有每天,一般一段时间要求check-in

30. 你们能把所有源码一下子编译成安装文件吗？
能,手工编译

31. 你们的项目组做每日编译么？
现在没有做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？
没有。自己曾经整理过一个,但是没有用起来.

33. 设计越简单越好
越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码
千万别什么东西都自己Coding。BizTalk和 Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是”软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么？
想做。但是进度太紧张了,没有做.

36. 你们的项目组每个人都写Daily Report么？
大项目组要求写,但是没有大家基本每天都是xx系统开发。日报有点频繁了,周报比较好.

37. 你们的项目经理会发出Weekly Report么？
没有,沟通不够。

也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

38. 你们项目组是否至少每周全体开会一次？
从来不开会.

一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

39. 你们项目组的会议、讨论都有记录么？
和客户沟通

会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？

大家都还知道
要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：”你们在干嘛”，你回答”ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group
有的人员,notes邮箱都没有装,基本靠飞鸽.

43. 每个人都知道哪里可以找到全部的文档么？
所有的文档以cc上为准

44. 你做决定、做变化时，告诉大家原因了么？
会告诉的

45. Stay agile and expect change
要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员？
要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？
这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么？
应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例？
太麻烦了

50. 你们的程序员能看到测试用例么？
出了问题,他们就看到了。

51. 你们是否随便抓一些人来做易用性测试？
这个问题吃了亏,最后出了问题.有个开发人员开发出来,不觉得难用.

52. 你对自动测试的期望正确么？
别期望太高。依我看，除了性能测试以外，还是暂时先忘掉”自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能”矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？
不能这样。性能测试不能被归到所谓的”系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么？
测试人员也不归我管.很矛盾,希望他们测试,但是也不希望他们提一堆无关的问题,浪费时间.测试人员对业务也不太熟.

55. 你们项目组中有人能说出产品的当前整体质量情况么？
主要是我负责回答

56. 你们有单元测试么？
要求有,但是多半是应付一下.

57. 你们的程序员是写完代码就扔过墙的么？
大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

58. 你们的程序中所有的函数都有输入检查么？
不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

59. 产品有统一的错误处理机制和报错界面么？
要有。

最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么？
要有。但是执行情况看个人,

61. 你们的每个人都了解项目的商业意义么？
不清楚,他们对业务不熟,基本上是写代码.

62. 产品各部分的界面和操作习惯一致么？
要这样。要让用户觉得整个程序好像是一个人写出来的那样。

现在做得不好,几个框架混在一块.

63. 有可以作为宣传亮点的Cool Feature么？
要。这是增强团队凝聚力、信心的。而且，”一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

这个项目缺少一些亮点.

64. 尽可能缩短产品的启动时间
要这样。响应速度客户很关心。

65. 不要过于注重内在品质而忽视了第一眼的外在印象
程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

这个项目中没有时间处理这些事情了,我们总监特别重视这个事情.

66. 你们根据详细产品功能说明书做开发么？
要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

感觉详细产品功能说明书不会写.

67. 开始开发和测试之前每个人都仔细审阅功能设计么？
要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说”你看，当初我就是反对这么设计的，现在吃苦头了吧”

功能设计写得不专业,基本靠问靠说.

68. 所有人都始终想着The Whole Image么？
要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

大家都只关心自己的那一块.

69. Dev工作的划分是单纯纵向或横向的么？
不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个”层”都有一个Owner来Review所有人的设计和代码，保证consistency。

现在的问题是大家不去own这些事情.

70. 你们的程序员写程序设计说明文档么？
很少写

71. 你在招人面试时让他写一段程序么？
从来不

72. 你们有没有技术交流讲座？
从来没有

73. 你们的程序员都能专注于一件事情么？
例如说，一个部门有两个项目和10 个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。

他们基本上是专注一件事情,但是我基本上干好多事情,既要管理,也要写代码.

74. 你们的程序员会夸大完成某项工作所需要的时间么？
会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。

75. 尽量不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。

互联网改变我的购书习惯

SummerRain — Sat, 15 Mar 2008 10:00:13 +0800

以前是到书店买书。常去的有风入松，光合作用等

后来是在网上买书。常去有：卓越网等

再后来是先在网上看连载，然后再在网上买书。比如，圈子圈套、明朝那些事等

体验了一吧海内和校内

SummerRain — Fri, 14 Mar 2008 09:38:00 +0800

早就听说了海内和校内，但是以前好像不让注册，也懒得找邀请。现在开放了,前天很无聊的时候,注册了一吧海内,也注册一吧校内.我看看哪个网站找到的好友多,哪个个网站更好玩.

我都用的真名,上传了真人照片.填写了完整的资料,还发了几篇miniblog,然后通过gtalk,msn搜索好友.结果还是海内找到2个朋友,一个是一起干过项目的,一个是blog认识,实际上没有见过面.校内则一个都没有找到.

我不甘心,又把我那帮干互联网的同事搜索了一遍,还是没有找到好友,失望啊.看来网站的人数还是太少,仅仅局限在web2.0这个圈子里面了.等等看吧,好友少了实在不好玩.大家有兴趣的可以加我:lijuncnATgmail.com