宝贝孙秀楠 – 第 31 页

也许有的朋友会说，为何一开始不考虑优化？作为一个老程序员，基本的一些常识还是有的，比如不去反复调用一些初始化操作，GetCount或者是GetSize这样的操作不放在循环里面进行，但是运行性能问题还是会发生。在最后的时候优化，算是一个比较好的时机，因为过早优化会没有目的性，既然客户端没有进行实际的调用，怎么知道那些操作会带来性能问题呢，只有跑起来才知道。

我们项目是一个组件程序，通过COM接口被其他程序使用，设计为了简单，将一些数据放在注册表里存放，另外其他大部分数据都是读取一个格式化的文本文件（EDS）来获得的。程序的整个结构是单线程的，同一个进程中，任何一个复杂操作都会阻塞其它调用的进行。

代码优化的重点是放在初始化这个阶段，因为我们需要读文件来构造整个系统，这其中牵扯到注册表操作以及文件操作和对文件解析生成特定的实例（instance）。

注册表的优缺点暂不评论，但是它的性能真的是很成问题，注册表是典型的key-value结构，按理说读取速度应该很快，但是它真的很牵扯性能，这个地方的优化做了一些，但是本质上没办法做更多的优化，个人倒是比较喜欢一些简单的数据库作为程序后端存储，比如很多公司都用到的sqlite引擎，支持sql语言查询，性能还算是不错，应该可以作为一个很好的替代品。问题是类似东西可能有license引用的问题，这个就比较复杂了。

我们组里另外一个同事针对注册表操作做了一些改进，估计这方面也不能做的更好了。所以注册表方面暂借不管，主要精力放在内部代码改进。

首先必须要做的就是收集数据，看看那些函数调用费时间。好在我已经有现成的log以及高性能计时器类，只要包含一下就可以。有的朋友会说log文件有多线程问题，计时器有多cpu问题。没错，但是我们程序是单线程的（见前面说明），所以写文件时候不加锁，另外尽量只建立一个全局log实例，保证创建、关闭文件操作非常少，而且也不进行内存new/delete操作。为何不使用OutputDebugString？好问题，这个函数可能导致一些时序上的问题（可以搜索codeproject上面有介绍文字），可以用，但是不如写文件那么simple。感觉这些也许是问题，但是还是尽量简化这些工具，够用就好。

经过性能数据收集，发现读取、解析文件使用时间不多，相比来说将数据序列化类实例比较耗时，因为我们加入了很多验证的函数调用，导致新的代码比前一个版本需要更多的调用。当然可以去掉这些验证，但是那我们还做这个新版本干嘛呢。

根据现在得到的数据，主要下面一些改进：一个是将一些集合类加入对map的继承关系，相当于重新又包装了一次抽象。原因是我们在查询这些集合类的时候都是使用的循环for-loop调用，相比map的查询，就差了不少。（学过数据结构的朋友应该了解stl的map查询性能要好很多，因为内部一般是用树状结构实现的）。另外一个改动就是把一些不必要的初始化操作放在后面进行，这样就导致我们需要在一些函数调用时加上它相关的初始化调用，代码复杂了不少，但是也没有办法。还有一个常用的手法就是使用cache，把一些运算结果缓存起来，下一次就直接拿出结果使用。cache最好在后期有了具体数据在进行，因为过早的优化，过早的加入cache机制不见得是正确的。为什么这么说呢？因为cache有一个可能失效甚至出错的可能，真正的结果可能因为某些数据变化而产生变化，如果这个时候cache系统不知道，那么就出错了，如果加入事件消息来刷新cache，也许就会让代码变得过于复杂，不容易维护和理解，也许性能还不如简单的版本快呢，就如同奥卡姆剃刀原理提到的那样，复杂的往往都是错的，或者是错误的根源。

总结说就是使用正确的数据结构，适当使用cache。如果这些还不行，那就得具体问题具体分析，后来我加入了更详细的log信息，发现用户端对于同一个文件做了多次的初始化调用，这也是优化时候需要注意的，客户端代码也需要相应的优化，也许它们的优化才是最关键的。虽然没有拿到客户端优化的结果，但我相信这个修改会比我前面做的任何改进都要显著，而且未必改动很复杂。

总的来说，这次代码改进不算是很成功，主要是一开始的方向不太对，尽管后来发现了真正的原因。我想主要问题是一开始就把目光聚集到非常微观的范畴里，导致大的问题没有得到解决。另外对于程序优化这件事，必须有实际的运行数据，猜测哪个地方可能会慢或者有问题，都是不客观的，在优化问题中，不应该出现“我觉得、我想”的字眼，什么地方慢什么地方需要改动，一定要用数据来说话。优化必然要对代码做这样那样的变动，这时候我们累积的test case就非常有用了，可以帮助我们确定代码改动是否引入了错误。

不要用一个模子制造所有东西 – 软件开发的复杂宣言

http://www.noop.nl/2009/03/the-complex-manifesto.html

noop.nl是一个比较关注开发方面的博客，里面有些文章很有意思，比如这篇。

我平时喜欢到toplanguage这个开发群组里去看看有什么讨论的话题，发现很多人有一种习惯，自己比较喜欢的一种语言或者模式，就喜欢推荐给别人，当然，本意不是坏的。经常会出现类似情况，前面一个人提问一个相对还不怎么具体的问题，后面就跟上来“这个问题可以用xx解决”或者“这个是xx语言擅长的”，也许也对，但是未免以偏概全。用标题的句子来说就是试图用一个模子去制造所有的物件。

就如同文章里提到的，人们倾向于简单的解决方式，可是我们也要意识到，真实世界比我们想象的更复杂。

