好的设计
前几天说，想再写本书。许多朋友给了我支持。暂时我还写不了。因为：
工作真的很忙，很难脱开身。我觉得我在某种程度上陷进去了。需要花点时间整理规划一下。然后把工作的事情处理好。让它可以顺利做下去。不光是技术上要解决的问题，也不光是管理问题，也不光是团队合作的问题，也不光是项目开发运作的问题。反正很多很多，确实有很多麻烦。我要尽力做好。
觉得上一本没写好，是因为还是太仓促了。即使是已经写的那点东西，也积累不够。写书的经验也太少。我倒不怕有错误被人骂，是怕自己回头不满意。
如果再写，肯定只抓着很少的问题谈。但是具体写什么，还没全想好。积累是有了点，真能够拿出来写写的不多。毕竟，写书和写 blog 瞎扯还是不一样的。
孟岩建议我先在 blog 上列的大纲，然后随便写点。让同学们给意见，再逐步修改成书。我也有此想法，觉得不错。不过一开始，恐怕我连大纲都列不出来，就想到哪写到哪，随便写点东西吧。过段时间再把零碎想法串起来，作为正式列提纲的参考。
由于最近几年用的主要开发语言是 C 和 lua 。那么也打算以此为基础写。假定读者至少有不错的 C 语言基础了。我真正想谈的是，如何把一个软件很好的构建起来。到底需要做些什么。（从实现层面看）怎样才是好的软件。
那么有一个重点问题，也是老问题，怎样才是好的设计。
好的设计，必然是容易实现的。它可以很精巧，但不能难以理解。
太阳底下无新鲜事。软件行业已经发展了这么多年，你想到的东西，肯定有人都想到过了。
每个软件也都有它的生命期，我们只要在它的生命期内完成它的使命就行了。软件往往需要尽快的投入使用，然后在使用中演化。这个演化最大可能并不依靠你一个人的力量去推动。随着参与的人增加，人和人（指开发人员）的共性就会减少。每个人都看得懂可以充分接受，软件才不容易向坏的方面演化。
我们常常谈模块化，谈高内聚，低耦合。
本质上，就是如何管理复杂度。如何把一件很难的事情（开发一个软件），分解成小问题，分而治之。
这些小问题之间的千丝万缕的联系，是设计人员面临的最大难题。
有些原则听起来不错，但是坚持起来很难。
比如，让模块的输入输出没有副作用。你能让你的模块每个输入对对应着唯一输出吗？
又比如，让模块层次化。如果 A 模块依赖 B 模块，B 模块依赖 C 模块。一旦出现这个状态，你能保证 A 模块绝对和 C 模块隔绝吗？更有甚者，让三个模块循环依赖这种更糟糕的事情也并不鲜见。
抽象是个好东西。但借助不断的抽象，问题不断的包起来，演化成新的巨无霸，显然会让事情更糟。虽然最终可能真的能像搭积木一样去组装软件了。或是雇佣更多的程序员填表单一样的工作，相互不需要对方在做什么。但是，软件性能却下降到了不可以忍受的地步。bug 也隐藏的更久，更不可收拾。
好的设计，必须对问题有足够清晰的理解。有如庖丁解牛一般，把整个问题划开，在最薄弱的地方分离。其实，做到这点，也就够了。
解决这些问题，其实跟语言无关。语言之争是没有多大意义的。如开头所说，把设计做好，模块之间的关系，用足够简单的方式就能描述清楚了，大部分流行的开发语言都能做到。
用 C 来实作，而没有用它的近亲 C++ ，也是为了避免狭隘的争议：我们该用这个特性吗？该用那个特性吗？这个形式做是不是好点？那样会不会有更好的性能？
所谓开发效率，对于个人来说，语言之不同，是会有很大差异。但是那是实现层面的差异。对于完成设计，这个过程，效率和所用语言无关。
实现的阶段，程序员可不可以开心的放心的去完成那些接口，这就是衡量设计好不好的指标了。这个时候，一个高开发效率的语言有优势（更少的代码量），一个容易掌握的语言也有优势（可以让更多的人参于而少犯错误）。
对于我的团队，我会更乐于采用一种让实现人员更轻松的方式。不用理会太多的语言细节，不用在投入开发前学习更多的概念（尤其是这个项目独有的），不用特别严格的 code review 也可以允许大家提交新的代码，切不至于轻易的引入 bug 。
我相信，软件做到后面，设计人员不需要亲自写太多代码。虽然我现在每天还是大量的写，也并不觉得枯燥。
事必恭亲是不好，但并不是说，你给实现人员足够信任就可以放手的。真正让你放手的只能是，你做出了好的设计，无论是谁，他也写不坏它。这时，是你乐意自己写，还是多找几个同学帮忙写，已经不重要了。
Comments
很期待，慢慢写。这会是一本与《代码大全》一样实用的书，希望能和《编程艺术》一样给读者带来享受。
Posted by: alioxp | (23) February 4, 2010 12:06 PM
我也建议把《那些日子》弄成一本书。
Posted by: 云端孤鹜 | (22) January 21, 2010 01:37 PM
我也觉得《那些日子》不错，再整理就可以出书，这些东西反而是让人受惠的。
Posted by: 云端孤鹜 | (21) January 21, 2010 01:35 PM
那些日子 就是一部书啊。
不一定非要是技术的了。
我从头到尾看了2遍。
Posted by: tanxw | (20) January 19, 2010 11:53 PM
赞同.我用AS写过小3D(驱动.x文件)引擎,还有不少小游戏.现在用C写服务器.我想的只是如何设计数据结构,如何实现(设计、分离)小函数.
其实"理论"上讲,用C++也能做到这样编程.可总觉得哪有点不对劲.
Posted by: dodo | (19) January 19, 2010 07:13 PM
高手：
不妨做一个开源游戏或者其它类型的开源项目，然后书再结合实例一起讲你的思路，设计。
这个开源项目不需要多大，能表现你的编程思想即可。
期待贵作。
Posted by: 1 | (18) January 19, 2010 04:36 PM
期待中~ 希望书中能对抽象，还有模块依赖，耦合做详细的阐述，正反举例最好。还有，最最期望的是书中能有设计的beta1,beta2版，能让我们理解设计的思路，从刚开始到最后成型。
最后，非常喜欢博文最后一段~完美~
Posted by: atengzt | (17) January 19, 2010 02:53 PM
我觉得把《那些日子》再细化一下就是一本书。 讲了很多游戏界、开发人员的成长历程，很不错。
其实有时候人文比技术重要，就像《DOOM启示录》、《观止--微软构建NT的夺命狂跑》那种书， 很多人都喜欢看。
Posted by: wangdehao | (16) January 19, 2010 12:44 PM
13楼的DD应该多相信自己的手下们。
Posted by: To DD's words | (15) January 19, 2010 11:19 AM
设计思想是最重要的，同时实现的语言也是关键的，适合的语言更能贴近想法。
Posted by: 小子 | (14) January 19, 2010 10:07 AM
非常同意你在最后一端的观点:-P
Posted by: DD | (13) January 19, 2010 01:11 AM
云风比较完美主义，寄希望于先得到一个完美的设计，然后轻松的实现它。实际上，设计和实现是应该迭代进行的，我习惯先从一个简单的粗糙的设计就开始实现代码，在实现的过程中检验和修正先前的设计，多实现一点对系统就多了解一些，设计也就更靠谱一些。
关于语言之争，我一直坚持的一个观点是选择正确的语言对于软件生产力有非常大的影响。在云风这样对语言本质有着深入理解的人眼里，或许语言并不是很重要，但是现实问题是一个团队里大部分的程序员并不具有很强的编程能力，大多数只能算是代码工人而已。如何让这些人写出合格的代码？让他们去用C，可能连基本的模块化都保证不了，程序结构很容易就一团糟了，用C++至少可以给他们一个面向对象的思考方向，当然对于大多数代码工人来说，让他们用C++仍然是一件很让人提心吊胆的事情，软件的可靠性很难得到保证，而大量的使用脚本语言，在性能上又很可能会失控，另外可读性和可维护性也相当差。所以，在我的团队里我总是尽可能的把开发平台迁移到.net上，.net具有很低的学习成本，即使是新手也可以掌握，不用担心指针越界，非法指针，内存泄漏等等不可控的BUG出现。因此，在我的团队里，我基本上不会去review其他人的代码，只要可以快速的交付并且通过测试，代码里即使有很多坏味道也没多大的关系。
Posted by: analyst | (12) January 19, 2010 12:12 AM
我很喜欢数据结构和设计模式,软件工程这些课程.虽然学的不好,但是也断断续续在看,我的编程能力不太好.虽然很多朋友说我看的都是没用的,现在机器这么快.那么多现成的东西.即便他们这么说.我依旧觉得.编程的灵魂就是汇编和设计模式,数据结构.开发的灵魂就是软件工程.
Posted by: Favoue | (11) January 18, 2010 10:17 PM
我觉得云风只会谈细节，不会谈框架，文章也没什么条理，只会想到哪写到哪，如果写代码也这样，必定浪费太多时间。
早些时候云风的《大世界服务器结构设计》名字应该是这样的吧，我想应该挂了吧，那个设计太复杂，框架的设计应该越简单越好，那会不我懂游戏编程，还真相信了，最后自己把云风这个设计推掉了，甚至觉得那个设计真的比较垃圾。
Posted by: system | (10) January 18, 2010 09:45 PM
师兄，希望你能谈谈关于团队成员水平与成本控制的关系。
Posted by: EDISON | (9) January 18, 2010 09:26 PM
设计，贯穿一个产品从构思到终结的整个过程，这一切不是仅仅几个程序员能够完成的。至于什么语言什么技术，就更不重要了。
Posted by: EGameSir | (8) January 18, 2010 09:24 PM
孟岩老贼又要逼人写书，太可恶了，大家都这么忙，云风，果断放弃……
Posted by: abc881858 | (7) January 18, 2010 08:51 PM
列个大纲确实好啊，希望在2012之前能看到大作，要不然一切都太晚了
Posted by: 池中物 | (6) January 18, 2010 08:43 PM
加油！希望能早日拜读到云风的大作！
Posted by: zhangbiao | (5) January 18, 2010 08:41 PM
云风的上一本书看的是电子版，若再写书，肯定会第一时间订购，对云风真的有一种膜拜的感觉
Posted by: skytop | (4) January 18, 2010 08:31 PM
沙发？
看了这些索引类的信息，我觉得这本书会是我很想读的一本书。我近期正投入到一个使用嵌入Lua的架构的程序，不过不是游戏，于是很多时候很多特性（功能）常常在到底用什么实现中犹豫，宿主？纯Lua？Lua的扩展库？选择多了，也是个很头痛的事啊！
Posted by: missdeer | (3) January 18, 2010 08:22 PM
终于又有新作了，上一本书很喜欢，希望能早日读到新书。
Posted by: 江波 | (2) January 18, 2010 08:21 PM
云风哥说的在理啊。设计才是软件的精髓所在。老实说微软的C#还是非常不错的，极大的简化了开发过程，让开发人员更加关注实际的业务应用。
Posted by: songsu | (1) January 18, 2010 08:20 PM