专注于提高软件质量和开发效率——古路刀客的Blog

关于项目工期的欺骗

gurudk — Wed, 27 Aug 2008 09:17:09 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/233088 发表时间: 2008年08月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

现在做定制软件项目有一种趋势，就是对工期的欺骗。

对方客户上层领导要求工期是12个月，直接负责项目的客户会说你们要在6个月完成，等到公司领导说要4个月，项目经理可能说要3个月。每一层都要剥削一点，一般到真正做项目，没多少时间了。

说的好听一点，是给风险预留一段时间，但每一层都这么做，严重挤压项目时间。一般客户都是有严格的上线时间，这个时间是客户定的，很难去协调，如果你说你完不成，就别来竞标了，一般都是会承诺这不合理的工期。就这样，不合理的工期，导致不合理的项目计划，导致不合理的没日没夜的加班，导致团队士气的降低，导致战斗力的下降，导致离职，频繁的人员流动。更可怕的是，客户对软件项目越来越不放心，导致他下一个项目对风险留了更大的余量，下一个恶性循环开始。。。

我经历了几个这样的项目，1个月的做了1年，8个月的做了三年，其中多是返工的工作量，每个环节做的都不够好，需求没做好，设计没做好，测试没做好，只能靠返工解决。

客户是没法要求他们什么，好说话的还好，不好说话的坚持，你也没办法。但是公司内部如果还是像外面一样的要求，无视项目经理的估算，那就太不合情理了。最可怜的是项目组，被做为鱼肉，任人宰割，没日没夜的加班，身心俱疲。

项目组应对办法也不是没有，就是迭代开发，分阶段交付，一般是一个月，在这个阶段能让客户看到点实实在的东西，他也就放心了。

看看大家的意见，分析一下整体解决方案。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

从软件质量想开去......

gurudk — Fri, 22 Aug 2008 02:34:03 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/231393 发表时间: 2008年08月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

先插播一则广告，我建立一个圈子，讨论软件质量和开发效率，欢迎大家加入。
http://devmgr.group.javaeye.com/

本文想采用头脑风暴的方式，大家一起想影响软件质量的因素，便于我们采用QFD（质量机能展开）方法改进软件质量。
我先首先介绍一些软件的质量特性，就是“XX性”，参考McCall，boehm，iso9126模型，其它自己杜撰的。

.正确性（correctness）
.可靠性（reliability）
.完整性（integrity）
.可用性（usability）
.效率性（efficiecy）
.可维护性（maintainability）
.可扩展性（extensibility）
.可测试性（testablity）
.互操作性（interoperablility）
.灵活性（flexibility）
.可重用性（reuseablility）
.可移植性（portablility）
.明确性（clarity）
.可修改性（modifiablity）
.可恢复性（resilience）
.可理解性（understandablity）
.有效性（validity）
.功能性（functionality）
.普遍性（generality）
.经济性（economy）
.透明性（transparency）
.合理性（rationality）
.可验证性（verificablity）
.可追踪性（traceability）
.简单性（simplicity）
.一致性（consistency）

以下是我的砖头，有些是客观的，有些是主观的，道行尚浅，欢迎继续拍砖：

1）项目管理与计划（☆☆☆☆☆）
.进度计划，估算是否合理，满足合理性；
.是否遗漏，满足完整性；
.细分的任务是否明确，满足明确性和可追踪性；
.是否建立了沟通机制，满足透明性。
.里程碑是否明确，满足明确性和可验证性。
项目计划和管理的不好，会直接影响软件质量。

2）需求分析（☆☆☆☆☆）
.是否描述了所有需求，满足了完整性。
.是否清晰阐述需求，满足明确性。
.是否正确描述需求，满足正确性。
.是否简单明了，不用副词和形容词，满足准确性和可理解性。
.是否容易测试，满足可测试性。
这是影响软件质量最大的因素。

3）设计（☆☆☆☆）
.是否容易理解，满足可读性和可理解性。
.数据库和架构是满足可扩展性。
.数据库是否考虑到性能，满足可扩展性和效率性。
.数据库的范式是否合理，满足合理性。
.架构是否考虑到性能问题，满足可扩展性和效率性。
.架构是否考虑周到，满足完整性。
.架构模块是否划分合理，满足可重用性。
.模块设计是否考虑性能问题，满足效率性。
.界面设计是否容易操作和使用，满足易用性和可用性。
非常重要，会影响软件的性能，可用性。

4) 测试（☆☆☆☆）
.测试用例是够合理覆盖业务流程，满足完整性。
.测试策略是否制定，满足经济性。
确保软件能够履行职责，直接影响软件质量。

5) 编码实现与集成（☆☆☆☆☆）
.编码是否考虑了性能问题，满足对设计的可追踪性；
.编码是否进行测试，满足性能和功能的可验证性，功能的合理性。
.代码是否规范，满足可读性，可理解性和可维护性。
.代码是够满足可扩展性。
.代码意图是够明确，满足明确性。
.代码命名是否合理，满足一致性。
.是够进行单元测试和持续集成，满足效率性，正确性，有效性。
实现好不好，影响功能符合性，修改的可维护性。

6) 技术评审（☆☆☆☆）
.预审质量是够合格，满足充分性。
.评审方式（桌查，轮查，走查，审查）选择是够合理，满足合理性。
.评审人员是够选择合格，满足合理性。
.评审缺陷是否记录，满足可追踪性。
.评审检查表是否合理，满足可验证性。

