免费打工仔的"自白书"

免费打工仔

原文发表在http://7dgame.com

“我是图形学界的芙蓉姐姐”

这句话有两个意思，其一是我确实因为Ogre的关系比较出名，其二是在图形学领域来说，我确实没什么聪明才智。

但是因为大家对我的了解，多是基于我对Ogre引擎普及工作所做出的一些贡献，所以很容易误解我是做图形学的人。本人师父确实是图形学高手，我师父的师父是发明OpenGL的彦博士（了解iQue的人应该知道我说什么）。所以按照辈分来说，OpenGL确实是我叔叔（汗，冷笑话）。但是本人确实愚钝，这个领域已经比较规范，本人也就没有在此有什么建树，所以我便依赖于Ogre图形引擎。多使用少而研究。

所以，既如此，我便虽是做游戏的，而非做图形学的。不希望有一些朋友或误认为我图形学厉害来仰视我，或因知道我图形学不厉害而鄙视我，大可不必。我确实不擅长，也从没在任何场合说过我擅长。

我不是天才，所以我是架构师

请注意，我是架构师，而不是引擎师。这涉及到结构重用和代码重用的区别。

小时候很多人说我聪明，但当我踏入软件开发届之后，发现这领域每个人都聪明，而且从来都不缺乏天才，大家各领风骚3、5年。

所以我很迷茫，当我看到《C++程序设计新思维》里面的一句话：只有天才的程序员，没有天才的设计师（设计师要靠大量的经验和失败来堆积而成）。的时候我看到了人生的曙光。如果我一生只做一件事情，不断的在此用工，那么对人类也会是有价值的。所以我如果不是天才的话，还可以做设计师。

所以，便有了Orz游戏开发框架。

架构是否有价值

很多朋友不认为架构有价值，特别是在游戏开发领域。大家批评我：“东拼西凑的烂柿子”，“什么也没做”，“基本没什么用出”。

但是我坚持还是有所原因的，虽然你并不一定认同，但我在这里也要说一下：
朋友你有做过项目么？你有做过失败的项目么？如果你有失败过，请你告诉我失败的原因。我所知道的失败的项目，没有一个是因为技术问题而导致失败。绝大部分（或者说是全部）是因为代码臃肿，开发混乱，团队离散设谢非技术原因而惨败。
让项目成功的方法有很多，但让项目避免失败的方法就只有一个，团队！

你是图形学天才？你能实现很棒的效果？那我要恭喜你。但一个项目做到很大的时候，1个人开发5个月的生产率是否等于5个人1个月的生产率？1x5 == 5x1？此时我们的问题回归到《人月神话》。
人和月是不能相互调换的！
《人月神话》出版了30多年，再版了N多次，可是还有很多人没有认同的意思：向一个延期的团队增加人手只能让项目更加延期。
1x5 为什么不等于 5x1。这是我们没有计算沟通成本的原因。
真正的公式是:n个人的效率=n*1个人的效率- n个人的沟通成本。
如果我们假设一个错综复杂没有框架的开发团队，每个人都要向所有其他人沟通，
那么这个公式就成为：n个人的效率=n*1个人的效率- （(n -1)^2）*沟通的成本
在此种情况下，增加人数带来的沟通成本会以2的次方数量增加。很快我们带来的效率就会被无情的浪费到任何人的沟通中去。
所以，对于任何想要形成规模的开发团队而言，最重要的是解开个体之间的沟通锁链，在一个最理想化的组织框架中，所有人只需要遵守一个原则，和一个公共知识库沟通。这时候每个人带来的沟通成本也只有1。
那么这个公式就成为：n个人的效率=n*1个人的效率- n *沟通的成本。
这种情况下，只要这个人的效率能大于它的沟通成本，那么增加人数会直线的增加开发进度。
而这就是架构存在的最重要的理由（只是在我的理解中，当然代码重用等等其他作用也是有的）。

所以：引擎是保证你开发成功的，而框架是避免你开发失败的。这就是Orz存在的原因。插件化离散化减少代码之间的耦合度，是Orz的任务。

架构之美
机缘巧合，我读到了架构之美的这本书。架构之所以重要，是因为他和组织密不可分的关系。架构和组织是会相互影响的。（举例来说，如果你用三个人的开发团队开发编译器，就得到了一个三阶段编译器）。不好的框架会影响公司的团队组织。

我这里有一个很有趣的案例：我的朋友也是作架构的，他的核心思想是封装，希望把所有图形引擎和其他功能性引擎封装到一个统一的接口中，这对逻辑开发者来说是很好的一个实现。但是它忽略了封装本身的难度，因为不论是地层引擎的变化还是上层逻辑的需求都会影响封装层的工作。这让中间这层很痛苦。
结果导致，在组织中，我这个朋友是主程，他身边二把手是维护封装的人，其他人开发逻辑。因为框架的原因，二把手是最痛苦的，经常和主程争执框架的问题，甚至希望自己重新写一套。而其他开发人员反而觉得框架很好（对逻辑开发的友好），所以也不理解二把手的处境，最后公司为了解决问题，不得已把二把手从上海调离到苏州。

