posts - 59,  comments - 323,  trackbacks - 0
一直有朋友发email来索要那本OpenDoc的源代码,这里一并给出下载地址。

http://www.blogjava.net/Files/zbw25/code.rar

抱歉,拖了这么长时间。

Update:
昨天在BlogJava上传的文件,今天就不能下载了,比较晕。。。

http://www.javaeye.com/topic/19448

这是在JavaEye的发布OpenDoc的地址,里面有下载的Link。
http://www.javaeye.com/topics/download/54f814f5-b77f-46e1-bf61-bd384493f118

应该要注册成为javaeye的用户后,才能下载。
posted @ 2006-10-18 19:45 读书、思考、生活 阅读(107824) | 评论 (11)编辑 收藏
 
 

我写的总结
 

  如果和超级女生这样的大赛相比的话, Ajax 大赛应该被称之为“ Ajax 小赛”吧。 250 名初赛选手, 10 多名复赛选手,三个来自于一个网站“ Ajax 中国”的评委。这样的比赛意义在哪里呢?

 

  仅仅看数量,是看不出来的。

 

  Ajax Web 应用的一种,而且可以肯定的说,是 Web 应用中最为复杂的一种,一个 Web 项目,我们通常都会分为“美工”、“ Web 静态页面制作”、“ Server 端系统开发”这样几个工种。而 Ajax 应用则同时需要 Server 端与 Client 端复杂的端到端编程技术。

 

  对于参赛选手而言,这些工作,都得靠一己之力来完成,在 2 个多月之内,做出来的作品,要美观,要好用,要有创意,要符合 W3C 组织的 Web 标准,还得正确有效的作为一个程序在浏览器里运行。真的,不容易!这 11 位(可能会修改)参赛选手,每一位都不容易!

 

  我们(大赛组织者、评委和参赛选手)都非常确切的意识到,我们正处在一场变革刚刚起步的阶段。 Ajax 可能仅仅是这场革命开始时,最响亮的一个名字。激动人心的发展将会接踵而来,而我们这些人将会自豪的宣称,我们从一开始就不是旁观者,而是实实在在的参与者,和有力的推动者!

 

  看着选手们的代码,我们的信心更加充足,这些 Ajax 的爱好者和参与者们,不仅是热忱的,更是踏实的。不但是严肃认真的,更是勇于创新的。由这样的一群人来推动 Ajax 在中国的发展,实在是一个极好的开始。

 

  而 Ajax 大赛,正是这样一个机会,使得这一群中坚力量,能够集结、凝聚,进而取得更加卓越的成就。这就是我对于这个比赛意义的理解。


   说实话,稍微吹了一点

posted @ 2006-07-14 21:35 读书、思考、生活 阅读(29936) | 评论 (0)编辑 收藏

“出来混,总是要还的。”这话说得真好。我最近的blog写得太少了,想写的东西,其实又实在是不少,一日复一日的堆积心里,又想写,又不想写,难受呀。

这篇blog原本还是打算在Word 2007里写的, 后来作为草稿发上来,发现还有不少不如意的地方,还是在线写吧。

想说的事情挺多的,一件一件的说吧。

一、敏捷中国大会,6月6日在上海交大举办了一场。专门介绍ruby的,昨天在csdn的martin fowler的中文blog上,也贴出了完整的演讲全文。《Ruby是一个非常好的开发工具》,《现场演示Ruby编程》,《细数Ruby语言优缺点》。关于这次活动的一篇Blog按理我早就该写了,但是却一直没有写出来。有两个原因,一个是那天老马在开讲之前,熊节是打算在边上当翻译的,谁知道交大的同学们牛啊,纷纷表示,不必翻译,都听得懂的,我一个学俄语的人,在那里抗议也没什么用,大家都一副听力很好的架势,老马在上面叽里呱啦的讲着,下面的同学们不时的笑着……我呢,也只能随着大家的笑声,冲着老马空洞的笑着……;第二个原因呢,是个原本打算等CSDN的演讲的翻译出来,我也好引用一下,谁知这一等,就是半个月,我都已经换了一个工作了。

说实话,那天老马的演讲,我没听懂,不过因为他在那里现场coding,所以我还是看懂了一些代码。Ruby的代码给人留下了深刻的印象,而且我不知道是不是Martin故意装作是一个初哥,反正看起来他对ruby的语法也不怎么熟悉,不过ruby厉害的地方就在于,你就算是个初哥,边试边弄,也能把程序鼓捣出来。