7) 沟通（☆☆☆☆）
.是够满足及时性，有效性。
.是够满足充分性，确保理解一致。
.需求分析和客户沟通不好，需求就会不明确。
.开发和需求，设计人员沟通不好，就会错误的去实现功能，造成浪费。

8) 培训（☆☆☆）
通过培训，可以使人获取用于工作的技能，从而间接影响软件质量。
.需求分析培训。
.架构设计培训。
.数据库设计培训。
.模块设计培训。
.界面设计培训。
.单元测试培训。

9) 管理（☆☆☆☆）
.配置管理，满足可追踪性，可恢复性，可维护性。
.质量保证，满足可执行性。
.制度，制度合理，人积极性高，间接影响软件质量。
管理得好，效率高，间接影响软件质量。

10)人（☆☆☆☆☆）
.IQ，逻辑思维能力强，能够透彻理解需求，分析条理清楚，直接影响软件质量。
.EQ, 有毅力，自律，勇气，遇到问题不退缩，间接影响软件质量。
.TQ, 是否好好利用时间，提高个人工作效率，间接影响软件质量。
.领导，好的领导可能会影响一批人，能够使团队凝聚在一起，从而直接影响软件质量。
.技术水平高低，对技术的熟悉程度，直接影响软件质量。

11)公司（☆☆☆）
.是否有好的氛围，轻松，有利于发挥个人能力，高效率的工作，直接影响软件质量。
.是否奖罚分明，影响心情，直接影响软件质量。
.是否有重视质量的文化，不用说，直接影响软件质量。
.职责是否清楚，满足明确性，如果一个人什么都做，什么都做不精，职责不清，间接影响软件质量。

12)客户（☆☆☆☆）
.客户信息化程度高，IT素养高，容易沟通，间接影响软件质量。
.客户积极配合，进行阶段软件演示，提交问题，间接影响软件质量，这个非常重要。

13)方法学（☆☆☆）
.采用迭代开发，分阶段交付，增强了反馈，充分沟通。间接影响软件质量。
.方法学选择缺乏指导，会间接影响软件质量。

回帖原则：

如果是新的主题，请继续我的标号，主题尽可能简短，分条阐述和软件质量的关联。
如果是补充，指出原标号和标题，进行补充。

权当一个游戏罢了。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

你是合格的程序员吗?—合格程序员应该具备的12种能力

gurudk — Mon, 11 Aug 2008 17:11:56 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/226672 发表时间: 2008年08月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

毕业四年来，感觉自己也是从一名不合格的程序员一步步走过来的。回头反思一下，合格的程序员有很多标准和要求，下面是我总结的一个合格程序员应该具备的12种能力。中国软件行业的崛起，靠的是合格的程序员。任何华丽的管理制度都不能保证软件项目的成功交付，合格的程序员就是有力的保证，是项目成功的基础。写下这些，是为了给刚刚进入程序员这个职业的新同学们一点参考。我一直以为，当程序员是很辛苦的，如果不是真正的喜欢，很难坚持下去。如果真的不喜欢这个职业，也该尊重这个职业，尊重自己，赶紧改行。

1. 编程语言能力

不用多说，作为合格的程序员，精通一门语言是必须的。这种精通，不是说看了一本《24小时精通XXX》，抄了几个程序就能说精通的,要靠长时间的积累和浸淫。

2.编码能力

我曾经看多很多程序员写的代码，在同一个jsp或者java源文件里，出现了三种以上的对方法的命名方式，有下划线间隔的，有全大写的，有拼音首字母的。就像一个菜市场，杂乱无比，估计10天后，他自己都无法看的懂。遵守编码规范，是一个程序员最基本的要求，可悲的是，很多程序员根本没有意识到这个问题的严重性。随意堆砌网上搜来的代码，根本不管可读性和可维护性，只要能实现功能就行了，心想做完这个项目，就拍拍屁股走人了，缺少最基本的职责素养。我经常把代码必须成程序员的孩子，你就是是孩子他爹，孩子他妈，是有感情的。对你自己的孩子，你能不仔细呵护吗？你是称职的父母吗？这是我编写的一个Java编码规范，供大家参考，这里可以下载http://gurudk.javaeye.com/blog/111734

另外一个就是注释，要注意不是为了注释而注释。对类，以说明职责为主；对方法，以说明意图为主；对方法体，以说明实现思路为主。对于大段大段的代码，要分段，使用空行隔开，并使用行内注释进行说明。

思维的条理性，写代码之前，先简单计划一下，用自然语言把流程写下来，用于整理实现思路。不要看了需求或设计之后，马上就敲代码了，敲完代码马上就debug。花点时间思考，敲代码只是最后一个很简单的工作，不要把自己变成一个代码打字员，编写边想，写了删，删了写。安安静静把实现过程想清楚，在脑子里先实现一遍。再去敲代码，水到渠成。

3.面向对象思维能力

如今，多数编程语言都是面向对象的编程语言。而这些面向对象的编程语言的共同的精髓就是面向对象的思想。掌握这些比面向对象语言本身更重要，比如对继承，多态，重载的理解。对面向对象基本原则的理解，比如开闭原则，接口隔离原则，单一职责原则等。在此基础上，应该掌握常用的设计模式，比如工厂模式，策略模式，观察者模式，模板方法模式，命令模式等等。我面试过很多程序员，没有一个能说得上几句的。

4.利用工具能力