在上面的案例中，我们清楚地看到了，对框架的设计，也就是对团队的设计。这点尤为重要。因为框架的价值是因为团队而产生的。

没错，这就是《人件》的意思。
开发软件，从来都是一个人的活动，而不是一个技术活动。
再来一边，如果你开发过失败的项目，请问你是技术的失败还是团队组织的失败？
我相信如果有经验的人或许都会有相同的答案。
框架之所以重要，是因为它是团队和程序技术的桥梁，但是最重要的远远不止这些，团队本身的维护又是一门学问。
在我的理解中。《人月神话》《人件》是灵魂
《敏捷开发》是骨架 《极限编程》《Scrum》《看板》 等等是神经网络。
我们的实践，是肉。
当我说这些的时候，有经验的人不屑一顾。没经历过失败的人更加不屑一顾。有经验的人往往有了自己的一套方法（很可能是自我总结出来的类敏捷），没经验的人更渴望学习着色语言。
所以我的人生，都是被好多这些老板，大牛以及一些天才的刚毕业的小兄弟所鄙视的。他们往往认为Shader是技术，而对团队的管理是狗屎。而我就是那狗屎上的一只苍蝇。当然，这些话我是充满着怨恨来说的。当我们这些狗屎作为肥料孕育出丰硕的果实的时候，你们可别忌妒。

贝克曾经说过：我不是天才，我只是用了正确的方法的普通程序员而已

我在赌未来
当年，我刚开始使用Ogre3D的使用，很多人鄙视我和Ogre。他们说Ogre效率太慢，虚函数太多。但我仍然坚持站在Ogre这边。今天很幸运，没想到计算机进步了，Ogre也进步了。竟然大家都开始用Ogre了，我也成为了“图形学界的芙蓉姐姐”。大家记得我不是因为我的能力高。而是因为我在这接近十年的时间内一直坚持为普及Ogre所作的贡献。换句话说，我不是刘翔！我是雷锋！

今天又开始了新的赌盘，我坚决地站在了敏捷开发和框架这一方，我坚信，随着游戏开发技术的普及，公司间竞争的白热化，游戏软件规模的扩大。软件工程和框架，将是以后未来的方向。

我为此付出，赌.博！会赢！

以下的话不是很好听，是给那几个鄙视我的小兄弟们看的。
小兄弟：你考我图形学的新知识，我当然不懂，因为好久没看了。不过只要给我时间上往上搜索一下，我就会给你答案。这些靠拷贝别人的轮子的事情我不觉得有什么光荣。我所作的事，是需要时间和汗水，无数次失败和成功总结出来的经验，是架构和团队，是一生的事业。我相信以你的聪明才智加上时间可能会超越我。但如果你们仍然不尊重框架和团队的话，我赌你永远不会产生出一个产品。我知道你们是技术天才，而我是做事情的人。 希望你们能成功，而我会看着你们的。

总而言之：

免费打工仔
是一个普通的程序员
是为Ogre普及作了力所能及的贡献
是希望用正确的方法维系团队
是希望能创造正确的架构
是希望能带来正确的价值的人

不是天才
不是图形学天才
不是年轻人

是雷锋，是芙蓉，不是刘翔！

x23105612

看到这个自白书。觉得 。。。。挺感动的。。。。。

kuki89

其实我觉得。
每个喜欢玩游戏，做游戏的人心中都是有着一个梦，对游戏的梦。

harr999y

我是新人，可我非常支持打工仔大哥所说的，架构是非常重要的，再牛逼的图形效果或者Shader都只能是Demo，只有成了一个全面方便高效易于扩展和修改的引擎才有其实用意义~
感谢大哥长期以来对于Ogre开源社区的奉献，正是因为你这种无私奉献的人的存在，才让我们这些刚入门Ogre的新人有了学习的方向。谢谢你对中国开源界的帮助，希望继续一路前行，早日赢得你的赌~博！

lgsnake

哥支持你，应用为王哈

52MARY

赞同免费打工仔的观点，只有真正失败过的人才会明白其中的道理。

总有些人认识自己的资本是高超的技术，结果确并不能为公司制造出产品。没有产品的公司注定会死亡，那你的技术又如何体现出其价值呢？

PS:虽然我不是程序员，但很喜欢OGRE。刚了买了你的书，周末都在看。

天策魂之音

虽然不继续研究Ogre了
但是好歹也看过lz翻译的N多电子文档
帮顶~

夜雨

6年前因一些原因而未见面，现在你已成斗士，希望6年后你成为大师。

ilymyq

路有很多条，没有什么高低区别，只是有的路好走、人多，有的路太艰难、人少。走在架构与应用这条路上的不只你一个，痛苦的是走这条路的人太少，幸福的也是走这条路的人太少。

TMeteorSnow

支持 免费打工仔！说的很有道理！