原本的计划是介绍Ruby DSL的,不过时间明显的不够用,关于DSL的部分反而讲得很少,还好这两天armlinux-w翻译了一篇专讲Ruby DSL的文章过来:《用Ruby 创建领域特定语言》。当时看到Martin演示的,用Ruby语言描述的配置文件时,脑子里颇有些想法,也写了问题交上去问,不过老马也来不及一一回答,后来想想,提的那个问题,也没有经过自己的深入思考与实践,不提也罢。

倒是我提的另外一个问题,颇有些价值,当时正好交大的林德樟老师也在,我以前就对林老师的那句语录有所不满《XP是草书,UP是正楷,先草书后正楷,就会乱套》。在自己的Blog上也和林老师的门徒们吵过架,如今Martin教主本人既然来了,我等看客正应该把这仗挑起来才是。于是我就提了一个问题,让两位专家都来评价一下这句话。可惜的是,后来他们两人的精彩交锋,我也没怎么听懂,还是林老师还用中文阐述了一遍自己的观点,我算是了解了一下他的逻辑。

原来我以为,林老师这样的说法,是出于在校教师“和稀泥”的考虑。这下我才了解到,原来林老师是真的这么认为的。而他这么一种说法的依据,还是惯常的“中国国情论”。或者称之为“补课论”。因为美国人是现有软件工程,才有极限编程,而我们现在的软件产业还落后人家几十年,所以不把软件工程这一课不上,是不行的。然后林老师还颇有些“攻击力”的询问Martin,当初你先写了UML,后来又写了XP,不也是这样一个心路历程吗?老马如何回答,我也没有听懂,但是在我看来,林老师混淆了三个概念,一个是国家级的软件产业的发展水平,一个是企业级的软件开发的管理水平,一个是开发人员的技术与理论水平。这三个不同的水平被他搅在一起,用于支撑自己的说法,实在是所以,会后我又追上去问林老师,我提出了三个概念混淆了云云,没想到林老师相当和蔼可亲的对我说:“嗯,你说的没错”,然后又说到关于大学的软件教育的问题,我在说很多刚毕业的学生,对于软件开发的理解,往往停留于知识点的积累上,而没有去思考,我打算把这些知识点,组合起来运用,以达到什么目的。很多学生,只是说我知道什么什么,而不会说,我会做什么什么。林老师又和蔼可亲的对我说:“嗯,你说的没错。我一直跟学生们说,学校和企业是完全不同的,真正的知识,只能在企业里才能学到。”然后我又说,其实软件学院应该多推荐学生去企业实习,还有就是多鼓励学生参与Open Source的项目呀。林老师还是和颜悦色的对我说:“是啊,不过现在的企业,要他们肯接收学生实习,不容易的。在美国,每年暑期都会有大量的实习生招聘,这其实就是企业在做慈善呀。再说现在的大学老师,对Open Source的了解,也很少的呀。”然后,我就跟林老师告辞了。作为一个老师,他给我留下了很好的印象,但是,我更加悲观的发现,要通过学校教育,提高软件开发人员的素质,好难啊!

会后大家又找了一家小饭店FB了一下,CSDN的霍泰稳也来了,我还给他们提了一个建议,以后CSDN最好能够搞一个系列的活动,不断的把世界各地的软件大师们请到中国来,巡回演讲,收取门票,整理成每年基本的《软件大师在中国》这样书出版,还有视频光盘也可以卖钱,各位大师的中文Blog也都建在CSDN,应该是一桩双赢的好事啊,就看他们是不是打算做了。

(待续)

posted @ 2006-06-20 23:05 读书、思考、生活 阅读(28064) | 评论 (6)编辑 收藏
最近一直在讨论招人的事情,如何判断一个人的水平,怎么样才算是没有bug,等等等等。也看到一些并不怎么有趣的反对意见,比如:
不要出来搞笑说:
没有bug的程序?????????
靠,站着说话不腰疼。那个公司可以做出没有bug的软件来?
当然,没有写过程序的人不出bug!!
估计这位同志不会写代码,是个理论专家。
还是不要这么狂的好。
我估摸按你的标准,你是肯定不会被别人录用的!
123说:
你是编程的吗?
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧
说实话,这两个名字我看都不是用户名,而且很可能是同一个人,就是所谓的troller。我说的没有bug,是交给我的demo没有bug,这样的要求很高吗?我还没有出算法题,要求应聘者的算法效率呢?仅仅要求一个正确实现简单功能的程序,很过分吗?
 
