« 3d engine 中的贴图资源管理 | 返回首页 | 关于 getter 和 setter »

捣糨糊

这两天完成一个新需求，需要维护以前一个同事写的代码。

前几天花了一天时间读代码，好不容易都看明白了，感觉真是一团糨糊啊。苦不堪言。

要在以前设计的接口基础上增加新功能，我觉得是件非常违背我的美学的事情。如果就这么干下去，我会做噩梦的。所以一咬牙决定重构。好在是比较底层的代码，只有中间层调用这些接口，和上层无关。

大约删除了 2000 多行代码，重写加上新实现的功能，用了 900 行左右。接口数量，加上新加的接口，总数减少到原来的一半。

另外修改了调用这些接口的大约 30 个源文件。昨天晚上完成的时候已经是一点，似乎都眼冒金星了，才把整个工程编译通过。

今天战战兢兢的测试两天闷头赶出来的战果，上午居然一点问题都没有，让我心虚的很。下午找到一个 bug ，稍微安心了点。晚上解决掉提交了。终于舒心了许多。

精心设计，而不要过度设计，是多么重要的一件事啊。

不要以为你的团队每个人的水平都很高，足以理解你的每个”精妙“的设计。而一旦团队中真的每个人水平都深不可测了，那么，”精妙“的设计反而更容易被唾弃。虽然每个人都有能力看明白它。

所以、如果在十分钟内，不能通过讲解让一个新手明白这些代码该如果使用；或是不借助作者的帮助，一般人两个小时还读不明白；那么，就应该考虑是不是做出了错误的设计。即使你怎么看都没错，总有一天它也会被误用的。

另一方面，也不要轻易放弃设计。如果一个需求很难简单实现，又要考虑这又要考虑那，就不要随手实现了。可悲的是，如果手上的锤子越大，就越容易轻易把钉子敲下去。比如用 C++ ，轻易的加上几个类层次，弄点多态继承出来，最好再玩点模板技巧、来个操作符重载。搬出教科书，复制点设计模式。貌似轻易的把问题摆平了。

问下自己，真的吗？

一定要依赖语言高级特性才能解决的问题，设计方案一定有问题。相比较而言，如果你在用 C ，则不应该抱怨没有类，没有继承，没有虚函数；而应该庆幸你没有这些干扰思维、阻碍你做出真正简洁设计的东西。

少即是多。

云风 提交于 August 1, 2009 12:44 AM |

Comments

做什么事情都要有个度。

Posted by: 福利工口姬 | (21) April 16, 2014 04:07 PM

少即是多。 老子曰： 为学日益，为道日损。损之又损，以至於无为，无为而无不为 你了解的越多越宽泛，他的核心思想却越收敛，你再对他精炼了又精练，发现没给你什么，你也不再受约束却什么都可以做。 希望我没有翻译错

Posted by: mmosquito | (20) September 24, 2009 02:17 PM

从精心设计之后的那几段话，都深有同感啊~~~

Posted by: 风舞影天 | (19) August 12, 2009 04:13 AM

会做减法才是高手的智慧。 决定不做什么才是最难的。

Posted by: 赵中 | (18) August 3, 2009 11:12 AM

--精心设计，而不要过度设计，是多么重要的一件事啊。 过度设计害死人啊,深有同感。

Posted by: 辰玉 | (17) August 2, 2009 05:49 PM

博主忒牛啊 人才！！！ 赞一个

Posted by: zuixinyule | (16) August 2, 2009 03:58 PM

其实云风说的情况属于比较理想的状态，可是现实中复杂的需求和进度要求往往会使设计变得复杂起来，不是什么时候都有时间或者说是可以重构的。 就拿大名鼎鼎的UE3来说，里面的设计非常复杂，代码实现的也非常复杂，丑陋的补丁性质的代码比比皆是，单就是这样把功能给堆起来了，并且成功了。 整个UE3只有主体框架和底层数据结构类的东西是精心设计的，功能性的代码堆彻性很强。复杂的宏、大量的使用模板，感觉很多时候是靠着程序员的经验和对语言的深刻理解解决问题的。 曾经自己认为没有必要那么复杂，简单些多好，但是我自己写一个小的引擎框架的时候才知道实际需求很复杂，简单的设计几乎无法满足需要。也许存在即简单又能满足需求的框架，但是这种框架在写之前是无法设计出来的，只能通过重构出来，但是有时候商业产品不是想重构就能重构的。这也只能权衡了。

