金庆的专栏

  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  423 随笔 :: 0 文章 :: 454 评论 :: 0 Trackbacks

5. 软工与管理

posted @ 2022-04-24 14:01 金庆 阅读(233) | 评论 (0)  编辑

posted @ 2020-12-31 09:45 金庆 阅读(324) | 评论 (0)  编辑

posted @ 2019-09-20 14:45 金庆 阅读(530) | 评论 (0)  编辑

posted @ 2018-08-30 10:58 金庆 阅读(754) | 评论 (0)  编辑

posted @ 2017-10-26 12:08 金庆 阅读(1462) | 评论 (0)  编辑

posted @ 2017-08-18 18:51 金庆 阅读(514) | 评论 (0)  编辑

posted @ 2017-02-18 22:18 金庆 阅读(515) | 评论 (0)  编辑

posted @ 2016-10-31 17:13 金庆 阅读(471) | 评论 (0)  编辑

posted @ 2016-05-31 11:51 金庆 阅读(728) | 评论 (0)  编辑

posted @ 2015-01-20 12:18 金庆 阅读(1265) | 评论 (0)  编辑

posted @ 2014-12-07 23:11 金庆 阅读(1213) | 评论 (0)  编辑

posted @ 2014-11-04 21:00 金庆 阅读(560) | 评论 (0)  编辑

posted @ 2014-08-17 09:44 金庆 阅读(579) | 评论 (0)  编辑

posted @ 2012-08-15 12:30 金庆 阅读(1987) | 评论 (0)  编辑

posted @ 2012-03-27 13:56 金庆 阅读(7120) | 评论 (0)  编辑

posted @ 2012-03-08 14:17 金庆 阅读(999) | 评论 (0)  编辑

posted @ 2011-10-21 16:27 金庆 阅读(905) | 评论 (0)  编辑

posted @ 2011-10-12 14:33 金庆 阅读(1698) | 评论 (0)  编辑

posted @ 2011-09-19 15:53 金庆 阅读(410) | 评论 (0)  编辑

posted @ 2011-08-08 11:12 金庆 阅读(1642) | 评论 (0)  编辑

     摘要: 对于已经上线的网游服务器,更改代码时要把安全性放在第一位,避免引入错误。
添加某个功能或修正某一个错误时,应该将变更的范围尽量控制在最小范围。
尽量不要造成对其他现有功能的影响。  阅读全文
posted @ 2010-05-19 17:51 金庆 阅读(528) | 评论 (0)  编辑

     摘要: 本文以表格形式总结了 “Exploring the C++ Unit Testing Framework Jungle” ( http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle ) 一文对各种单元测试框架的比较,并添加了原文所还没有加入的Google Test. 并添加了另一项特性比较,即对Mock对象的支持。  阅读全文
posted @ 2010-04-13 10:53 金庆 阅读(1746) | 评论 (1)  编辑

     摘要: 100%代码覆盖率的单元测试并不代表是足够的测试,下面是一个例子:  阅读全文
posted @ 2010-03-09 09:42 金庆 阅读(3840) | 评论 (0)  编辑

     摘要: 保持团队的稳定性说来容易,其实对于每一个优秀的研发经理和公司CEO都非常具有挑战性,尤其是员工很多时候并不能意识到这一点和理解领导层的压力。就好比单身汉不能理解父亲的心情一样。  阅读全文
posted @ 2010-01-20 13:18 金庆 阅读(670) | 评论 (0)  编辑

     摘要: 有个随机数生成函数,按以下分布随机生成1个1-100的整数:90%概率为1-50,10%概率为51-100.
单元测试应该如何进行呢?
生成10000个数然后计算分布比例应该可以,只要在90%上下就算通过。
但是仍有极小可能产生测试失败的可能。
如何做一个具有确定性结论的测试用例?   阅读全文
posted @ 2010-01-09 12:24 金庆 阅读(1191) | 评论 (3)  编辑

     摘要: 看到怪盗KID的文章
( http://hi.baidu.com/kidcdf/blog/item/2cefd85c9d13f449fbf2c09f.html )
最后一句: 没有一个人喜欢看着自己辛辛苦苦做的东西被反复删掉重写.

个人觉得别人更改自己写的代码是我乐意接受的. 不知大家有什么想法?

你愿意别人更改你的代码吗?
A) 代码一旦提交, 就是大家公有的代码, 无所谓谁改谁的代码.
B) 很乐意有人愿意更改自己的代码.
C) 绝不允许别人更改自己的代码.
D) 看到自己的代码被人改了,感到很受打击.

还有其他别的感受吗?  阅读全文
posted @ 2009-11-21 12:55 金庆 阅读(647) | 评论 (2)  编辑

posted @ 2009-08-03 17:35 金庆 阅读(2291) | 评论 (10)  编辑

posted @ 2009-06-18 14:53 金庆 阅读(10865) | 评论 (8)  编辑

posted @ 2009-05-18 18:52 金庆 阅读(684) | 评论 (0)  编辑

     摘要: TortoiseSVN的diff显示中文有些问题, 多数不能完整显示出来. 好像是整个TortoiseSVN对中文字符都有问题, 如blame会崩溃,但是选中"Use test viewer..."用Notepad显示就会正常.  阅读全文
