重构和设计模式

免费打工仔

楼上是一个有经验的人，对于你的说法绝大部分我是赞同的。

但是对于后面两点因为我所处的领域有自己的看法。产品是一个点，能够“能够顺利发售”就好了，这没错是符合市场原则的。但对于企业或者开源社区来说，就不同了。因为企业的经营和社区的建设是一个线的工作。我们必须不断的演化和重构（不仅仅是软件）以及建设才能保证健康的发展。

国内的状况也和楼上说的一样，但是对这种状况的纵容。导致比如网易，巨人，暴雨这些大型公司再有一个好的作品之后就很难继续下来。这或多或少和他们做“项目”的观点有关。

开源社区在这方面算是做的不错的，很重要一点是他们不计较“浪费成本”，不仅仅作项目，还做“教育”和“培训”。每个软件不停地持续的重构和改良，比如Linux和apache的版本进化都是很小的。这符合敏捷的“小步骤持续迭代”的观点。一个软件在开始的时候“很搞笑的代码，很搞笑的设计，以及很搞笑的BUG”是很正常的事情，但这并不能怂恿开发者“已经知道的BUG，但是已经发售了，卖了30多万份，这就足够了”的观点。

我希望大家以经营企业的观点来看待游戏，不要以经营项目的观点来做。瞄准一个项目的公司往往如旅游景点的买卖，做一次就好了（没错现在这种状况，确实是做一次买卖就能赚一辈子的钱）。但是随着类似完美这种流程化比较强的公司的进入，竞争越来越激烈，利润空间越来越低。所以持续的良好的可重用的框架和代码的价值越来越高。

记得当年史玉柱说网络游戏界的营销如同小学生一样，然后把保健品的团队全都带过来做地推。这种对行业的“破坏性”创新，导致从貌似红海的网游行业异军突起。

不知道大家是否认同，国内游戏开发行业的规范化和流程化，和一些大型软件公司比（不说国外，甚至连东软中软这种公司相比），都还是“小学生一样”。基本没有规范，都是靠毅力，体力，脑力居多。这时候有一些较规范化的公司进入，以较低的成本和风险，良好的框架进入这个领域，是否能再找到一片蓝海呢。

可能上面说的事情很多人不赞同，很多人可能已经在做了。

不管看法如何，这种想法足以让我“免费打工的”做一次实践了，所以我做了http://class.gd这个项目。

最近看一本书，叫做“黑天鹅的世界”，说的是经验虽然很有价值，但是能从经验中总结出来的问题往往不会影响你的人生，哪些无法预测的（比如美国911）事件，这种不可预测的黑天鹅，才能改变整个世界的进程。所以呢，我希望去探索这只黑天鹅，虽不一定成功，但却依然努力。仅此而已。


==================================================

补充一点，楼上说的人员问题，人员流动问题。不仅仅在《极限编程 -- 拥抱变化》中有办法解决，在另外一本几十年前的著作《人件》中也有观点。

你不能解决人员流动问题，但你可以通过良好的方法让这个影像尽量降低，比如让人员在项目不关键的地方离职。或者“代码公共所有权”，“结对编程”这些都可以降低人员流动的成本。

我想，XP不是企图改变世界什么，只是希望这个世界可以向更好的方向迭代而已吧。

tarkey

不要忘记一点，软件工程是为产品服务的，对于游戏这种创意型软件，天生就注定了他不可能有可持续性。即使是同一款产品的第二代，都是翻天覆地的架构变化。从暴雪的魔兽1->2->3到魔兽世界的，或者说从席德梅尔的文明1->2->3->4也能看出来，这就是为什么我一直要说削弱软件工程在游戏业的影响。市场也再三的证明同一款模子里出来的两款产品必定是失败的，这也是为什么每一款游戏都会带来巨大的研发挑战。即便是游戏的通用引擎类似虚幻这种规模的引擎也不是在重构中诞生出来的，虚幻2和虚幻3的架构那是天壤之别。