工欲善其事，必先利其器。有了趁手的家伙，工作效率可以提升数倍。你编程序，有没有选择一个很好的IDE，以前听说编程高手都用记事本写程序，我觉得那是一种自虐。就像以前看到的一篇文章，说一帮户外旅行爱好者，出去旅游，背了重重的旅行包，里面装着什么压缩饼干等快速食品。他们宁可就着矿泉水啃压缩饼干，也不肯去1里路都不到的快餐店，农家菜馆吃饭。工具是为目的服务的，好用，提高效率就行，形式无所谓。

另外一个常用的工具就是日记本，好听点可以称为知识管理工具，我用的是myBase，感觉非常好用，在之前，我的所有的片段内容都是记录的单独的文本文件里的，非常不好找，管理也很混乱。

经常上互联网，看到好多好的资料想保存下来，作为日后查看之用.一开始，我用的是firefox自带的书签，但是自己分类太累，多了之后不便于查找，很麻烦。后来用了得乐书签（del.icio.us）的firefox插件，非常方便，现在成为了我必备的一个工具。

还有一个最重要的工具就是搜索引擎了，我装了google for firefox插件，感觉不错，还有英文翻译功能。按照我同事的说法，内事用baidu，外事用google。很多技术资料都是英文的，用google搜索效率高一些。搜索引擎用好了，就等于打开了一扇通向知识宝库的门，使用搜索引擎，关键字选择很重要。

经常去浏览大牛的blog，逐个网站访问很麻烦，去看了又可能没有更新，可以借助于RSS订阅工具，我是用iGoogle桌面工具，每天早上花半个小时扫一下，大牛的最新文章尽收眼底了。

5. 英语能力

新的技术资料都是英文的，英语国家的IT技术走在我们前面至少10年（这是我自己估计的数字，可能正在缩小）。就连印度，一个连基础设施建设都不太完善的国家，因为其英语基础较好，其在软件外包领域的发展也非常迅猛,远远超过了我们。学英语，首先是有信心，其次就是花时间。多阅读英文资料，使用金山词霸，google的firefox插件等工具配合，贵在坚持。

6.学习能力

在IT也混饭吃不容易，整个环境进化的太快，你不学习，就等于落后了。学习要有针对性，别今天学ruby，明天学python，后天php的。首先要认清自己的目标，自己短期目标是什么，1年后，3年后，5年后的目标是什么。结合这些目标，确定自己的学习计划，人的精力毕竟是有限的。当然，多掌握几门编程语言也是好的，可以扩充自己的知识面，重要的是为自己的目标服务。

要想系统的学习一门技术或工具，看书是最好的方法。看完后，然后上网找相关资料，进行深入学习。学习要抓紧一切可以利用的时间，比如电脑启动要花1分多钟，旁边放一本书，可以看上几页了。公交车上，地铁上也可以看。

当然，不能只学习技术，要经常联系自己的软技能，比如沟通能力，表达能力。你可以把自己学到的东西，解释给自己的同事听，既加深了理解，又增进了同事之间的交流。学习的最高境界就是你能够把学到的东西解释给别人听，这才说明你理解了。在学习心理学上，称之为构成主义。

我学一样东西，总是先上网了解有没有相关书籍，如果想学，就买一本或者去图书馆找相关的书来读。我买的书，家里快放不下了(到目前位置，我买了1万多块的书)。我多半是把目录看完，了解这本书讲解的主要内容，然后需要的时候，我就可以立即补充它进入到我的知识结构。每个人可能都有自己的学习方法，意识到学习的重要，并能够根据需要补充自己的知识，这种能力更重要。

7.创造能力

普遍认为，东方人模仿能力很强，但创造能力差。我见过很多这样的程序员，经常说，“这个只能这么解决了，我想不出有什么别的方法。”可能他根本都没想过别的方法，或者懒得去想。对任何一个问题，找出两种以上的解决办法都是非常容易的，简单的google一下，可能就是数十种。悲哀的是，有些程序员经常止步于自己构建的狭小领地之内。对待客户也是这种态度，不是积极的帮助客户解决问题，而是推脱这只是唯一解决方案。

打破这一思维定势的首先的一个办法就是在面临一个问题时，首先想到的是“没有不可能”，或是“一切皆有可能”，前面那个是阿迪的广告语，后面是李宁的。只有这样去想，才能寻找解决问题的别的出路，即使最后我们试了很多种办法，还是只有着一种解决方案，但我们在这种寻找解决方案的过程中，常常会产生很多好的想法，这样才会使我们真正深刻思考一个问题。建议大家看一看《水平思考》这本书，他提供了一些进行创造性思考的方法和工具。

但我认为，坚持认为存在另一种解决方案的信念是第一位的，方法和工具都是其次。

8.文档能力

也许有人会质疑，程序员跟写文档有什么关系。大家开源软件也用过不少，看看Spring，hibernate，Struts等最流行的开源软件的文档就知道，他么的tutorial，他们的getstarted，他们的reference文档写的多么的易懂。其实写代码也相当于写文档，只不过用的是编程语言。同样，写文档，用自然语言，也相当于写程序，简单明了，清晰易懂,这样的“程序”谁看谁舒服。同样，对于想进阶到设计师或者需求分析员角色的程序员，文档能力更是非常重要。

word是一个最实用的工具，很多程序员，多级编号都不会用，索引目录也不知道如何生成，更别灵活应用样式了。很多排版都是所谓的dirty work。垃圾样式一大堆。其实，静下心来，稍微学习一下，就能写出一篇格式漂亮的文档。

9.抽象能力