Posted by: fancy | (15) August 2, 2009 03:14 PM

"知道自己最终需要什么是特别重要的" 当策划自己都不知道自己最终需要的是什么的时候，程序不可能知道自己最终需要的是什么……不过就目前遇到的问题来说，其实纯粹是一种习惯，也就是任何数据成员都不能是public……

Posted by: sjinny | (14) August 2, 2009 11:41 AM

“可悲的是，如果手上的锤子越大，就越容易轻易把钉子敲下去。比如用 C++ ，轻易的加上几个类层次，弄点多态继承出来，最好再玩点模板技巧、来个操作符重载。” 对于技艺不精的程序员，这个诱惑很难抵挡。

Posted by: 啃饼 | (13) August 2, 2009 11:09 AM

呵呵,最近在看Kris kaspersky写的《优化代码：有效使用内存》一书。还是喜欢看云风兄写的有关优化提供思路的文章。 建议云风有时间写本类似上述的书，总结云风兄多年的编程经验和建议等，我想一定会和Kris kaspersky写的《优化代码：有效使用内存》一样好看

Posted by: Rainssa | (12) August 2, 2009 09:54 AM

楼上的情况就是云风说的"知道自己最终需要什么是特别重要的"

Posted by: chentan | (11) August 2, 2009 02:01 AM

云风对那种所有成员数据都写setter/getter的做法有什么看法吗……这两天试图精简三个太庞大的类，但是单单setter/getter就让接口数目变得非常多了……

Posted by: sjinny | (10) August 1, 2009 11:07 PM

无法体会你说的东西

Posted by: donkeyji [TypeKey Profile Page] | (9) August 1, 2009 09:46 PM

一定要依赖语言高级特性才能解决的问题，设计方案一定有问题。 =========================== 类似的话能否多总结点，就像前两天的“老人言”。。

Posted by: jay | (8) August 1, 2009 06:32 PM

云风的文章不太适合代码经验低于2年的朋友。 还是多code，多思考适合我

Posted by: xLight | (7) August 1, 2009 02:30 PM

@桂良 我觉得你留言之前还是先重构一下比较好...

Posted by: Ted | (6) August 1, 2009 02:29 PM

非常喜欢你这句“精心设计，而不要过度设计”！同感！ 然而，我觉得，多利用高级语言的特性来“精心”设计也未尝不可，毕竟，我们去读队员的代码，看到“对象”会比其他心里舒服多。 其实，我倒觉得，语言越高级，东西反而越少了。譬如C，甚至汇编，只要你愿意，你还是可以应用那些所谓对象、框架诸如此类的，甚至更多。还句话说，C甚至汇编也能写出类，不是吗？C编译器对程序员的约束少了，看似简单了，其实更复杂了。反而看Java，或者C＃，摆在你面前的是一套一套的东西，看似复杂了，但在开发的过程中，就反而简单了。 我现在正要重构一个项目，是以前公司一个老总写的。怎么说来着？用Java来写C的程序，即完全过程式！一个类的行数可以上到4位！读程序的我呀，真看的“呕心沥血”呀！ 所以，我觉得，那些所谓高级语言，并不会说会扼杀程序员的设计思想。只要我们能够站在不同的出发点看待问题就好。 再说，在现在讲求合作的时代，代码写出来了，并不是说能够编译通过，能够发挥效率就是好程序，更重要的是，能够给同行的看懂你写的什么。

Posted by: 桂良 | (5) August 1, 2009 10:35 AM

有道理，云风什么时候再出书，将经验传授一下也好，好让我们少走弯路

Posted by: Anonymous | (4) August 1, 2009 10:31 AM

C的接口确实很难设计，有时候看看Unix API的设计真的是觉得很奇怪，说不出来的感觉

Posted by: Anonymous | (3) August 1, 2009 10:15 AM

简单既是美

Posted by: Maya | (2) August 1, 2009 07:58 AM

呵呵，你也好晚睡哈!你是五年后的目标！

Posted by: zxboykiss | (1) August 1, 2009 01:41 AM

Post a comment

非这个主题相关的留言请到：留言本