对于游戏开发来说，程序的作用要尽量的削弱，取而代之的是美术/策划/动画的作用要加强。换句话说，我一直对于软件业的书籍持怀疑态度，这个行业的进步不是由书本来带动的，而是由各种各样出色的项目来带动的，所有的研发概念，以及整个软件工程的概念都是在项目的研发成功之后才慢慢形成的。而项目本身的需求则是日新月异，你根本不可能预料到明天会出现什么新的软件，所以任何的所谓开发经验，大部分情况下都是过时的知识。

举个最简单的例子，项目中发现了一个BUG，如何来设计开发体系，让我能在看到BUG的5分钟之内就判断出这是谁的BUG，是美术，是程序，还是动画，还是音效，软件工程里面有告诉我们怎么做么？

补充：
正好想起一件事，05年在北京一家公司的时候，发布一款休闲网络游戏，服务器端一运行个4，5天就出问题了，老板把我发配到运营商那去，给我一个礼拜，让我不解决问题就卷铺盖走人，这种情况下重构能顶个球用？别跟我提单元测试，你单元测试的设计还可能出现漏洞呢，纯粹就是脱了裤子拉屎还接根管子，没事找事么。

tarkey

另外来个AOE的，说说我对开源项目的看法。
市场经济的情况下，开源项目纯粹就是一个笑话，缺乏组织，缺乏压力，随心所欲的开发，纯粹是把软件开发当成业余爱好在玩而已。别拿apache和linux说事，这两个东西要不是IBM和SUN在背后大力支持意图和MS抗衡，根本不会流行起来。我以前也很崇拜open source，多好的精神，多么崇高的做法，后来发现“责任心”这一点在开源项目中很难得到体现，人们拿开源当喝茶，用的是过时的技术（新的技术实现出来没人会开源，这点从ACM的各类论文中可以得到充分的体现）。然后告诉使用者，你要用可以，只不过你用了之后的项目也得开源，这不就一传销么，这哪是为用户着想，摆明了完全为了自己的兴趣爱好而已。

我曾经花了一年多的时间为MUDOS（曾经最火的MUD网络引擎）这个LGPL的开源东西做过贡献，一段300行的代码，出现各种不同的编码风格，各种不同国家语言的注释，这真的是软件开发的最高境界么？我严重表示怀疑。

我始终觉得，软件行业的进步，离不开市场经济，如果不是市场和用户在用最挑剔的眼光选择产品，这个行业永远不可能前进的如此之快。

免费打工仔

有一点你误会我了，我并没有否定传统的开发理念。只不过觉得并不是传统一条出路。
好的游戏当然需要天才和创意的完美结合，就如同全聚德烤鸭大餐一样。没错天才是可遇不可求的。
但是游戏行业也有另外一种需求，比如教学和外包行业，就需要有严格的流程来保证质量和效率。那么这时候就需要肯德基的做法来定制游戏了。

所谓工业化就指的是从手工业作坊到大规模工厂，而者之间最重要的环节就是流程化，标准化。当然不是说工厂就能替换掉手工业，现在很多奢侈品仍然是天才们手工业的结果。

我说这两段的意思是，当然“05年在北京一家公司的时候”这些事情你可以按照自己最妥当的方法去做，XP最重要的信条就是：“请记住XP不是唯一的开发方法”。没错XP不是全部，只是一种比较好的方法而已。我们可以有选择的，有取舍的引用。

但现在的问题是，需要有人把这些实践拿出来给大家看，看明白哪些适合那些不适合。这就是我所做的工作，http://class.gd。


另外关于开源软件，建议你看看《大教堂和市集》这本书，里面阐述了为什么开源界能产生有质量的好的软件。

你说Linux和Apache是Sun和IBM的支持，当然我同意有这样一部分原因，但我更相信IBM和Sun得到开源的支持更多。这是一个互惠互利的情景。比如Ogre3D图形引擎，目前并没有得到比较大的公司的支持。但仍然发展的越来越好。PHP就更棒了，在社区内孕育出一家Zend公司。开源的项目比比皆是，为什么兄台只看到了失败的呢。