抽象能力是认识事物从现象到本质的能力。如果你只是停留在“见山是山，见水是水”的层次，客户说什么，你就做什么，设计怎么做，你就怎么实现，从来不过问为什么，也不去想他是满足了用户哪些方面的需求呢。这样可能只解决了表面的问题，可能会引起返工。认识到本质，才能让你的程序具备更大的灵活性和可扩展性。在做企业应用软件开发中，抽象能力体现为对问题域的理解能力，对领域模型的抽象。合理的抽象也是代码重构的前提，每一次重构，都是向更好的抽象迈进了一步。

10.代码评审能力

代码评审和单元测试是保证代码质量的两种常用手段之一。代码评审能力，说明了你的审美标准，知道什么是好的，什么是不好的，什么是优雅的代码，什么是糟糕的代码，你才能让自己做的更好。

11.单元测试能力

没有单元测试的代码，只能说是半成品。因为没有什么能证明你的代码是可以运行的。测试驱动开发是一个非常好的敏捷过程的最佳实践。单元测试还可以作为回归测试，在修改代码时，起到警戒线标志的作用。是否具有单元测试的意识是区分程序员是否合格的重要标准。写不写单元测试是区分平庸程序员和优秀程序员的重要标杆。

12.DRY

DRY是一种原则，就是Don't Repeat Yourself.出自《程序员修炼之道-从小工到专家》。这条原则可以用到很多地方，比如你经常要编译，打包，部署应用程序，供集成测试用。每次你都在重复你自己，写一个自动化脚本（比如用ant，批处理命令）来将这些工作自动化，以提高效率。

还有一个就是我们经常在不同的地方切换IP，如果每次手工做，也非常浪费时间，写一个bat命令可以解决，找一个小工具也可以解决。

编码时，对代码的copy复用也是在重复你自己，虽然拷贝过程很爽，但是维护一致性就要付出巨大的工作量，特别是将来维护的人不是你的时候,使用代码生成工具可以解决这个问题。类似的例子太多了，如果你发现你经常做一些重复的工作，就要警惕了，是否违背了这个原则，想一些办法将他们自动化。

以上我一家之言，其实评判标准很多，希望大家交流指正。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

白话CMMI（一）——CMMI扫盲

gurudk — Thu, 07 Aug 2008 23:53:10 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/225652 发表时间: 2008年08月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

公司在进行过程改进，为了在公司进行宣传，特制作了一个宣传栏，部分内容隐去，内容如下：

• 什么是过程？
过程是活动的集合。软件过程就是关于软件生命周期的一系列活动的集合，一般要经过需求分析、设计、编码、测试等活动。肯德基里的炸鸡腿也是一个过程，包括购买原料、准备、炸制、包装等活动。
• 什么是CMMI？
CMMI代表能力成熟度模型集成，是一个过程改进框架。它对组织的具体过程改进提出了详细的目标要求，对每一个目标又规定了一些具体的实践。CMMI认为好的过程能产生好的结果。
• 为什么要过程改进？
1）规范软件开发过程及其管理。
2）增加企业的国际竞争力。
3）降低软件开发风险。
4）投标时，提供有利凭据。
5）通过明确定义的过程，职责得到了明确，过程中每一个活动都可以通过指南获得帮助。
就像我们自己也会做炸鸡腿，但做得不够规范，有时候好吃，有时候不好吃。开发软件也是一样，有时候成功，有时候不成功。这是因为我们没有遵循一套成熟的过程；过程不稳定，导致结果不一样。过程改进的目的就是为了产生一套规范的过程并能持续改进，以产出稳定的成果，提高软件开发的成功率。当然，我们可以按照自己的想法进行逐步改进，也可以采用成熟的过程改进模型，CMMI就是这样一套模型。

• CMMI3包含的内容？
CMMI过程改进包含了一系列过程改进的主题，称为过程域。CMMI2包含了7个过程域，分别是：需求管理、项目计划、项目监督和控制、供应商协议管理、度量与分析、过程和产品质量保证、配置管理。CMMI3包含了11个过程域，分别是：需求开发、技术方案、产品集成、验证、确认、组织过程中心、组织过程定义、组织培训、集成项目管理、风险管理、决策分析和决议。

• CMMI和敏捷过程是不是相互对立的两种过程途径?
关于两者的争论已经很多了。两者在理念上有某种冲突，也可以整合在一起。CMMI侧重于提出一个管理标准，而敏捷过程侧重于实践方法。两者的结合就是敏捷CMMI，也就是用敏捷过程的方法达到CMMI定义的目标和标准。

• 公司的整体过程目标与改进计划是怎样的？
公司过程改进目标是CMMI3级。整体计划如下：这里插入计划。
 启动阶段（2008年03月11日 — 2008年04月14日）
任务：CMMI模型培训；EPG和QA实践演练；过程比对；建立实施计划。
 第一阶段（2008年04月15日 — 2008年08月21日）
任务：建立和完成过程改进过程；建立评审过程；定义项目计划过程和项目监督过程；定义PPQA过程；定义和完善CM过程；定义需求管理和需求开发过程；定义度量方案；定义设计和实现过程；定义培训过程。同时还包括以上过程的试用。本阶段结束后，要进行一次Class-C评估。
 第二阶段（2008年08月22日 — 2008年12月11日）
任务：定义风险管理过程；定义测试过程；定义SAM过程；定义DAR过程；定义并建立度量数据库；定义裁剪指南和PDP的使用。同时还包括以上过程的试用。本阶段结束后，要进行一次Class-C评估。
 第三阶段（2008年12月12日 — 2009年03月19日）
任务：过程全面试用；过程文档修订；过程部署发布。
 评估阶段（2009年03月20日 — 2009年04月10日）
任务：准备评估资料，进行正式Class-A评估。
• 过程改进覆盖范围？

