捣糨糊
这两天完成一个新需求，需要维护以前一个同事写的代码。
前几天花了一天时间读代码，好不容易都看明白了，感觉真是一团糨糊啊。苦不堪言。
要在以前设计的接口基础上增加新功能，我觉得是件非常违背我的美学的事情。如果就这么干下去，我会做噩梦的。所以一咬牙决定重构。好在是比较底层的代码，只有中间层调用这些接口，和上层无关。
大约删除了 2000 多行代码，重写加上新实现的功能，用了 900 行左右。接口数量，加上新加的接口，总数减少到原来的一半。
另外修改了调用这些接口的大约 30 个源文件。昨天晚上完成的时候已经是一点，似乎都眼冒金星了，才把整个工程编译通过。
今天战战兢兢的测试两天闷头赶出来的战果，上午居然一点问题都没有，让我心虚的很。下午找到一个 bug ，稍微安心了点。晚上解决掉提交了。终于舒心了许多。
精心设计，而不要过度设计，是多么重要的一件事啊。
不要以为你的团队每个人的水平都很高，足以理解你的每个”精妙“的设计。而一旦团队中真的每个人水平都深不可测了，那么，”精妙“的设计反而更容易被唾弃。虽然每个人都有能力看明白它。
所以、如果在十分钟内，不能通过讲解让一个新手明白这些代码该如果使用；或是不借助作者的帮助，一般人两个小时还读不明白；那么，就应该考虑是不是做出了错误的设计。即使你怎么看都没错，总有一天它也会被误用的。
另一方面，也不要轻易放弃设计。如果一个需求很难简单实现，又要考虑这又要考虑那，就不要随手实现了。可悲的是，如果手上的锤子越大，就越容易轻易把钉子敲下去。比如用 C++ ，轻易的加上几个类层次，弄点多态继承出来，最好再玩点模板技巧、来个操作符重载。搬出教科书，复制点设计模式。貌似轻易的把问题摆平了。
问下自己，真的吗？
一定要依赖语言高级特性才能解决的问题，设计方案一定有问题。相比较而言，如果你在用 C ，则不应该抱怨没有类，没有继承，没有虚函数；而应该庆幸你没有这些干扰思维、阻碍你做出真正简洁设计的东西。
少即是多。
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]](https://blog.codingnow.com/nav-commenters.gif)
| (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