在JavaEye还看到另外一篇帖子《大伙能进来讨论下“跳槽”的问题》,有一个小伙子,对自己的代码有感情,对人有感情,对公司有感情,所以当公司遇到困难的时候,一时间舍不得走。这样正常的事情,居然颇遭到不少人的冷嘲热讽,和各种“善意”的劝诫。
 
我就觉得非常奇怪,一个程序员,如果对自己写的代码没有感情,怎么可能写出漂亮的代码来?同样的道理,如果一个程序员,对自己的工作质量没有追求,又怎么可能成为高水平的程序员?一个前来应聘的人,为了得到offer而写的demo,就这种情况下,在寄出代码之间都不认认真真的检查检查,这样粗心大意的家伙,我怎么敢招?
 
总而言之一句话:“对代码有感情,对质量有追求”,这是成为好程序员的基本前提。
posted @ 2006-06-18 02:23 读书、思考、生活 阅读(27647) | 评论 (14)编辑 收藏
  我写了一篇blog叫做《招人不难》,很多朋友很赞同,也有的朋友不同意我的意见,他们很怀疑:“有bug的一律不要?没有BUG的代码是不存在的...blabla”
 
  正好今天又看到一篇转贴的笑话,叫做《【转】从一个笑话看软件开发管理》,大意是,程序员交出了自以为没有bug的代码,然后一切都变得越来越糟糕,而程序员总是会交出自以为没有bug的代码。
 
  我们今天就来谈谈,一个程序员,什么时候可以交出自己的代码,并且可以自豪的对别人说:“我的代码里面,没有bug!”。
 
  先说传统的做法,一个负责的程序员,应该在交出代码之前,自己跑好多次自己的代码,左看右看,上看下看。直到交出去的时候,没有一个人能够发现其中的问题。这样的能力一般只有天才才能具备,我以前遇到过一个。但是,如果我企图以这样的标准来招人的话,那就是在发疯,怎么还敢说“招人不难”?
 
  说说可行的办法吧。一个程序员如果足够的谦虚,时时想证明自己可能犯错,即将犯错,或者已经犯错。那么他就会尽量写出足够多的TestCase,以便打消自己的疑虑。直到所有的测试用例全部通过,屏幕上显示出美丽的绿色长条,他才能确信,自己的代码没有bug。
 
  所以,我的判断标准,也很简单。如果寄给我的代码,没有附带测试用例,我就自己运行他的程序,随意的乱找,找到一个我认为是bug的,那就是有bug了。如果寄给我的代码,附带了足够的测试用例,我只要Run一次,看到绿条,这一关就算是过了。~~~很简单吧。
 
  也许有人会说,那如果他的测试用例很简单呢?岂不是不能说明什么问题?怎么不能说明问题呢?首先可以说明:这是一个会写测试用例的程序员!其次,我会看看他的测试用例的代码,大概覆盖了多少的功能特性。当然,这是更进一步的能力判断。但是至少,他的代码已经达成了他自己的设计了呀。
 
  所以:“有bug的一律不要”,意味着,你最好能够自己证明自己没有bug,否则,我如果找到一个bug,你就没戏了。