对于兄台参加的MUDOS代码质量，我觉得你做的很棒。找到了问题所在“一段300行的代码，出现各种不同的编码风格，各种不同国家语言的注释，”。但我们还需要找到这个问题的解决办法。至少在Ogre3D社区内是这么解决的：“保持核心人员的精简和强壮，并执行好的规范”。我不知道MUDOS的领导者有没有看过《大教堂和市集》这本书，开源组织的众多参与是在Debug和新的解决方案的探索上的，而不是核心开发上的。如果MUDOS的老大能理解这一点，我相信MUDOS会取得良好的成功。

关于商业价值，那么开源软件确实不如商业软件来得多。但是人类所追寻的就只有商业价值么，我曾经这么问我自己。如果把商业软件比作企业的话，那么开源软件就是宗教。一个更高级的组织形式。有自己独立的教义（开源协议），低成本的普及方式，教皇和众多的活动。国内不知道有没有游戏企业能做过超过100年的，但开源软件只要服务器还在，那么就会永远的流传下去。这是开源软件天生的优势，在Ogre刚诞生的时候，因为运行速度等问题，导致被业界接受程度较低，但是因为其非商业的特质，连续十年不间断的开发，今天看来至少不差的太多。如果我们继续维护辖区，搞不好哪天就能超过商业软件呢。

不注重商业价值并不代表没有商业价值。为什么Sun,IBM等公司下血本的支持开源行业呢，是他们学雷锋么。似乎不是。因为开源行业天生符合：“软件即服务”的理念。这个理念并不新鲜，在数学界，很早以前使用公式是需要缴纳版税的，不知道哪个高人哪天发疯了，把所有的数学公式都开源了。今天数学家并没有饿死，而是靠服务来赚钱。

这就是软件的未来。当然您可以说，有些事情不适合软件，有些事情不适合游戏，有些事情不适合中国，有些事情不适合我。

但 这并不能阻碍我进行实践的工作。如果我的理解是错的，那么至少让我遇到这个错误再说。


（目前为止 开源 和 XP给我个人带来的荣华富贵是不可想象的，所以我才这么支持开源。当年我用开源软件建立社区和企业，最后企业并购给另外一家公司，现在的女朋友也是在这个企业中找到的。可以说，我的绝大部分人生，是开源赐予我的，所以我很感谢开源领域。我深深体会到了贡献越多收获越多的理念，XP也同样带给我快乐，这是我支持开源和XP的原因，至少现在看来，我并没有疯掉。）

PS.对于你所举的例子，我是很赞同的。但是我们要清楚世界发展是螺旋形上升的。还是那本《黑天鹅的世界》告诉我说，哪些不能用经验来总结的事情才是最能影响人类的事情。欧洲人用一千年来总结：天鹅都是白色的。但到了大洋洲，他们发现了一只黑天鹅，导致这一千年的经验都作废了。因此所以就算西德梅尔或者卡马克没有使用XP或者开源元件，这并不能阻止我进行这些尝试。搞不好这是一只没有发现的黑天鹅呢？

免费打工仔

“换句话说，我一直对于软件业的书籍持怀疑态度，这个行业的进步不是由书本来带动的”

至少在亚马逊的图书排行榜上 《人月》，《人件》和《设计模式》这几本20多年的书目前还没过时。软件发展才不到一百年时间，和建筑业其他工业的发展阶段不一样。所以才有很多伪科学和容易淘汰的东西存在，比如瀑布式开发。但不能这样就认为，软件科学都是伪科学。有一些至少是有价值的。我老大曾经说过一句话：外国人不都是傻子，搞了几十年的软件工程，应该有点价值。

XP不是软件科学或者经验，他给自己的定义是一门人与人沟通的应用科学。软件本质上是人和人之间的活动的结果。虽然是不可预测的，但我们可以出版《心理学》读物，为什么不能出版《极限编程》呢。这不是一个经验的总结，而是一些应用科学，没人能说XP是最好的实践，但是相对一些更糟糕的实践来说，XP还算得上一个选择。


关于“脱了裤子拉屎还接根管子”的有趣问题，我希望Martin Fowler先生北京访谈录里面的一句话可以帮你解答：
Martin Fowler：当然（值得花一半的时间来写单元测试）！因为单元测试能够使你更快的完成工作。无数次的实践已经证明这一点。你的时间越是紧张，就越要写单元测试，它看上去慢，但实际上能够帮助你更快、更舒服地达到目的。

