個人檔案陆其明 - 逐日相片部落格清單更多 工具 說明

lu qiming

職業
居住地
興趣
《山海经》记载:“夸父与日逐走,入日,渴欲得饮。饮于河、渭,河、渭不足;北饮大泽,未至,道渴而死。弃其杖,化为邓(桃)林。”
第 1 張 / 共 25 張

陆其明 - 逐日

穷则独善其身,达则兼济天下!
17/2/2009

CString是MFC类吗?

答案是:曾经是,但现在不是了。这个问题困扰了我一段时间,因为时不时会在非MFC的项目中看到别人使用CString;只是这类技术细节也不是什么大不了的事,以往并没有深究。今天突然来了点兴致,在MSDN上查到这样一段话:
 
ATL/MFC Shared Classes
Beginning with Visual C++ .NET 2002, several existing MFC utility classes were rewritten or revised to reduce their dependencies on other MFC classes. These utility classes can now be used in any native C++ project. This section only includes classes that were previously available to MFC projects and have now been shared, plus a few new classes related to the changes in CString. It does not include the ATL classes, which can be used in any native C++ project type by inclusion of the appropriate header.
 
 
Classes Shared Between MFC and ATL:
 
31/12/2008

改变自己,改变世界

一段很不错的墓志铭,跟大家分享:

When I was young and free and my imagination had no limits, I dreamed of changing the world.

As I grew older and wiser, I discovered the world would not change, so I shortened my sights somewhat and decided to change only my country.But it, too, seemed immovable.

As I grew into my twilight years, in one last desperate attempt, I settled for changing only my family, those closest to me, but alas, they would have none of it.

And now as I lie on my deathbed, I suddenly realize: If I had only changed my self first, then by example I would have changed my family. From their inspiration and encouragement, I would then have been able to better my country ,and who knows, I may have even changed the world.

21/12/2008

《代码之道》勘误表

由于《代码之道》一书整个出版过程比较仓促,在我把译稿交给出版社、出版社编辑同志完成修改之后,出版社并没有把修改后的译稿发回给我复查。结果是,书中出现了一些悖离原文的翻译,可能会给读者带来费解或误导。(毋庸置疑,我对全书精神的把握肯定要比编辑同志好一点。)这不完全是编辑同志的错,更多是出版流程上的问题。本着严谨、务实的态度,出此勘误表。参见http://blog.csdn.net/happydeer/archive/2008/12/21/3574823.aspx

 

11/12/2008

访谈录:中国的软件业需要悟道

1.      记者:目前,随着中国IT业的发展,国外IT企业对中国IT业也越来越重视,能否简单介绍一下目前中国外包情况?

陆其明近几年,中国IT业的发展确实比较快,特别是软件行业。你可以看到,全国各地都在建软件园,各级政府对软件企业也都有政策倾斜。软件企业的发展如同雨后春笋一般。遗憾的是,国内众多的软件企业中,很少能制造出有自主知识产权、并且拥有广大用户群的软件来。为什么呢?原因可能有很多,但我觉得最关键的是“土壤”问题——国人对知识产权的尊重意识不够。很多人都没有花钱买软件的习惯;企业做出来的软件没人买,那何以为继呢?于是,很多软件企业做起了含金量不高的定制项目,做起了软件外包。看一下前不久刚刚统计出来的数据吧:中国软件外包2008年第3季度的规模已经达到45.3亿人民币。看起来,中国的软件企业活得还不错。也很有意思,您的问题里没有提软件,而直接提到了“外包”;看来在中国,软件就等同于外包了J 中国的软件有了规模,但我认为中国离软件强国还有很远的距离。

 

2.      记者:您目前在哪家公司就职,在公司中扮演怎样的角色?

陆其明我目前在速尼软件(上海)有限公司工作,担任Qflix部门的工程经理一职。速尼是一家美资企业,专业从事多媒体内容的制作、管理、娱乐等软件的开发,在欧美享有良好的声誉。好莱坞的很多DVD都是通过我们公司的高端软件制作完成的!而公司的使命,更是要把好莱坞的娱乐体验带进千家万户寻常百姓的家中。再说说我所在的Qflix部门吧,这是一个新成立的部门,主要从事按需生产DVD的产品研发。听说过“长尾理论”吗?我们的产品能使这个理论在DVD消费领域变成现实。市场前景很不错哦,很有革命性!我本人主要负责中国这边的研发工作,以及相关的项目管理、沟通和协调。

 

3.      记者:在一个项目中常常会遇到怎样的问题?

陆其明建一栋房子是一个项目,造一架飞机也是一个项目,但我们这里只说软件项目。软件项目中可能会碰到的问题实在太多了:需求不清,需求经常改变,设计不合理,人员不够,人浮于事,计划太紧,代码太乱,毫无流程或者流程混杂,沟通不畅,软件Bug太多……任何问题处理不当,结果都可能是:不能在规定的时间内交付给客户符合他们的需求、达到他们的质量要求的产品或服务。那就是项目失败!

 