posted @ 2006-06-11 10:34 读书、思考、生活 阅读(28659) | 评论 (10)编辑 收藏
  孟老师最近有点烦,面试了一个刚毕业大学生,结果发现那家伙一问三不知。随后的跟帖也是常见的感叹:
  “现在的大学生过于浮躁”
  “真不明白本科都在学什么”
  还有一位台湾同胞说:“本來還以為只有在台灣有這種情形,原來兩岸的情都相同。”
 
  因此,打算写这篇blog,介绍一下我是怎么招人的。其实,招人并不难。
 
  1、写招聘广告
  2、收简历,初步了解背景情况,然后让加我的MSN
  3、在MSN里,就问一个问题:以下几种技术,你哪一种最熟悉,哪一种最不熟悉
  4、你就用最不熟悉的那种技术,做一个demo给我,没有时间限制,要求如下:
    -首先是demo的质量,一定不能有任何bug
    -其次是代码的质量,要干净,明白,好懂。
    -要有创意
    -在功能创意与时间进度之间,自行平衡
  5、拿到代码之后,先看看能不能正常运行,看看有没有bug。
  6、在Google里搜索代码的关键段落,看看有没有抄袭,或者了解一下借鉴的程度
  7、看他的代码,是不是足够干净,足够合理,足够朴素
  8、如果一个人能够在很短的时间里,自行快速学习一种新的技术,并交出足够质量的代码。这样的员工,我就准备要了。至于面试,无非是谈谈工资的高低意向罢了。
 
  这样的招人办法,要点在于:
  1、我不关心他的学历,工作经验,年龄和技术背景,因为招到一个出色的员工,他会持续的自我学习,不断的进步。
  2、有bug的一律不要
  3、代码最能够说明问题,其他一切判断都要在我看过他的代码之后。一个人,不要玩弄聪明,不要炫耀技巧,写老老实实,干干净净的代码,合理的贴切的变量命名、方法命名、类命名,合理而不多不少的类间关系。这样的代码,就是漂亮的代码。能写出这样的代码的人,就有足够好的思维和品性。
  4、快速学习的能力要比过去的工作经验更加重要,因为那么多工作经验,也要有助于完成今后的工作,才能体现出价值。
  5、不抄袭,有创意,这样的人才很难得。
  6、有计划的实现功能,能够在功能和时间进度之间合理决断。这就是有大局观的人才。
 
  当然,这样招人的基础是,你自己的代码水平要够高。很多公司根本就没有这样的水平,只能靠笔试来判断人家的水平。
 
  我工作过的公司,曾经有一个小伙,他的代码,缩进不是靠Tab,而是“按下空格键,任代码随意后退”,他的代码,弯弯曲曲,难看至极。前两天,他跟我说“我笔试得了90多分,当场拿到了4.5K的Offer。”可见,笔试是毫无意义的测试手段。
 
btw:还有问题,这样招人效率不是很高,也比较累,紧急招人的情况不适用。当然,紧急招人的项目,通常肯定是搞不好的。
posted @ 2006-05-30 16:11 读书、思考、生活 阅读(28565) | 评论 (36)编辑 收藏
  大多数程序员,都极度痛恨写文档。Coding是愉快的,而Write是痛苦的。有一部分原因,其实是要归咎于程序员自身,以我的经验,很多程序员往往会“艰于表达”,尤其是用“文字、图表、PPT、Word”之类的Office Document来表达。当然,还有一部分原因,是由于很多项目开发实践中,文档的前后矛盾、形式主义、反复修改、歧义重重,常常让程序员们抓狂。
 
  UML是一个比较好的工具,但是,仅仅靠UML,是无法将项目的知识描述清楚的。也有不少项目组在引入了UML之后发现,文档的工作量不但没有减少,而是更多了。随着项目的进展,需要维护的设计文档数量,也更多了。也因此造成了更多的前后矛盾,形式主义,反复修改。
 
  根本的痛苦,并不在于一开始写一份文档,而在于所有写下的文档,都必须跟随项目的进展而随之变化。当我们写出来的文档越多,需要被持续维护的文档也就越多,需要反复检查文档间的可能存在的矛盾也就越多,所有扔出去的石头,最后都会落回到自己头上。
 
  于是,还有不少项目组,将文档工作与代码工作截然分开,文档就写一次,用来应付上面的管理层,而代码自管自的继续开发。对于小型项目来说,这其实是一个不错的权宜之计。但是一旦项目越来越庞大、复杂。所有的隐性的知识,都仅仅存在于程序员的脑子里,所有成文的东西,都可能是错的,而真实的情况,却隐藏在代码之中。如果代码质量再糟糕一些,后来维护的朋友,就遭遇火坑了。
 
  文档,写还是不写,这是一个问题!
 
  还记得测试驱动开发吗?为自己的每一个方法,每一个类,都写出单元测试来。不但如此,更加彻底的做法是,在写代码之前,先写测试用例。这样才能保证不会忘记写测试用例。更大的好处在于,这样有助于思考、有助于获得更加完善的设计,有助于写出更加高质量的代码,有助于安全的重构,有助于自动化的持续集成实践。总之,是好得不能再好的一项开发实践。
 
  这一实践之所以可行,就在于他将繁杂的集中的测试工作,分解为日常的,必须不断进行的工作。当你每天都在写测试用例,当你的每一个测试用例,都能够与代码完全对应时,压力反而减轻了,工作量也更少了,更重要的,一些优良的习惯也因此被养成了。
 
  在两年前,我要开始一个全新的P2P网络电视项目时,也在考虑关于文档的问题。当时我发现了Open Source的WikiPedia。这是一个PHP的WIKI,最大的应用是维基百科全书。因此,这个项目的质量就绝对值得信赖。我就将它拿过来,作为我们项目文档管理的工具。
 
  用Wiki来管理项目文档,基于以下一些考虑:

