一直有朋友发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 读书、思考、生活 阅读(108269) |
评论 (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 读书、思考、生活 阅读(30202) |
评论 (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 读书、思考、生活 阅读(28426) |
评论 (6) |
编辑 收藏
最近一直在讨论招人的事情,如何判断一个人的水平,怎么样才算是没有bug,等等等等。也看到一些并不怎么有趣的反对意见,比如:
不要出来搞笑说:
没有bug的程序?????????
靠,站着说话不腰疼。那个公司可以做出没有bug的软件来?
当然,没有写过程序的人不出bug!!
估计这位同志不会写代码,是个理论专家。
还是不要这么狂的好。
我估摸按你的标准,你是肯定不会被别人录用的!
123说:
你是编程的吗?
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧
说实话,这两个名字我看都不是用户名,而且很可能是同一个人,就是所谓的troller。我说的没有bug,是交给我的demo没有bug,这样的要求很高吗?我还没有出算法题,要求应聘者的算法效率呢?仅仅要求一个正确实现简单功能的程序,很过分吗?
在JavaEye还看到另外一篇帖子《
大伙能进来讨论下“跳槽”的问题》,有一个小伙子,对自己的代码有感情,对人有感情,对公司有感情,所以当公司遇到困难的时候,一时间舍不得走。这样正常的事情,居然颇遭到不少人的冷嘲热讽,和各种“善意”的劝诫。
我就觉得非常奇怪,一个程序员,如果对自己写的代码没有感情,怎么可能写出漂亮的代码来?同样的道理,如果一个程序员,对自己的工作质量没有追求,又怎么可能成为高水平的程序员?一个前来应聘的人,为了得到offer而写的demo,就这种情况下,在寄出代码之间都不认认真真的检查检查,这样粗心大意的家伙,我怎么敢招?
总而言之一句话:“对代码有感情,对质量有追求”,这是成为好程序员的基本前提。
posted @
2006-06-18 02:23 读书、思考、生活 阅读(28039) |
评论 (14) |
编辑 收藏
我写了一篇blog叫做《
招人不难》,很多朋友很赞同,也有的朋友不同意我的意见,他们很怀疑:“有bug的一律不要?没有BUG的代码是不存在的...blabla”
正好今天又看到一篇转贴的笑话,叫做《
【转】从一个笑话看软件开发管理》,大意是,程序员交出了自以为没有bug的代码,然后一切都变得越来越糟糕,而程序员总是会交出自以为没有bug的代码。
我们今天就来谈谈,一个程序员,什么时候可以交出自己的代码,并且可以自豪的对别人说:“我的代码里面,没有bug!”。
先说传统的做法,一个负责的程序员,应该在交出代码之前,自己跑好多次自己的代码,左看右看,上看下看。直到交出去的时候,没有一个人能够发现其中的问题。这样的能力一般只有天才才能具备,我以前
遇到过一个。但是,如果我企图以这样的标准来招人的话,那就是在发疯,怎么还敢说“招人不难”?
说说可行的办法吧。一个程序员如果足够的谦虚,时时想证明自己可能犯错,即将犯错,或者已经犯错。那么他就会尽量写出足够多的TestCase,以便打消自己的疑虑。直到所有的测试用例全部通过,屏幕上显示出美丽的绿色长条,他才能确信,自己的代码没有bug。
所以,我的判断标准,也很简单。如果寄给我的代码,没有附带测试用例,我就自己运行他的程序,随意的乱找,找到一个我认为是bug的,那就是有bug了。如果寄给我的代码,附带了足够的测试用例,我只要Run一次,看到绿条,这一关就算是过了。~~~很简单吧。
也许有人会说,那如果他的测试用例很简单呢?岂不是不能说明什么问题?怎么不能说明问题呢?首先可以说明:这是一个会写测试用例的程序员!其次,我会看看他的测试用例的代码,大概覆盖了多少的功能特性。当然,这是更进一步的能力判断。但是至少,他的代码已经达成了他自己的设计了呀。
所以:“有bug的一律不要”,意味着,你最好能够自己证明自己没有bug,否则,我如果找到一个bug,你就没戏了。
posted @
2006-06-11 10:34 读书、思考、生活 阅读(29253) |
评论 (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 读书、思考、生活 阅读(28949) |
评论 (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 读书、思考、生活 阅读(28624) |
评论 (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 读书、思考、生活 阅读(29542) |
评论 (31) |
编辑 收藏
几段在脑子里盘旋了很久的话:
带一个项目,要保证项目的质量,当然要靠Team Leader的水平。那么,什么才是最重要的项目质量呢?当然是代码质量!一个软件项目,最重要的产品当然是代码!
如果这个Leader看不懂项目的代码,他只能通过要求文档的质量,来间接的控制代码的质量。一个能够看得懂代码的Leader,他就能够直接控制代码质量。而能够直接控制代码质量的Leader,对于文档的要求,会合理很多。
直接控制与间接控制,哪一个更加有效,是不言而喻的。当然,那些没有代码阅读能力的Leader,他们会更加强调文档的重要性,甚至舍本逐末,认为文档质量才是项目质量的体现。进而变态地追求文档完美,以至于浪费了程序员写代码的时间。这样的Leader,根本就不可能管好项目的。
公司往往会出于恐慌,向员工要求很多详尽的文档,主要是为了防止员工离职带来的损失。而问题在于,公司的主要努力,应该用于留住员工,而不是用于加强“善后能力”。更不是为了增强善后能力,搞得员工越发想离开这家公司。
btw:
补记一段交锋对话:
UP和Agile都是工程过程实践的总结,林德彰先生说过“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非,这只是在不同的实践内容和阶段上的总结。在过程的选用问题上,只有不断地实践才是前进的方向。
我的回答是:
林德彰的说法,是一个在校教师,典型的和稀泥的说法,我不同意。
没想到今天有一个朋友WANG回了一帖:
老林是在校教师?你应该去看一下人家在美国打拼的经验~~
我的回复是:
他在美国打拼怎么了?还有好多土生土长的美国人,也不鸟那什么UP呢?
我为什么要听一个海龟来上课呢?
这年头,海龟还不够多吗?
另外对GHawk多说一句话:让组员快速磨合的最好办法,是结对编程,而不是大家埋头写文档。
posted @
2006-04-22 21:35 读书、思考、生活 阅读(29926) |
评论 (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 读书、思考、生活 阅读(30171) |
评论 (9) |
编辑 收藏
决定不再玩连载的把戏了,总共就这么点文字,还不如一口气放出来算了。
这是以前写的书的初稿,后来因为打算全部推翻重写,所以将过去写的内容,作为Open Doc放出。
欢迎下载: AJAX——新手快车道
posted @
2006-03-27 22:39 读书、思考、生活 阅读(6217) |
评论 (24) |
编辑 收藏
这是一个Java的NIO开发框架,我在上一家公司,和现在所在的这家公司,都已经使用了这个框架。但是,开发人员始终只有他一个人。
前天他写了一篇Blog:《
目标》,对我有很大的触动。我也一直存在这样的疑虑,为什么我们要用Java开发网络应用?或者说,使用java开发的网络应用,难道注定只是一个快速原型,就像当年用VB开发桌面应用?一旦需要面对性能需求时,就得推翻过去的工作,用C/C++重新实现一遍?
现在,目标已经很明确了——“无限接近于C/C++效率的java网络框架”。这是Cindy的终极目标,而我则相当确信,我一定要为这个目标,做出贡献!现在,我已经是Cindy项目的第二名成员了
zoomq在woodpecker上写道:
每日至少抽一刻钟解答列表中初学者的问题,
每周至少抽两小时整理新学知识,用Blog/Wiki/mail将体验发表/分享出去,
每周至少抽四个小时来翻译自个儿喜爱的自由软件的文档,
每月至少抽八小时编程,推进自个儿的项目,
每年至少参加一次自由软件的活动,传播自由软件思想,发展一名“自由人”……
只要我们每个人都坚持下去……
10年!就足以改变中国软件的整体风貌!
自接触电脑以来,自由/开源软件也一直给我诸多帮助和乐趣,Linux、Python、Vim凡此种种。当我有些业余时间,有些体会和收获时,又该为自由/开源社区做何回馈呢?
我的思考是:参加一个项目,或者发起一个项目,使用一个项目并且提交反馈,宣传一个项目。不要仅仅是感叹中国开源项目的水平。如果你是一个程序员,那么,你也可以为之做点什么。
posted @
2006-03-27 13:53 读书、思考、生活 阅读(3152) |
评论 (16) |
编辑 收藏
本来拿到的是一个20多M的MP3文件,还好找到一个工具,转了一下。还是微软的格式牛啊。
下载地址:
posted @
2006-03-22 15:55 读书、思考、生活 阅读(3196) |
评论 (7) |
编辑 收藏
我有很浓厚的“地图情结”,以前我写过一篇《我的信仰地图》,最近又做了一次关于Ajax的演讲,名字叫做《Ajax技术地图》。我一直以来的观点是,世界是一个整体,在这个巨大的世界之中,任何事物、任何知识,任何观点,都有其合理、自然的位置。理解这个世界的过程,就是逐步将需要了解的各种事物,在作为整体的一个世界中,找到其位置。了解这个位置的前后左右,相互关系,相互影响。这样的理解世界的学习方式,我认为是最为有效的。所以当我在JavaEye看到关于《代码大全》的广告时,我的第一反应就是:这不是世界地图吗?
看了看他的目录,竟然有35章之多?架构、分析、设计、编程、测试、重构、面向对象、调试、规范、管理、软件质量控制、协作、优化、开发工具、注释、甚至个性、开发艺术等等等等,只要是与软件有关的,基本上他都写到了。
说实话,我当时相当的不屑......可能吗?居然有这么一个家伙,能够像当年的托马斯•阿奎那一样,以一己之力,写出《神学大全》?CSDN的网站上介绍这个Steve McConnell,在1998年的时候,被Software Development杂志的读者评为软件业最具影响力的三大人物之一,与Bill Gates、Linus Torvalds齐名。一个写书的,能和两个写代码的天才齐名?网站上的那些推荐的话,个个都是大名鼎鼎,个个都是推崇备至。作为我这样一个有逆反心里的家伙来说,直觉上就是:“会不会呀,有这么牛吗?”
当然了,我也不好多说什么,毕竟没有看过书~~~
没想到好事居然找上门来了,博文视点的魏泉是我要写的那本Ajax书的责任编辑。而《代码大全》也是他们负责出版的。那天他找到我,说是让我看看这本书的书稿……看看能不能写一篇书评。这等美差,我很爽快的就答应下来了。
一看之下,果然是很喜欢,作者的思考问题的方式,与我的方式相当的接近,都是尽可能将多种、甚至矛盾的事物,放在一个整体的环境中来理解。比如对于隐喻,用于描述软件开发的特征的各种各样的隐喻,其实各有其价值,如果能够组合运用,自然能够获得一种平衡。正如作者所说:“使用隐喻又是件说不清楚的事情(fuzzy business)。你需要适当地引申它的含义,才能从其中蕴含的深刻启发中受益。但若你过分地或者在错误的方向上引申了它的含义,它也会误导你。正如人们会误用任何强大的工具一样,你也可能误用隐喻,但它的强大的功效,还是会成为你智慧工具箱中的一个宝贵部分。”
这样的一种看法,可以说“中正平和、深具智慧”,这是我们在大多数关于软件开发的论述中,很难看到的。
再比如说,作者在第三章时给出的一个表格:三种常见的软件项目种类,及其典型的良好实践。就将软件分为商业系统、性命攸关的系统以及性命攸关的嵌入式系统。然后指出对于这三类不同的应用,在开发手段、管理强度、设计、构建、测试、部署等等方面的差别化策略。这样的分类,自然就避免了将各种开发手段,简单的对立起来比较的方法,显得更加具有说服力。
再比如说,全书给出了相当多的Check List,这样的表格,实在是大有益处,借用地图的隐喻来书,这样的CheckList,就是一个一个的定位器,它能够帮助你认清自己的位置,了解问题所属的范畴,了解应该努力的大致方向。这样的“开发工具”,真是独一无二。
这本书我目前只看了前面的5~6章,实在没有太多的发言权,不过我现在已经可以肯定,这是一本非常有价值的好书,我推荐所有没有看过的朋友去看看这本名副其实的经典之作。
说实话,天下没有免费的午餐,我这篇书评,也是属于交差之作。人家出版社把样书给你看,请你写书评,当然希望你能说些好话幸运的是,这些好话,的确都是我自己愿意说的。
posted @
2006-03-22 15:53 读书、思考、生活 阅读(5625) |
评论 (5) |
编辑 收藏
广州之行,真是匆匆又匆匆,在广州呆的时间,算上在飞机场的时间,都还不到24个小时。
个中甘苦,就不在这里说了,还是把PPT传上来吧。
之所以叫处女秀,是因为这是我第一次上台做技术演讲,但是这句话却不是我自己想到的,而是江南白衣说出来的。
PPT的标题是《Ajax技术地图》,基本上是一个纯粹空对空的理论探索,不出现一行代码。还好随后曹晓钢的演讲,同样是讲Ajax,充斥了无数的代码,相信广州的朋友们,一定爽到了。
PPT的下载地址是:
http://www.ajaxcn.org/space/start/2006-03-13/1/Ajax%E6%8A%80%E6%9C%AF%E5%9C%B0%E5%9B%BE.pps
广州游记和其他感想,就明天再补吧。
posted @
2006-03-13 22:47 读书、思考、生活 阅读(2969) |
评论 (8) |
编辑 收藏