全文地址在http://class.gd/node/35
Martin Fowler是何许人：http://www.china-pub.com/main/sale/renwu/luminary.asp?id=89

我看到您说的：“所以任何的所谓开发经验，大部分情况下都是过时的知识”
这句话是不能反对的真理，没错，不要局限于开发经验，就如同你05年的开发或者0x年的项目一样。虽然用一些方法解决了问题，但我们并不能证明哪些是最好的方法。就算在那时候是良好的“经验”，但到今天来讲搞不好就是“过时的知识”。所以我们应该进一步实践，把已有的知识和现在的项目结合起来看看结果，有机的吸收和萃取。这一点我和你的想法完全一样。

再说一点点废话，世界上只有数学是证明出来的，绝对准确的。其他科学包括物理化学，都是在“实验”的经验上总结出来的。导致这些科学不停的被推翻，经典力学->相对论->量子论。最小粒子也不断被找到，“原子”本身就是一个笑话。

我们这里很多的朋友有很多的经验和经历，但是这些就如同物理的“实验”一样，不能作为决定性的推断。经验这东西可以拿来看，但不应该成为我们探索新的世界的负担。不要被白天鹅蒙蔽双眼，总有一天会找到那只黑天鹅的存在。

最后一句话：在游戏软件业无数痛苦的加班和项目的失败，让我更加坚信了如果用正确的方法可以快乐的成功的完成代码。回到学生时代那种生活。

小小C

学习

tarkey

学习别人的知识是没错，任何书籍都是前人在经历了项目的挫折之后留下的感悟。只是完全的照搬所谓书上说的内容就完全不靠谱了，正好去年年底听了Stan Lippman的讲座，其中一句话说他们发明了UML，不过在他们的项目中却很少使用到UML，这就正好的验证了一点，大多数概念的发明者，并不是某个概念的受益者。盲目的遵循书本知识来进行开发本来就是一件很愚钝的事情。

透过现象看本质，任何的软件开发如果脱离了项目本身的目标而去追求所谓的“编程艺术”就是错误的，没有项目也就不会有软件开发这个课题，在这个大前提下所有的规划、成本以及需求都应该是紧扣项目本身来进行设计。或许你目前的项目你自己就是用户，你可以给自己提很多需求，这些需求就包括了对代码有一定的要求，这种项目本身就不具备普遍性，或者说永远是个无法结束的项目，因为你在开发的过程中学习进步，那么自己的需求也会不断的改变，这种事情我自己也做过很多次，只不过我对其定位比较清楚，纯粹的学习，和项目无关。

如果你认为软件开发是一件很轻松的事情，我只能说你还完全没有认识到这个市场竞争的残酷性。大多数时候让你痛苦的并不是所谓的软件设计，而是硬件设计的缺陷，以及时间、资源和来自其他公司的竞争压力。软件开发竞争很残酷，如果你还没认识到这一点，只能说明你还没有入行，只是生活在自己的世界里。

你做开源软件，当你发现有其他人已经做过了一些功能，你可以简单的拿来使用，但是软件开发则完全不是这么回事，你发现其他人做过一些功能，那么你就要做的比他们更好，更高效，成本更低，你才有可能生存下来，这也是我身边很多程序员最后顶不住市场竞争的压力，都自我安慰的去做开源项目。殊不知一线的研发人员个个都是软件工程应用到极致的人，只不过他们嘴里不愿意成天挂上一些别人听不懂的名词，因为他们知道从嘴里说出来的话如果没有人能听懂，就如同废话一般。

我曾经也很喜欢装B，主要体现在当时新浪游戏开发论坛还很火的时候，以自己阅读过多少什么什么书而自豪，也喜欢研究一些旁门左道的东西，后来真正碰到实际项目中各种挑战的时候，才发现项目要能做出来，比什么理论都重要得多，这也是近些年来我越来越尊重做出实际产品的实干派，哪怕他们用最简单的，最过时的流程在进行开发，他们在整体项目中对团队，对质量的控制力是旁人远不能及的，这也是他们能在市场经济中屹立不倒的关键。