文档是项目的知识,这些知识必须集中管理、容易获取、人人可以编辑。

项目在生长,代码在增加,文档也必须能够跟随项目自然生长,强行划分设计阶段和开发阶段,是不可取的。

Wiki不是传统的项目文档,而是一个应交流需要,可能随时增删改的知识库。项目组的成员,遇到问题,就应该首先查看Wiki,如果这是Wiki中没有,那么他应该找人询问。而那个知道答案的人,如果他不想再今后不断的回答同一问题,就应该把这个答案写入Wiki,这就是Wiki条目增长的自然动力。

传统文档最大的问题在于浪费,而Wiki通过持续修改,按需提供的方式,保证了所有写下的文字,一定有超过一个人需要读它。

 
  在Wikipedia的基础上,我又做了一些增强,以更好的辅助项目的管理。

Include功能,增加include标签,可以在一个条目中,引入其他条目的全文,而不是仅仅增加一个link。

文档的层次结构,当项目的文档条目逐渐增加,分门别类的条目,更加便于查找,也可以有效的避免条目重名的问题。

一个Click,就能够创建新一个条目,用于填写当天的工作安排。

  相应的管理制度,也必须建立起来。

每日15分钟文档制度,基于“填写当日工作”的功能,我规定每个项目组成员,每天要花三个5分钟来写文档,早上的5分钟,填写当日工作计划。中午的5分钟填写上午的工作情况,下班前的5分钟,填写下午的工作情况。这样,每天的文档工作相当轻松,但是文档能够保证持续的跟随项目成长下去。更进一步的,这样的制度,对于项目的进度控制,也很有帮助。

User Case条目驱动,所有分解出去的User Case,在分配到责任人之后,该责任人的第一项工作,就是在Wiki中写下对于这个User Case的理解。随后项目进展,也应该持续的维护这个条目。

同时进行Bug的管理,Bug也作为Wiki中的条目,以便于和其他条目项目引用。

每次Check In CVS时,必须写注释。这是更加细节的文档,然后我还做了一个小程序,能够自动的从CVSTrac中读出当天Check In代码的注释。供每个人在写当天文档的时候引用。

  总而言之,我对于项目文档的看法,并不是非此即彼的极端主义者。在我看来,好的项目文档管理政策,应该有助于集中团队知识和智慧,同时不要让程序员痛苦和反感。这样才叫做有效的项目管理。仿造Martin Fowler的著名文献《持续集成》,我给这篇Blog起这样一个名字《软件开发文档的持续集成》,希望能够引发更多的、更深入的思考。