• 如何参与到过程改进活动中来？
1）提建议：过程改进是整个公司的事情，和每位员工息息相关，欢迎大家以邮件、MSN、QQ、公司OA讨论版、面对面交流或其他任何方式给我们工作组提供建议。
2）样本项目：可以参与过程实施的样本项目，试用已经制定好的过程，并提供反馈意见。
3）参与过程规范的制定和编写：对过程改进有兴趣的同事，可以随时和我们工作组取得联系，参与到过程规范制定活动中来，亲自参与制定过程规范、模板以及指南的编写。

• 过程改进组织架构及职责
领导小组成员
EPG组成员
QA组成员
领导小组职责：负责整体协调，确定过程改进的整体方针、政策以及目标。
EPG组职责：负责制定过程规范、模板和指南，对项目组进行过程培训等。QA组职责：负责监督和推广过程规范的执行。
EPG组按照改进内容不同又分成五个小组，具体分工如下：
1）项目过程小组
2）需求过程小组
3）设计实现小组
4）组织改进小组
5）验证确认小组

• 过程改进状态图
过程改进状态图是围绕18个过程域以及一个通用目标（GG），三个特定目标（SG）的过程比对图。

说明：这样图反映了当前过程改进的状态。

SG : Speicial Goal, 代表过程域要实现的特定目标。
GG : General Goal, 代表CMMI3级的一般目标，也包含了二级的通用目标。
过程域缩写说明：
REQM 需求管理
PI 产品集成
PP 项目计划
VER 验证
PMC 项目监督和控制
VAL 确认
SAM 供应商协议管理
OPF 组织过程焦点
MA 度量分析
OPD 组织过程定义
PPQA 过程与产品质量保证
OT 组织培训
CM 配置管理
DAR 决策与分析
RD 需求开发
RSKM 风险管理
TS 技术解决方案
IPM 集成项目管理

• 过程改进动态
近期进展，以周为单位。
• 通知栏
近期召开会议、讨论等。
• 过程改进工作组宣传区
介绍过程改进工作组近期动态，每个组一个区域，包括规范编写情况，指南模板编写情况，过程域的试用推广等。
• 过程改进项目代号是什么？
过程改进的项目代号为rhino，本意为犀牛，俚语代表金钱。寓意像牛角一样锋利，刺破障碍，直接触地，产生实际效益。我们过程改进的风格也是这样，每个工作组都要坚持这个原则。
• 过程改进的口号？
人人参与，天天改进。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

随想，关于办公环境

gurudk — Thu, 07 Aug 2008 14:40:33 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/225479 发表时间: 2008年08月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

很多公司，比如google，微软，百度，淘宝这些公司都有自己特色的企业文化，感觉他们的工作环境是把生活和工作合为一体了，感觉舒适，自然。办公环境和企业文化相关，我们公司就是一个白开水公司，按时上班，按时下班，甚至连一个乒乓球桌都没有，更别提随意喝的饮料，咖啡，台球，健身房。。。，唉，这种环境，自然而然的感觉压抑。营造更自然的环境，其实更能提高效率。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

apche静态页面乱码问题解决

gurudk — Sat, 19 Jul 2008 15:30:40 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/216507 发表时间: 2008年07月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

居然一下两种设置是不一样的：
AddDefaultCharset GB2312
AddDefaultCharset gb2312

页面里是gb，小写，本来设置大写，就乱码，得刷新一次。
改成小写，问题解决。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

重用管理和技术研究在软件公司的重要性

gurudk — Wed, 30 Jan 2008 10:40:13 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/160274 发表时间: 2008年01月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

先说说我们公司的概况，主要是以一个行业的项目型企业应用为主，有一个技术框架但不完善。

我想听听大家所在公司的情况，就是你们公司有专门研究技术的人员和部门吗？这些人不参与项目的开发，而是开发技术框架，为开发人员提供技术支持和培训，对公司的技术资源进行积累，形成公司技术资源库。如果不设立专门的人员，而是在项目中积累，就没有统一性，开发人员在项目中受进度等项目指标的影响，他们的目的是完成项目，和形成技术积累目标是不一致的。

我认为软件公司提高开发效率，是应该要有一个这样的组织或部门来进行这样的工作，但实际上很多公司不够重视，结果因为技术支持不够，公司平台和框架不完善，开发效率非常低，以往技术资源的重用也不理想。公司领导对这块不是很重视，认为技术是次要的，项目是主要的。不把技术研究，通用技术平台建设以及资源库当作公司重要的任务来看待。直接的结果是，技术人员参差不齐，工作成果依赖实际技术人员的水平和学习能力，没有公司级的技术支撑。

我认为，在软件公司中，一个人的工作能力体现为四个方面：
第一知识。拥有了知识，才有了解决问题的前提，知识面广，解决问题的思路就更宽阔。
第二工具。熟练运用工具才能提高工作效率。用的好可能比用的不好工作效率高几倍以上。
第三技能。比如精通Spring框架，技能直接体现在工作的效率上，是一个综合的体现。
第四制品。这里就是指工作成果，程序员的制品就是写出高质量的代码，需求分析人员就是写出一篇完善的需求分析文档。

对于现在的企业应用，特别是开发Java应用，经常需要借用多个成熟的框架来完成，学习成本可以说非常的高。对于一个能够胜任工作的员工，应该有统一的获取这些知识，技能的途径。单纯通过自学积累是很难获得的，而且学习效率也非常低。
对于一个软件企业，如果想长期发展，我认为下面这些东西都是必须的：
1. 技术平台。公司统一的技术平台，为开发项目和产品提供支持。
2. 资源库。积累特性领域模型和业务知识。
3. 研究中心。负责技术平台的开发，资源库的建设和维护。应该做为一个单独的组织。
同时负责组织和实施新技术的研究，并转化为公司积累。另外就是组织培训，
培训工具和开发技能，提高开发人员效率