免费打工仔

只是完全的照搬所谓书上说的内容就完全不靠谱了
这句话我双手赞同，应该结合实践去辩证的去读书。“尽信书不如不信书”。不过对于游戏开发领域里面的规则和流程知识，不是尽信和不信的关系，反而是不读书和读书的关系。信和不信至少要先读书才好。我在极地课程里面的工作是这样的，我先去读书，然后实践，最后辩证。信与不信我还没有什么资格去讨论，先要读书是必要的。没错吧。

透过现象看本质
我不反对，但应该更进一步来说，通过实践看本质。有些事情不能道听途说，国内很多人都透过“现象”来批评XP和其他一系列东西。问题是没有实践过，怎么有资格来评价呢。或者部分实践就全然否定，就如同吃了西瓜皮就说西瓜苦一样。还是上面那句，先读书在实践最后辩证。

如果你认为软件开发是一件很轻松的事情，我只能说你还完全没有认识到这个市场竞争的残酷性
我并不认为软件开发是一件容易的事情，我经历的失败的项目远远比成功得多。但是我仍然坚信，这种状况可以改变。所以我才去极地课程里面探索新的出路。这样比喻吧，我走了一些道路了，都是“不轻松”的加班和失败以及裁员和跳槽的过程，和一些消极的朋友不同，我仍然认为这并不是一个必然的状况，仍然有改变的可能。XP说他可以解决，在我没有自己的出炉的时候，为什么不尝试一下呢。搞不好下一条路就能走通呢，下一次开发就能轻松呢。还是黑天鹅的世界，一万次白天鹅（痛苦的开发）不代表世界上都是白天鹅，只要有一线希望我们仍然要去探索黑天鹅（轻松愉快的开发过程）。我坚信，所以我持续的实践。

都自我安慰的去做开源项目。
对于这点我也同意，程序员除了挣钱之外，很多人也有展现自己的目的，就如同手银（不是错字，是和谐）一样。不过这是一部分，另一部分确实是开源社区不停的壮大和发展。比如p2p领域和web服务器领域以及网页脚本领域都是开源的比较先进。正如同你所说，做技术我胜不过微软，所以我只能做开源。历史上和微软斗争的公司，除了投靠开源的，还真没剩下几家（剩下甲骨文？）。没错当不能sex的时候hand job也是一个选择。


我曾经也很喜欢装B
可能我说的话让人家觉得实在装B，确实我也浸淫在这种感觉中。不过我认为，我本身的工作极地课程是有价值的，首先来说对别人没有伤害的。如果是我错了，至少能把整个错误过程展现出来，之后可能就不会有人再犯同样的错误了。如果这个实践证明是有价值的，那么一定会对这个行业有点益的。如果没有伤害到别人，还可能对别人有点帮助的话，这种B装一下也可以，你说不是么？


综上所述，楼上的绝大部分观点我都是认同的，不过：

曾经有人做过一项实验，把一只跳蚤放进一个玻璃杯里，这只跳蚤迅速灵活地跳出杯子，于是实验人员在杯子上盖上了一片玻璃，跳蚤不停地往上跳，经过反复地努力，还是跳不出来。过了一段时间，当实验人员拿开玻璃片，跳蚤偶尔跳几次，根本跳不出玻璃杯。

因为我们不是跳蚤，所以失败并不能成为我们继续探索的阻力。

PS.楼上说05年的项目来看（已经是服务器主程之类的，我那年还是小弟），看样子应该算是前辈。多年开发的经验让您可以不必要依赖软件工程就可以完成很多很好的项目，这些是我们这些小弟们可望不可及的事情，但请不要其中失败的经验强加给后来人，让其不要去继续探索，前辈失败的经验应该是我们继续探索的动力，而不应该成为我们后来人的阻碍。江山代有才人出，各装牛B三五年。现在我也成了老人了，把我们的好的经验坏的经验都总结下来，留给后人评述吧。如果我们能客观的记录下来，并不计较其商业价值的留给后来的人，相信是一件不错的事情，不是么？