posted @ 2006-05-12 14:23 读书、思考、生活 阅读(28300) | 评论 (3)编辑 收藏
  我新到这家公司,就开始了一场死亡之旅,我们的项目开发周期是3个月,人员大概有3~6个不一定。而以我的经验,我们大概要做的,是一个3~5个人年的非常复杂的创新型项目。新加盟的技术总监,是一个崇尚文档交流的“老干部”,因此,我们花了一个月的时间,在写各种各样的设计文档。真正能够用于开发的时间,是2个月。
 
  我们这个小组的另外一位组员,也是一位经验丰富的项目经理,他崇尚的,是文档UML化描述。因此,我现在除了写文档,还要用Rational Rose画好多好多的图~~~
 
  在他们两位来这个项目组之前,我其实已经写出了一份基本完整的User Case列表,而且和另外一位组员已经进入测试驱动的、结对编程阶段了。。。
 
 
  大家可能已经看出来了,这其中的开发模式,简直就是混乱不堪。到底是文档驱动?UML驱动?用例驱动?还是测试驱动呢?
 
  问题还不止这些,我们的大老板比较喜欢和我们一起讨论设计,甚至会和我们争论具体的某个算法。开发文档没有统一的管理,汇报机制没有明确的定义,项目需求随时都可能变动,就连到底我们这个小组会有几个人,都还是一个未知数,这样的死亡之组,不知各位有什么好的建议?

 背景资料介绍完毕,抱怨结束,下面讨论正题:

  文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题?

  要回答这个问题,还真不容易。我们得问一个更加重要的问题,真正驱动项目的,究竟是什么呢?我想,应该是需求吧?

 

  那么,这些“文档”、“测试”、“用例”、“模型”、“特征”,究竟是什么呢?对于需求的描述!我们之所以不会直接用需求来驱动项目开发,而是要借助工具,来帮助我们描述需求,就是因为口语化的需求描述是非常模糊的,充满歧义的。所以,选择什么来驱动我们的项目,其实就是要看,以上这些工具,哪一个能够更好、更准确的描述需求?

 

  文档其实是最难准确描述需求的一种方式,如果是纯文字的文档,就更难。我们的技术总监,非常喜欢读写文档,我最近也创下了一天写47页文档的最新记录。但是,当我们开会的时候,我还是经常需要提醒我们的技术总监,麻烦他再仔细看看文档第XX页的第XX段,以及配合着另一份文档的XX小节,来确切的理解我的意思!如果没有我的解释,他就会误解我的文档。

 

  当然,如果要写出不需要我来解释,他就能理解的文档,那么文档的工作量,将会极其惊人!我以前写过一篇blog,《Jacobson博士演讲观后感》是我对UP的创始人的极度反感的集中体现。GHawk,以及交大林老师的所谓“UP”的观点,当然不可能获得我的赞同。在GHawk的最新一篇blog:《UP & XP之争,意义何在?(续)》中,GHawk说:“唯一的问题是:“如何确保测试用例的质量”。显然,我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢?“结对编程”么?嗯,这是一个不错的方式,那么最终该信赖谁呢?是Pair中的A还是B呢?或者,是Leader么?那么又是谁提出的要求呢?是老板么?还是客户?政府?法规?市场?……问题没有终结了。”

 

  由此我可以推断,他对于XP的认识,基本上是停留在猜测的阶段。对于这篇blog的观点,我就不逐一反驳了,我的猜测是,他经历过一次失败的XP尝试,而究其原因,我猜测是因为他们那个所谓的XP Team中,没有一个人,曾经实践过一次正规的XP开发。

 

  再来看模型驱动,这中间有一个大问题,因为需求是“问题域”的范畴,而模型,则是“解答域”的范畴,试图通过解答域的精确描述,来实现对于需求的准确描述,肯定不靠谱啊。

 

  特征驱动,我认为FDD其实是老方法的新名词,具体的实践,可能更加接近测试、迭代式的过程。了解不过,所以我也不打算多说。

 

  用例驱动与测试驱动,其实我认为这是一个硬币的两面,用例要尽快的翻译为测试用例,而测试用例,正是为了更加准确的表述需求用例。这是我能够想到的,驱动项目开发的,最好的方法!

posted @ 2006-04-26 00:32 读书、思考、生活 阅读(29165) | 评论 (31)编辑 收藏
  几段在脑子里盘旋了很久的话:
 
  带一个项目,要保证项目的质量,当然要靠Team Leader的水平。那么,什么才是最重要的项目质量呢?当然是代码质量!一个软件项目,最重要的产品当然是代码!
 
  如果这个Leader看不懂项目的代码,他只能通过要求文档的质量,来间接的控制代码的质量。一个能够看得懂代码的Leader,他就能够直接控制代码质量。而能够直接控制代码质量的Leader,对于文档的要求,会合理很多。
 
  直接控制与间接控制,哪一个更加有效,是不言而喻的。当然,那些没有代码阅读能力的Leader,他们会更加强调文档的重要性,甚至舍本逐末,认为文档质量才是项目质量的体现。进而变态地追求文档完美,以至于浪费了程序员写代码的时间。这样的Leader,根本就不可能管好项目的。
 
  公司往往会出于恐慌,向员工要求很多详尽的文档,主要是为了防止员工离职带来的损失。而问题在于,公司的主要努力,应该用于留住员工,而不是用于加强“善后能力”。更不是为了增强善后能力,搞得员工越发想离开这家公司。
 
