我写的总结
如果和超级女生这样的大赛相比的话，
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 读书、思考、生活 阅读(30203) |
评论 (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 读书、思考、生活 阅读(28430) |
评论 (6) |
编辑 收藏
最近一直在讨论招人的事情，如何判断一个人的水平，怎么样才算是没有bug，等等等等。也看到一些并不怎么有趣的反对意见，比如：
不要出来搞笑说：
没有bug的程序？????????
靠，站着说话不腰疼。那个公司可以做出没有bug的软件来？
当然，没有写过程序的人不出bug!!
估计这位同志不会写代码，是个理论专家。
还是不要这么狂的好。
我估摸按你的标准，你是肯定不会被别人录用的！
123说：
你是编程的吗？
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧
说实话，这两个名字我看都不是用户名，而且很可能是同一个人，就是所谓的troller。我说的没有bug，是交给我的demo没有bug，这样的要求很高吗？我还没有出算法题，要求应聘者的算法效率呢？仅仅要求一个正确实现简单功能的程序，很过分吗？
在JavaEye还看到另外一篇帖子《
大伙能进来讨论下“跳槽”的问题》，有一个小伙子，对自己的代码有感情，对人有感情，对公司有感情，所以当公司遇到困难的时候，一时间舍不得走。这样正常的事情，居然颇遭到不少人的冷嘲热讽，和各种“善意”的劝诫。
我就觉得非常奇怪，一个程序员，如果对自己写的代码没有感情，怎么可能写出漂亮的代码来？同样的道理，如果一个程序员，对自己的工作质量没有追求，又怎么可能成为高水平的程序员？一个前来应聘的人，为了得到offer而写的demo，就这种情况下，在寄出代码之间都不认认真真的检查检查，这样粗心大意的家伙，我怎么敢招？
总而言之一句话：“对代码有感情，对质量有追求”，这是成为好程序员的基本前提。
posted @
2006-06-18 02:23 读书、思考、生活 阅读(28041) |
评论 (14) |
编辑 收藏
我写了一篇blog叫做《
招人不难》，很多朋友很赞同，也有的朋友不同意我的意见，他们很怀疑：“有bug的一律不要？没有BUG的代码是不存在的...blabla”
正好今天又看到一篇转贴的笑话，叫做《
【转】从一个笑话看软件开发管理》，大意是，程序员交出了自以为没有bug的代码，然后一切都变得越来越糟糕，而程序员总是会交出自以为没有bug的代码。
我们今天就来谈谈，一个程序员，什么时候可以交出自己的代码，并且可以自豪的对别人说：“我的代码里面，没有bug！”。
先说传统的做法，一个负责的程序员，应该在交出代码之前，自己跑好多次自己的代码，左看右看，上看下看。直到交出去的时候，没有一个人能够发现其中的问题。这样的能力一般只有天才才能具备，我以前
遇到过一个。但是，如果我企图以这样的标准来招人的话，那就是在发疯，怎么还敢说“招人不难”？
说说可行的办法吧。一个程序员如果足够的谦虚，时时想证明自己可能犯错，即将犯错，或者已经犯错。那么他就会尽量写出足够多的TestCase，以便打消自己的疑虑。直到所有的测试用例全部通过，屏幕上显示出美丽的绿色长条，他才能确信，自己的代码没有bug。
所以，我的判断标准，也很简单。如果寄给我的代码，没有附带测试用例，我就自己运行他的程序，随意的乱找，找到一个我认为是bug的，那就是有bug了。如果寄给我的代码，附带了足够的测试用例，我只要Run一次，看到绿条，这一关就算是过了。～～～很简单吧。
也许有人会说，那如果他的测试用例很简单呢？岂不是不能说明什么问题？怎么不能说明问题呢？首先可以说明：这是一个会写测试用例的程序员！其次，我会看看他的测试用例的代码，大概覆盖了多少的功能特性。当然，这是更进一步的能力判断。但是至少，他的代码已经达成了他自己的设计了呀。
所以：“有bug的一律不要”，意味着，你最好能够自己证明自己没有bug，否则，我如果找到一个bug，你就没戏了。
posted @
2006-06-11 10:34 读书、思考、生活 阅读(29256) |
评论 (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 读书、思考、生活 阅读(28959) |
评论 (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 读书、思考、生活 阅读(28625) |
评论 (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 读书、思考、生活 阅读(29544) |
评论 (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 读书、思考、生活 阅读(29936) |
评论 (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 读书、思考、生活 阅读(30173) |
评论 (9) |
编辑 收藏