作者提出一个复杂宣言，大意如下，后面的注是我的想法。

Each Problem Has Multiple Solutions

每个问题都有不同的解决方案。

注：显然如此，而开发者经常需要做的就是权衡抉择，从不同方案里尽快选择一个可行的。相比保证方案的完整性正确性，行动起来往往更重要。

Solutions Depend on the Problem’s Situation

解决方案依赖于问题的具体情形

注：Erlang不是万能的，java、ruby、python不是万能的，软件开发没有银弹。一个问题，如果用basic就可以快速解决完成，那就是好的。一个高并发高性能的设计方案，如果没有真实运行起来，没有实际数据的证明，那就是个纸上谈兵，都是假的。

Changing Context Requires Changing Solutions

改变了环境（需求变化？），也需要变更解决方案。

注：同样的，没有银弹，没有万灵药。

Some Solutions are More Prevalent Than Others

一些解决方案比其它的更流行

注：没错，ruby on rails是很火爆，django也非常有名，但未必就一定适合你，选择好的不如选择对的，尽管有时候对的长得不一定好看。

For Every Solution There is a Best Situation

对于每个解决方案都有一个最佳的时机

注：这句话稍有些拗口，不过可以这样理解，“这个方案为何不用c++？”ok，也许那时候c++还没有发明出来，“为什么会有1M内存限制这么傻的东西？”那时代，1M内存就是高配了。也许现在看来一些很愚蠢的选择，当时也许都有一些必须的原因。

Solutions Change Themselves by Changing Their Situations

解决方案通过改变它们的运行环境来改变它们自己

注：解决方案改变了环境，环境改变又需要改变解决方案，一个互相影响互相作用的关系。

Understanding Complexity Helps in Applying Simplicity

对复杂度的理解可以帮助应用的简洁

注：可不可以这样理解，对问题理解的更深刻，也许解决起来未必就很复杂。比如网上流传的那个电风扇吹空盒的故事。

It Is Impossible to Predict the Best Solution

不可能预见到最佳的解决方案

注：邓公不是说过吗，摸着石头过河，不可能一下子就找到最佳的过河地点过河时机的。只有走出这一步，才是最重要的。

最后有句话我非常非常欣赏，相比那些绚丽多彩的技术（敏捷、scrum、用例、用户卡片），我们更应该关心“什么时候用什么”。推荐大家读读此文。

关于编程的一些想法

1，编程关键就是两个方面，数据结构以及相关函数（或者说算法）。

2，对于我们现在的这个项目，里面分成两层，一个是接口层，负责COM接口，一个是逻辑层，是真正做事情的。这种分发未必就一定最好，但是实用性不错。

3，程序员最常用的一个解决办法就是递归，递归的难度在于：必须先在脑袋里构造出一个层层递进的逻辑过程，用人脑去模拟电脑的运行过程。

4，项目开始，必须定下来如何Log过程，如何进行自动的unit test，用什么无所谓，但是必须坚持。所谓坚持，就是不断的增加test case，不断地根据需求修改unit test。

5，使用visual c++，编译时打开level 4的警告，可以对代码做一个非常有用的lint。相信很多人也不知道lint是什么，打开就好了，然后根据提示修改代码，尽量减少警告。

6，不会算法无所谓，不会某些语言特性无所谓，但是，不会思考，那就完蛋了。

7，所谓代码质量保证，两条而已，unit test以及code review。

8，代码有了坏味道，一定要改。起一个有意义容易理解的函数以及变量名；长函数改短；删掉不必要的参数；重构重复的代码；确定让函数只做一件事；使用c++标准而不是微软的扩展。

9，使用doxygen的注释方式，可以自动生成代码。

没有丑女人，只有懒女人

废话不多说，先看这个神奇贴：

http://www.tianya.cn/publicforum/content/no11/1/679202.shtml

或者到这里http://user.qzone.qq.com/349448609

说实话，就如同后面朋友留言一样，我看到第一张照片，也以为是“表弟”，根本不会认为是“ 表妹”。

女人，如果过了23岁，那就是三分长相、七分打扮了，会不会倒持自己，分别真的是很大啊，不信的朋友，看看这个帖子就知道了。气质加上化妆，可以让人大变脸。

太神奇了！太神奇了！

VARIANT研究

Variant如何使用及相关步骤

VARIANT是一个结构而不是类，这是比较容易混淆的一个地方。所以，当我们要使用或者返回VARIANT类型，必须做以下步骤，不能假设客户端使用的是CComVariant类型。

继续阅读“VARIANT研究”

神奇的2009年2月13日

在西方的传说里，13号星期五是很不吉利的一个组合，号称是黑色星期五，而情人节的前一天恰恰就是一个黑色星期五，不知道是什么寓意。

当然这其实不奇怪，黑色星期五碰到的几率还是很大的，我想提到的是这个数字：1234567890。

熟悉unix系统的朋友可以试试，这个时间戳（timestamp）到底是哪天，

% date -r 1234567890
Sa 14 Feb 2009 00:31:30 CET
%
% env TZ=US/Eastern date -r 1234567890
Fr 13 Feb 2009 18:31:30 EST
%
% env TZ=US/Pacific date -r 1234567890
Fr 13 Feb 2009 15:31:30 PST

没错，就是今天！这个时间再次出现的时间估计是人类毁灭之后了（never happen？）。
另外，现在大部分unix族的操作系统好像已经都把时间转换到64位，Year2038基本上是不会产生什么问题了。

相关信息来源：
http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20090205_2120.html
http://en.wikipedia.org/wiki/Year_2038_problem