btw:
 
补记一段交锋对话:
软件开发项目中的成本比例》是我以前写的一篇blog,有一个GHawk有这么一段留言:
 
UP和Agile都是工程过程实践的总结,林德彰先生说过“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非,这只是在不同的实践内容和阶段上的总结。在过程的选用问题上,只有不断地实践才是前进的方向。 
 
另外还有一篇blog,专门讨论这句话。
 
我的回答是:
 
林德彰的说法,是一个在校教师,典型的和稀泥的说法,我不同意。
 
没想到今天有一个朋友WANG回了一帖:
 
老林是在校教师?你应该去看一下人家在美国打拼的经验~~  
 
我的回复是:
他在美国打拼怎么了?还有好多土生土长的美国人,也不鸟那什么UP呢?
我为什么要听一个海龟来上课呢?
这年头,海龟还不够多吗?

另外对GHawk多说一句话:让组员快速磨合的最好办法,是结对编程,而不是大家埋头写文档。
posted @ 2006-04-22 21:35 读书、思考、生活 阅读(29364) | 评论 (21)编辑 收藏
  我们现在这个公司的大老板,平时在三楼办公。但是,每天都会有几次,他会在我们的办公室里走来走去——“进行着聊胜于无的监督工作”。
 
  我想,他大概没有听说过“XP”、“结对编程”这样的名词。
 
  4月15日,周六,我参加了BEA上海User Group的一次活动。北京来的Charls,做了一次非常精彩的演讲。名字叫做《一个Xper的心路历程》。全场笑声不断,Charls的感染力征服了每一个人。
  演讲最后提出的一个观点是:“成为一个Xper,就是成为一个合格的程序员”。要勇于暴露自己的不足,要善于沟通,要谦虚,要有计划,要……做到了这些,我们才算是“刚刚够格”。
 
  我基本上已经被说服了……在Charls演讲结束的时候,我只想问一个小问题。因为他说,在项目组里,如果有人遇到问题,不要自己偷偷摸摸 的Google搞定,而是应该马上“举手”,看看小组里有没有人能够马上告诉你答案。这才是“勇于暴露自己的不足”。而我还想从另外一个角度问一下。
 
  (以下对话是一个大概的回忆)
 
  “我一直以来的工作方式是这样的,遇到问题的时候,首先Google一下,这样我不但可以找到当前这个问题的答案,还能够了解很多周边的知识,触类旁通。如果直接问人的话,问题解决,我也就不再深入了。这样是不是对于个人能力成长不太有利呀。”
  Charls:“项目进度在那里,当然是马上解决问题最好。”
  我:“那么我们是不是可以这么理解,XP对于项目开发的目标很有效,而对于程序员个人能力的成长目标,不是很有效?”
  Charls:“我一直这么说,XP更加高级的剥削方式……”
 
  顿时,我豁然开朗。XP的好处,从老板的角度来看,应该更多:
 
  结对编程——最有效的相互监督机制
  结对编程——最有效的内部培训机制
  测试驱动开发——最有效的质量保证体系
  User Story+客户现场办公——最低成本的需求收集、分析机制
  每日集成——有效降低集成、测试成本
  …….
  从程序员的角度来说,这些“与我何干”呢?

  所以,一个追求利润最大化的老板,就应该选择XP,而一个聪明的老板,不但要运用XP,还要保证8小时工作制,甚至给员工20%的 On Beach时间(来源于Gigix对于ThroughWorks的介绍)。这样才能保持员工的可持续编程能力。如果我是老板的话,我就会这么干!
  那天讨论的话题中,还有一些XP没能够很好回答的问题:
  比如文档。在我以前的开发实践中,我们都建立了一个Wiki,并且强制程序员每人每天就Wiki几次,以分散写文档的压力。
  比如对于人员的高要求的疑问。我的理解是,XP对人员提出了很高的要求,但是同时也提供了最有效的人员培训机制(结对编程),所以,对于入职人员的要求,并不需要很高,更多的是考察一个人的沟通能力、学习能力,而不是开发的能力。
posted @ 2006-04-18 06:44 读书、思考、生活 阅读(29789) | 评论 (9)编辑 收藏
仅列出标题  下一页
<2017年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

常用链接

留言簿(20)

随笔档案

友情BLOG

搜索

  •  

最新评论

阅读排行榜

评论排行榜