目前我们公司的实际情况是，所有人都在参与在项目中，没有人负责技术研究和积累工作，技术框架也不够完善，也没有时间完善。我是技术总监，但人员都在项目中，所有这些事情不是我一个人能完成的，况且我自己也有一些琐碎的管理工作，根本没有精力实施上述计划。
请大家发表一下看法，不知道我问题有没有描述清楚。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

衣带渐窄终不悔，为伊乐得人陶醉

gurudk — Tue, 21 Aug 2007 21:34:31 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/114987 发表时间: 2007年08月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

软件开发有无穷魅力阿！虽然辛苦点，至少到现在，还乐在其中!
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Java编码规范及实践

gurudk — Mon, 13 Aug 2007 15:33:44 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/111734 发表时间: 2007年08月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近，公司需要制定java方面的编码规范，我参考了网上的资料，同时增加了代码最佳实践，包括常用的10几个设计模式快速参考等。附件是这个《Java编码规范及实践》的pdf版本，供大家参考。

下面是目录：

第1章    概述    3
1.1    前言    3
1.2    术语    3
1.3    约束    4
第2章    一般规则    4
第3章    格式规范    4
第4章    命名规范    15
4.1    一般命名规范    15
4.2    特殊命名规范    18
第5章    注释规范    21
5.1    概述    21
5.2    一般原则    21
5.3    注释内容    22
第6章    编程实践    25
第7章    设计模式快速参考    27
7.1    工厂模式    27
7.1.1    简单工厂    27
7.1.2    工厂方法    27
7.2    单例模式    28
7.3    适配器模式    29
7.4    组合模式    30
7.5    外观模式    31
7.6    代理模式    32
7.7    命令模式    33
7.8    观察者模式    34
7.9    策略模式    36
7.10    模版方法模式    37
7.11    参观者模式    39
第8章    单元测试    42
8.1    为什么要单元测试    42
8.2    单元测试工具    42
第9章    代码重构    42
9.1    长方法    42
9.2    巨大类    42
第10章    工具支持    42
10.1    eclipse 配置    42
10.2    使用方式    43
第11章    参考资料    45
第12章    致谢    45
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

我是如何来装备我的firefox的-常用extension推荐

gurudk — Mon, 13 Aug 2007 14:33:37 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/111720 发表时间: 2007年08月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我的firefox配置截图：

sourcelive.cn/firefox/myfirefoxweapons.jpg

1) Google工具条扩展 Google Toolbar for firefox 3.0
   搜索条，英文翻译，pagerank...
   安装地址：www.google.com/tools/firefox/toolbar/FT3/intl/en/
2) 得乐书签扩展 del.icio.us Bookmarks
   方便的添加tag，发现好的网页，tag一下即可,那可是相当的方便啊
安装地址：addons.mozilla.org/en-US/firefox/addon/3615
3) TabMix plus 多标签扩展
   灵活的标签浏览，配置非常丰富，从开始用firefox我就用它了
安装地址：addons.mozilla.org/en-US/firefox/addon/1122
4) cooliris
我主要用于页面浏览，可以不打开新窗口浏览链接的页面信息
安装地址：addons.mozilla.org/en-US/firefox/addon/2207
5) Download StatusBar
下载文件状态指示器
安装地址：addons.mozilla.org/en-US/firefox/addon/26
6) 天气预报
   forcastfox
安装地址：addons.mozilla.org/en-US/firefox/addon/398
7) tab catalog
   像powerpoint多页浏览一样浏览多页面窗口，初次看到，感觉很酷
安装地址：addons.mozilla.org/en-US/firefox/addon/1937
8) firebug
   适用于web开发人员的扩展,用的不多
安装地址：addons.mozilla.org/en-US/firefox/addon/1843

希望和大家一起享受firefox！

更多截图：

得乐书签：

iGoogle, 订阅了n多的RSS

tab catalog，酷就一个字

tab mix plus

cooliris

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

请大家推荐需求管理工具

gurudk — Fri, 10 Aug 2007 14:40:33 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/110872 发表时间: 2007年08月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

有没有开源的需求管理工具，我google了，也在sf上找了，没看到特别适合的。
就是为了给大家一个公开的视图，可以进行产品特性的追踪，可以评论，可以进行度量管理。
我感觉在jira上做二次开发不错，增加一些需求管理属性，不知道有没有人这么干过.
最终目的就是为项目，产品或产品线，公司积累领域方面的知识，每一个产品特性都可以追踪。
有人说用excel就行了，我觉得这个可以完成记录，但追踪，分享，互动都满足不了要求，就像
我也可以用excel记录bug，但使用jira肯定效率更高。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

中国队，I服了U

gurudk — Thu, 19 Jul 2007 12:23:38 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/102752 发表时间: 2007年07月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

总结一下，我的感觉：

1）球员没有精神，三个丢球都是定位球，丢的有点小学生阿，注意力怎么会这么不集中，想回家抱老婆，养二奶呢吧
2）战术素养不高，传接球太滥，基础差，感觉一盘散沙，而不是一支球队，尤其是中场。
3）教练平庸，朱导临场指挥能力不行，老是45度起球，效果太差，就韩鹏一个人，争顶没一点优势，况且传中还总是歪。
4）中国猪协，只注重短期利益，不重视中国足球环境大环境的培养，急功近利，我们买体育彩票的钱都哪去了