4.      记者:如何提高一个项目的开发效率?

陆其明一个项目能否成功受到很多方面因素的影响。而且各个项目有各个项目的特点,不存在统一的、放之四海皆准的、能确保项目高效成功的方法。但总体来说,人才是第一位的。我们国内不缺高素质的软件人才。再则软件流程也很重要,国内软件企业在这方面很薄弱,不过即使是国外的企业也不见得个个都很强。再则就是沟通,因为沟通永远都是个问题。再则……人才、流程、沟通,不分先后顺序,个个都很重要,个个都大有可为之处,做好了都能提高项目的开发效率。但是,迄今为止,没有哪个方法能够彻底解决软件开发过程中的所有问题,哪怕你采用最近几年很流行的敏捷软件开发过程。软件行业里有句名言,叫做“软件开发没有银弹”。因此,我认为,在项目实践中不必刻意去套用一种“完美”方法,而在项目过程中建立起一个持续反馈、自我改进的机制才是最有价值的。

 

5.      记者:作为一个项目管理者,您是如何建立一支高效的软件团队?

陆其明这是每个管理者都关心的问题。毕竟,谁不想拥有一支骁勇善战、能够百战百胜、建功立业的团队呢?!当然,为了建立一支高效的团队,有很多技巧可以应用。但我觉得更重要的,还是要提高我们管理者自身的素质。那就是如何让自己成为一名优秀的管理者?难吗?其实一点都不难,你只需要做好下面两件事:(1)确保你的团队能够正常开展工作;(2)把你的团队成员真正地当人看,而不是只把他们看成是资源。(呵呵,这些我也是从《代码之道》一书中学到的J

 

6.      记者:我知道您最近翻译了一本软件职场方面的专著,书名叫做《代码之道》,在市场上这方面的图书并不是很多,能谈谈您对这本书的感受吗?主要针对读者人群有哪些?

陆其明是的,我前段时间翻译了一本叫《代码之道》的书。虽然书名里有“代码”,但书的正文中没有出现任何一行代码。这本书阐述的是“道”,软件之道!我还要说的是,我太喜欢这本书了;不是因为我是这本书的译者,而真正是因为这本书的内容本身。这本书太贴近现实了,非常有启发意义——如果你把书中的“微软”换成你所在公司的名字,把“Windows”、“Office”换成你所在公司的产品名字,你会发现,整本书好像就是在说你们公司的自己事一样。说的是事,讲的是理,悟出的则是道。太精彩了!

《代码之道》适合所有软件从业人员阅读。这本书,管理人员读起来会更有味道;但被管的人读一读此书,同样能够受益匪浅。我写过四本书,翻译还是第一次。不管我的翻译功力多么稚嫩,也顾不上“王婆卖瓜”之嫌,我真心向大家推荐《代码之道》。

 

7.      记者:这本书给你感受最深是哪个部分,为什么?

陆其明说起感受最深的部分,我想应该是那些关于“管理”的篇章吧。这包括了第1章的“项目管理”和第9章的“人员管理”。原因可能是因为这些话题比较贴近于我现实的工作。我是做技术出身的,管理对我来说存在着天然的障碍。为什么这么说呢?因为技术注重的是细节,而管理注重的是大局。技术出身的管理者一不小心就会陷入过于关注细节的泥潭,也就很难真正地把管理工作做好。因此,管理对我来说是个挑战,是一个需要我不断提高的领域,也是我目前的兴趣所在。通过阅读《代码之道》,我对如何克服管理上的障碍信心更强了。当然,我并不是在贬低这本书的其他部分。每个读者的知识框架是不一样的,各人有各人的实际情况。如果你对软件过程改进比较感兴趣,那第2章会比较符合你的胃口;如果你对效率很看重,那第3章定会让你大受启发……总之,大家见仁见智,各取所需吧!

 

8.      记者:最后一个问题,目前又是一轮企业招聘的时节了,希望您能谈谈应届毕业生在职场上应该注意什么,或者说给他们提一些建议吧?

陆其明时下受金融危机的影响,很多企业都在削减开支。一大批企业倒掉了,或者开始裁员,同时也停止了招聘。因此,我认为眼下的就业形势不容乐观,2009年可能还会更加严峻。至于应届毕业生就业问题,可能还要更难一点。因为大部分应届毕业生都是白纸一张,他们最缺乏实战经验,而这跟企业的用人条件是背离的。遗憾的是,很多应届毕业生还自我感觉良好,做起事来却是眼高手低。结果呢?他们对企业创造不了什么价值,难怪一些企业订下潜规则:“绝对不招应届毕业生……”但谁不是从应届毕业生过来的呢?作为过来人,我能给出的建议是:要认清当前的形势,认清自我的情况,始终保持一种谦虚、学习、积极向上的心态,“大处着眼,小处着手”,兢兢业业把事情做好。没错,应届毕业生年轻、思路开阔,但企业支付给员工薪水不是因为员工的能力,而是因为员工给企业创造了价值,也就是为企业做出了贡献。能力和贡献之间并不是直接的等号关系!要经常问问自己,你对企业的价值何在呢?如果说个人能力是进入企业的敲门砖,你在工作中也能保持良好的心态,那在一个企业工作达到一定级别之后,你会发现,个人的智力和行动的速度对职业生涯的进一步发展起到的作用已经不再明显。这时候,你的沟通技能以及自我管理能力就显得非常地重要。当然,这些都是后话了……

14/11/2008

温昱书评:读《代码之道》

索然无味、毫无观点的书永远引不起人们的阅读兴趣。放心,《代码之道》绝对不是!

 

形式上,本书中的每一篇文章都通过讲故事等方式提出问题,然后分析问题根源,最后给出改善建议。其中,问题的提出往往极具戏剧效果(作者也坦承“为了达到效果,我又一次夸大了问题”),这样一来,凸显了问题的巨大负面影响,且使阅读过程变得有趣。于是,当捧书在手时,产生欲罢不能的感觉,也就并不奇怪了。

 

¨        不必说“我认识一些架构师,他们的生活都是失控的”、“回到现实世界来吧,到别的经理手下干活也未必解决问题”这些亦庄亦谐的话点到了人的痛处——现实就是这样的!

 

¨        也不必说“你总是在伤害你爱的人”、“了解并接受你所选择的生活方式”这些富有哲理的话让人顿生错觉——本书的上架建议真的是“软件工程”?

 

¨        单是“管理层不切实际”、“如今,大家都在跨部门合作上空口说白话”这些你想说又不敢说的话就足以“抓”住你——此书我得好好读读!

 

定位上,本书不仅是实用建议录,也是深入思考集。书的字里行间,透着作者的良苦用心:不仅“推”给你体现其多年经验精华的实用建议、医“病”良方,更要“拉”你就一线开发中的关键问题进行深入思考、对比分析。这是十分值得赞赏的。即使在我并不认同作者阐述的某个观点之时,我对作者“引发思考”良苦用心的赞赏也未减一分。

 

内容上,都是和一线的“软件工程师和工程经理”息息相关的话题。首先,是软件开发流程。第1章,谈了项目管理方面的经验。第2章,核心观点是“敏捷,但应理性”。第3章的真正含义不是“停止写规范书”,而是“为了提高协作效率,建议采用非正式文档”。第4章,阐述开发者和测试等其他角色之间的关系。第5章谈质量,质量=业务上有价值+工程上无Bug。第6章讲前期设计。……是的,过程管理、项目管理、沟通管理、角色设置、质量管理、前期设计,这些正是软件开发流程关心的。

 

除此之外,本书有30%的内容覆盖一线开发者和经理成长的话题。例如,我很喜欢第9章。作者为经理们提供了实用建议:如何识才、如何面试、如何帮助平庸员工、如何避免团队“内斗”……。很中肯的良方。

 

有趣的是,这本书的很大一部分我是在外出讲课的火车上读的,而读此书的感觉恰似坐在晃动的火车上——它不容你的大脑懈怠,因为让你“为之一振”的观点会以极高的频率不断“跳”出来,冲击力十足。

 

¨        “有没有一种方法在大产品和小团队之间的缺口上架起一座桥梁呢?答案是肯定的,有!那就是架构。架构最重要的一点,就是它能把难以处理的大问题分解成便于管理的小问题。”非常到位的总结。我在架构培训中也常讲:架构要设计到什么程度呢?第一要支持并行的详细设计,第二可根据团队和项目情况灵活调整,第三业务层和通用机制应更深入设计。

 

¨        “工程的本质就是要真实地知道,而不是靠猜测。”言简意赅,却切中肯綮。

 

¨        别的公司,团队里有交互设计师、文档专员、过程经理等角色,你的公司要怎么做的?“如果那是一款很熟悉的产品,目标也很明确,那么你可能不需要很多的专员。如果那是一款不常见的产品,目标也很模糊(至少对于工程师来说是这样),那么你需要较多的专员。”这就是《代码之道》给出的回答。

 

¨        ……

 

 

经验,对软件从业者的重要性,怎么强调都不过分。而在本书中,作者无私地分享了他过去在软件行业6个不同的公司、28年的职业生涯中提炼出来的经验。相信大家都能从中找到自己需要的。