posted @ 2009-02-14 13:30 金庆 阅读(3343) | 评论 (5)  编辑

posted @ 2008-12-27 13:34 金庆 阅读(621) | 评论 (2)  编辑

posted @ 2008-12-10 13:07 金庆 阅读(2205) | 评论 (8)  编辑

     摘要: 有很长一段时间,我常为团队的「笨」感到困扰,我交代的事,常常不能如期完成;许多的事,我经常一讲再讲,但还是有人会犯同样的错,到最后我不得不抓着他们的手,一步一步的追踪,才能勉强完成,我甚至自怨自艾,怎么会找到一群「笨」人呢?直到有一次,我遇到一个知名企业的高级主管  阅读全文
posted @ 2008-09-26 19:32 金庆 阅读(551) | 评论 (1)  编辑

     摘要: VN可以对代码文件中的一些关键词进行自动扩展,最常用的是$Id$关键词,它扩展为文件名,版本号,日期,提交用户,如  阅读全文
posted @ 2008-08-07 08:56 金庆 阅读(598) | 评论 (0)  编辑

     摘要: Source-Navigator是代码阅读工具,功能与Source Insight相同,但它是开源的。  阅读全文
posted @ 2008-07-29 08:35 金庆 阅读(2609) | 评论 (0)  编辑

     摘要: 在设计时发现错误总比在编码编译时发现好。在编码编译时发现错误总比在单元测试中发现好。在单元测试中发现错误总比在调试中发现好。在调试中发现错误总比在系统测试中发现好。在系统测试中发现错误总比让用户发现好。让用户发现错误总比没有用户好。  阅读全文
posted @ 2008-05-08 15:38 金庆 阅读(332) | 评论 (0)  编辑

     摘要: 我个人认为,这种做法对时间和效率太抠门,反而得不偿失。 Scrum Meeting一般不会超过15分钟,本身已经是高效了。为了压缩成5分钟,就取消了面对面交谈的机会,实在是不合算。   阅读全文
posted @ 2007-12-03 10:36 金庆 阅读(957) | 评论 (2)  编辑

     摘要: 软件工程与敏捷抓住了软件开发的不同方面。软件工程的强处在于技术性实践;而敏捷的优势则是社会工程。个人认为:软件工程是心中有招,而敏捷是无招胜有招。  阅读全文
posted @ 2007-11-15 14:09 金庆 阅读(968) | 评论 (1)  编辑

     摘要: 其中我对第4点中的观点不太赞同:“把你的时间花在代码的功能上, 而不是去把现有的代码改得对自己胃口(尤其对于那些copy/paste过来的代码);要找到系统的瓶颈进行优化,而不是对那些无益于系统整体性提高的地方做无用功。”因为最近总计至少有一周多的时间,我正是处理与功能和性能无关的代码更改。添加新功能之前,查看是否有重构的必要,这应该也是高效程序员的习惯之一吧。  阅读全文
posted @ 2007-11-03 10:58 金庆 阅读(1871) | 评论 (6)  编辑

     摘要: 昨天临近下班,边敲代码边调试工作了一整天,大脑已经接近于混乱,所以碰上了灵异事件。因为没法重现,所以无法确定这是不是一个VSS的BUG。  阅读全文
posted @ 2007-10-26 09:39 金庆 阅读(1152) | 评论 (3)  编辑

     摘要: 方法是在架构设计之初,得到一些不同的架构方案,并对各个方案进行先期验证。这是一种排他法。所谓的先期验证其实只能做到先期的讨论,即文中所指的争论。一切都来自于个人经验,根本没有科学的数据,用数据进行比较只能是理想。但使用成熟技术避免风险是对的。如果有实际可行的架构,就直接套用,而不必考虑更先进的创新,避免新技术的风险。  阅读全文
posted @ 2007-10-15 10:42 金庆 阅读(1007) | 评论 (7)  编辑

     摘要: 你是否需要自动化工具。一位开发者从任务板上摘下一张故事卡,把它拿到自己的桌子上——卡片给她带来触感,那种实实在在的拥有的感觉,她亲手把自己的名字写到卡片上,再走回去轻轻地把卡片放到任务板上“进行中”的格子里。或许是绝大多数自动化工具太强大了,而我所需的仅仅是领取任务。只有当异地开发,如现今较流行的虚拟项目管理中,才能显示此类自动化工具的威力。可能最中心的自动化工具是版本控制,如SVN,但使用定期的压缩备份也是一个可行的方案。  阅读全文
posted @ 2007-09-11 10:59 金庆 阅读(890) | 评论 (0)  编辑

     摘要: A case study of Apache peer review 分析了Apache项目的代码检查过程,提出了两种Apache所使用的代码检查流程:并与正式评审(Inspection),结队编程(Pair Programm)的持续检查进行了比较,结果如下:  阅读全文
posted @ 2007-08-02 13:43 金庆 阅读(892) | 评论 (3)  编辑

     摘要: Review这个词意思很明确,就是“再看看”,但是在中国表示看的词太多了,结果“Peer Review”反而不太好翻译。看到一个讨论review翻译的贴子,跟贴很多,可是没有一个精确的。贴子早已关闭,无法回复,我只好把自己认为合适的词发表在此。  阅读全文
posted @ 2007-08-02 10:35 金庆 阅读(2516) | 评论 (8)  编辑