这里面2）是中国队历来的顽疾，1）是因为爱国意识不够，敬业精神不够，最基本的盯人怎么能出这么大漏洞。3）就不说了，中国队的问题不是靠一个教练能解决的，而是需要一大批素质高的基层教练，从小球员就该养成良好的战术素养，足球不是11个人的运动，而是一个团队。再就是劣习，要不是红牌，不会这么多主要球员缺席，难道你就没脑子控制一下，以球队利益为主吗？这些都是从小养成的习惯了。

又一个轮回，一个从希望到极度失望的轮回，一个保平就出线的轮回，一个发誓永远不看而又忍不住要看的轮回。
中国队，你什么时候让中国球迷有点骨气，有点面子，有点骄傲，有点理由去看你们的比赛。

中国队，I服了U！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

论双赢的普遍存在

gurudk — Thu, 05 Apr 2007 20:23:26 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/68382 发表时间: 2007年04月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

      我想说明的是，日常生活中，个体之间的合作双赢永远都是普遍存在的，无论是人还是公司。

        请看上图，可做如下分析:

        简要说明： A, B 分别为个体A和个体B的基点，可以看作是出发点，所有决策都会围绕它做出，穿过AB的两条线是他们的利益线。假设A和B决策的变动均围绕基点进行变动。两条线的交点C我们可以认为它是双赢点。
        1) 假设个体A的利益线确定，那么个体B的决策利益线个数为n， n条决策线中，唯一一条不和A相交的线是过B并和个体A利益线平行的线，则在个体A利益线确定的情况下，个体B和A相交的概率为(n-1)/n, n趋于无穷大（因为围绕点B的直线有无数条），所以上式的极限为1, 即双赢点是普遍存在的。
        2) 我们再来看点有意思的事。记 Cost 表示双方合作所付出的代价 , 可令Cost = |AC| + |BC| >= |AB|。双方合作的最小代价为
个体A的基点A到个体B的基点B之间的距离。也就是说，要想比较容易的达到双赢，双发的基点应该很近，也可以理解为有较好的合作基础。
         无论怎么说，双赢总是普遍存在的。无非代价大还是小的问题。所以在日常生活中，处理企业，商业利益的时候，如果大家足够耐心，是一定会达成双赢的。生活中总是能找到这样或那样的契合点，事情经常这样就完美解决了，我相信双赢的普遍存在。
         在这里，我只是把熟知的东西用数学元素表示出来，感觉它是那么美。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

分享一个PL-SQL使用小技巧

gurudk — Wed, 04 Apr 2007 19:17:42 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/68042 发表时间: 2007年04月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

对查询结果进行更新，可以直接在查询语句后加 for update, 如红字所示
select * from journalarticle t where t.groupid = 15 for update
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

像外行一样思考，像专家一样实践

gurudk — Sun, 25 Mar 2007 23:46:28 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/65422 发表时间: 2007年03月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

         在去杭州出差的车上，我把这本书看完了，作者金出武雄是一位卡内基梅隆大学的日本籍教授，曾是
机器人研究所的所长。我真的为作者的朴实，真诚的语言所打动，回想自己上研究生时的科研经历，可以说
非常失败，感觉等到毕了业，才入了科研的门。
         下面是读完时候，和作者的一些共鸣：
         1) 海阔天空的构想。思维不要受羁绊，好的构想来自于荒唐无稽的想法。
         2) 一些重大的想法，一开始不免天真，但结合知识技术就能产生伟大的成果，重要的是要深入，像专家一样去实践验证。
         3) 某些已经存在的，成功了的方法，经验和知识是导致想象力匮乏、缺少经验的主要元素。
         4) 简单，省略，抽象化。越简单化、抽象化就会产生越绝妙、鲜明的理论。做软件不也是一样吗？同样能感受抽象所带来的美，简单带来的朴实无华，更能反映问题域的本质。省略的重要：在软件开发中，高层概念模型就是这样一种省略，它抓住的本质概念，带来了问题域的精髓。
         5) 用情景推动研究进展。软件领域中，用例，用户故事都是起到同样的作用，但没有什么比一个真实的情景更能反映用户与系统的交互，比那些生硬的活动图和白开水般的文字描述要好多了。
         6) 构想力是限定问题的能力。教授说的是定义问题的能力，在软件开发中，我感觉是识别关键问题的能力，在业务逻辑比较复杂时，识别关键问题和抽象是非常重要的，有时候我认为这确实需要一些天分。另外，解决问题时，识别自己陷入死胡同也非常重要，这时候，退一步，换换思路，常能海阔天空，迎刃而解，相信大家也有过这样的感触。当技术人员，我认为尽量少下肯定结论，应该i多多尝试，不要总是说“这样做肯定不行！”。
         7) KISS方法(Keep It Simple, Stupid) 这可是敏捷的核心价值观。这点，做研究和做软件不谋而合。
         8) 智慧体力-所谓的集中力，让自己成为问题本身。我自己是有这个亲身经历的，当我想一个问题时，几乎所有脑子都在转，
优良的架构和优美的代码很多时候都是这样出来的。
         9) 越能干的人，越迷茫。要想成功，必定迷茫。没有具体目标的科学研究注定一事无成，有了目标自然就会倾注全部精力。
