分类： tech

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的注释方式，可以自动生成代码。

Variant如何使用及相关步骤

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

（更多…）

在西方的传说里，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

第六本，C专家编程（C和C++实务精选），douban链接http://www.douban.com/subject/1232029/

第七本，C陷阱与缺陷，douban链接http://www.douban.com/subject/2778632/

这两本书都是将近20年前出版的超级经典好书，个人认为，只要c语言还被使用，这两本书就不会过时。这两本书也都是C和C++实务精选这系列丛书中出类拔萃的两本，字字珠玑。另外推荐大家如果有闲钱，可以另外买下面这两本：《C++代码设计与重用》，《C和指针》。

《C专家编程》这本书很有意思，里面不少内容被不少企业作为面试内容出现，比如我常看到的这个“如何不使用临时变量确定链表中存在重复”，还有“数组和指针有什么区别，什么时候相同”等等，不过最后一章关于c++的论述因为时代关系，可以跳过不看。

第八本，《C++标准程序库自修教程与参考手册》，douban链接http://www.douban.com/subject/1110941/。这本书可以作为案头书使用，对于c++中的template，介绍的那是恰到好处，没有任何炫技之处，整体风格就是德国人典型的认真、朴实、实用，如果想在项目中使用模板技术，这本书一定要放在手边。

最后两本很难选择，感觉剩下的基本上可以战成平手，故此更细化一些，大家可以根据个人喜好来选择。

如果专业是windows桌面编程，建议如下两本。

第九本，《Visual C++技术内幕》，译者潘爱民，链接http://www.douban.com/subject/1027574/，第十本，《Win32多线程程序设计》，译者侯捷，http://www.douban.com/subject/1231702/。

这两本算是我入门时候看到的好书，尤其是第九本，非常之经典（新版本好像评价不高）。如果使用MFC及COM开发，这本书可以让你一步一步照着做，免得没有头绪。而且还有个优点就是介绍的比较全面，windows桌面开发可能用到的技术基本上都有涉及。这本书也是推荐我最喜欢推荐给公司新入职同事的，非常有帮助。第十本关于多线程，个人觉得一个Windows程序员如果不了解多线程，那就不能算是一个完整的程序员（笑），如何进行线程同步，如何使用锁、事件、句柄这些东西，这本书介绍的非常仔细。

而且这两部书的译者都非常不错，翻译的口碑相当不错。另外插一句，孟岩、刘未鹏也是国内译者中我很喜欢的，他们翻译的书都有质量保证。

如果关注的不是windows桌面开发或者MFC开发，可以选择这两本书。

第九本，《代码大全》，http://www.douban.com/subject/1477390/，作为一个程序员，应该反复读读这本书，里面的内容很浅显，道理很实用。没错，我很喜欢强调使用，这么厚的一本书，不需要一口气读完，可以有针对性的读读里面某些章节，比如7、8、9章关于程序的，18章关于表驱动方法的，22章开发者如何测试的，都是看了就能用的内容。

第十本，Effective C++，http://www.douban.com/subject/1842426/，这本书介绍了55个非常实用的，没错就是非常实用的C++编程条款，相比herb sutter的书，这些条款可以算的上脚踏实地，比如什么情况下应该写拷贝构造以及赋值函数，虽然有些章节略微难一些，但是实用性还是比较高的。

有的朋友推荐《深入理解计算机系统》这本书作为入门，我回家又翻看了一遍，感觉不选是对的，《深入》作为教材系统学习是很有用的，也建议大家有空读读，但是实用性相比来说差了不少，可以让大家深入理解，但是无法写出好的代码。个人浅见，写代码之所以成为一个手艺，是因为它可以在模仿前人的基础上达到一个比较不错的水平，而《深入》这本书可以让工匠往大师的方向发展，对于初学者来说，不是必要的。

另外，一个程序员应该多少了解一些软件工程思想以及涉猎一些代码开发边缘的书籍，《快速软件开发》《微软研发制胜策略》《writing solid code》（最近有引进影印，网上有不错的翻译）《代码阅读方法与实践》，另外C++ FAQ和C FAQ都可以在网上找到，这都是非常值得读读的。作为一个C、C++程序员，最好再涉猎一门脚本编程语言，如果对web开发感兴趣，可以学学php，入门极为容易，有c基础就行。或者看看python，是google主推的编程语言之一，桌面网络开发都可用。

终于写完这十本书，感觉前面五本相比后面来说容易写的多，也许是自己读的少（推荐的我都读过，而且感觉不错），也许是经典也就这些的缘故吧。