这里我在写程序时也有同感，当面对一个无从下手的问题时，你的问题就变成了确定问题域中一个待解决的子问题。一定要确定，否则无从下手。这时候，我的一个做法是，找一个安静的环境（有时候在厕所），静静思考15分钟，然后在纸上写出所有子任务，有时候会写一些伪代码。确定了子问题后，编程就变得相对简单了。
        10) 从“做不到”重新开始。挑战不可能是所有技术人员的乐趣。有时候，它是所有好想法的起点。"当科学工作者说不可能的时候，他很可能错了"..
         11) 想法是要和别人交流沟通的，这样才能触发新的灵感，并且要练习如何提取概要以便让别人了解自己的意思。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

从咨询师这个行当说起

gurudk — Sun, 25 Mar 2007 22:50:23 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/65416 发表时间: 2007年03月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

         前几天上班做公交，突然想起来一个咨询师的恰当定义：
         咨询师：比技术专家知道的面要广，比普通技术人员了解的要深。
         想想自己也是这样的人，各个方面接触的领域很广，但大多是一知半解，没有深入，遇到一些技术初学者，
可以口若悬河，滔滔江水，连绵不绝，引起一片敬仰的目光，可自己心里却挺心虚。对技术专家（一般精通某项
领域），也能讲的头头是道，什么ruby了，敏捷了，测试驱动了，持续集成了，面向对象的六大原则了，架构了，
这个框架怎么怎么了，那个框架怎么怎么了，五花八门一侃就给整晕了，人家还挺谦虚，“你怎么知道这么多阿，
以后向您学习了”。可自己确一个完整的Web应用都没写过，惭愧啊，还是一个技术总监呢，哈哈。要学的东西
太多了，我大多像高手切磋武艺一样，点到为止，每样都学一点，但精通的不多。感觉学的越多，越强烈的感觉
就是软件成功和失败，技术都不是最主要的问题，在中国，和客户捣浆糊和扯皮才是最主要的，捣不好，扯不好
你的项目十有八九就要失败了。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

项目失败鱼骨图

gurudk — Sun, 25 Mar 2007 22:30:00 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/65411 发表时间: 2007年03月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天老婆生病了，陪老婆打点滴，闲来无事，总结了一下自己做过比较失败的软件项目的失败原因，画了一张鱼骨图，供大家参考，希望能产生共鸣。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

牛人是不是都是寂寞的？沟通的重要性

gurudk — Mon, 19 Mar 2007 14:43:24 +0800

作者: gurudk 链接：http://gurudk.javaeye.com/blog/60964 发表时间: 2007年03月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

       想想爱因斯坦，伽利略，布鲁诺等大科学家。他们的思想不是很容易被常人理解的。
我想能够和他们沟通的人也非常少，所以他们应该非常寂寞。
        面向对象的大师们，Kent Beck, Eric gamma, Martin fowler等人中， Martin技术不见得比前两个人高，
但是Martin fowler经常能把复杂的问题和思想解释的非常明白，这也是我觉得他比其他两个人更有名
的原因之一。解释的清楚了，沟通的人多了，也就不寂寞了。思路也开阔了，真是一个良性循环。
        做了几年开发，感觉沟通真的太重要了， XP也是强调沟通的价值。看看开发管理中的问题
很多都是沟通的问题，比如高级程序员不理解初级程序员分配的任务总是完不成。其实可能是高级程序员
不了解初级程序员的真正困难，或者没有把要实现的逻辑和思路讲解清楚，也可能是初级程序员碍于面子
有不懂的问题也不想问。真正的问题是沟通问题，我认为，高级程序员应该把问题讲到明白为止，初级程
序员应该把问题问到没为止，这样障碍才能去除，项目才能得以顺利进展。
       我一直想把最先进的软件开发思想向整个公司做一普及，比如测试驱动，比如重构，比如设计模式，比如
面向对象设计的原则，比如多多利用开源资源。我感觉还是比较困难，可能把每个人培养成精通上述技术的高手
不太现实。技术人员一般比较固执，比如我，我一般对自己不熟悉的领域，也不是很想尝试，而是安于现状。另外，
可能就是没有时间，做项目已经很累了，还要接受那么多新东西，累不累阿！到现在，我相信人真的是有差别的，
不是每个人都可以培养成顶尖高手，以前我认为这是可以的。
       沟通多了，就不会寂寞，将此篇文章作为我在JavaEye上的第一篇博客，希望以后和大家多多沟通！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

用例名称	发送短信
用例编号
用例作用域	短信发送和接收
用例版本	1.0
优先级	5
主要参与者	普通管理人员
涉众	涉众名称	兴趣
	短信接收人	准确及时的收到短信
	短信网关	准确及时地将短信发送到用户手中
前置条件	已登录到短信平台
触发条件	管理人员想通过本平台发送短信时
主事件流	1. 用户选择发送短信功能 2. 系统显示短信编辑页面。 3. 用户输入编辑短信信息 4. 用户选择发送范围。 5. 系统所有部门，用户组，用户供用户选择 6. 用户选择发送目标群体，并确定。 7. 用户点击发送，发送短信. 8. 系统将短信记录保存到短信网关发送表。
分支流
后置条件	短信成功被发送到短信网关
业务规则
特殊需求	选取发送群体，应做到灵活选择。

用例名称	删除联系人
用例编号
用例版本	1.0
用例作用域	个人通讯录管理
优先级	4
主要参与者	所有用户
描述	用户可以对不再联系的联系人予以删除。用户转到个人通讯录管理页面，用户有两种方式可以删除联系人信息，直接在列表中浏览，然后删除指定的条目，也可以执行联系人查询功能，进行批量删除。
特殊需求	应该有方便的批量删除功能