就在昨天，就在我们的项目要结项的时候，一个影响力不亚于’广岛原子弹’的bug出炉了，蒙蔽我近一个月的问题终于被澄清了，不过为时已晚，项目即将上线，如果想彻底地解决这个问题，需要对整个系统的实现架构作调整，目前能做的只是’亡羊补牢’了。

这里先简单的说一下问题的原因吧！熟悉Unix编程的人都知道有’共享内存映射’这回事儿，我们的问题恰巧就出在对’共享内存映射’的使用不当上。由于我们使用的底层库采用的是mmap的匿名共享内存映射，所以这里例子中的共享内存映射默认就指使用mmap的映射。我们可以利用下面的一个例子简单说明一下我在项目中遇到的问题，实际上看完这个’精简版’之后你会认为这很简单亚，怎么会让你困惑一个月，的确是这样不假，但是如果加上了繁杂的上下文后，找起来也并不是件容易的事情。

假设我们有这样的4个进程，它们的亲缘关系是这样的：A是爷爷，B、C是兄弟，并同为A的儿子，而D则是孙子，是B的儿子，用图表示如下：
A
| —- B
|         |—-D
| 
| —- C
问题就出在D利用mmap映射到匿名设备上后，将返回的起始地址赋值给一块由A创建，B、C、D都继承并能访问到的共享内存中的指针。C的任务是读写这块由D创建的这块儿共享内存中的数据。明眼人一眼就可以看出，C是访问不到这块D映射的共享内存的，即使C知道那块内存在D中的地址，但是由于C没有映射，在C进程空间中即使访问那个相同的地址，实际上访问的虚拟内存页也是不同的，最终的结果就是dump core。不光是C就连B、A也都无法访问D的那块共享内存，原因这里不详说，任一本质量上乘的有关Unix编程的书都会讲到这一点。

出现这样的问题，自己有推卸不掉的责任，先撇开责任不谈，反思自己在查找bug过程中的行为，我觉得有两个问题是今后需要改正的：
1、始终质疑别人的代码，导致在查找bug的时候戴上了’有色眼镜’，思维也发生了倾斜，把大部分时间和精力都花在查找别人的代码漏洞中，而忽略了对自己代码的细致地分析。不过这个过程到让我学了不少以前未接触的’知识领域’^_^。
2、测试时态度不够端正。其实项目负责人当初就对这块儿的可靠性有质疑，只是他当时也不能具体说明到底哪个地方的使用会出问题，回头看来自己在测试时测试用例不全，也是导致没有及时发现对症问题的一个重要原因，从而失去了走向查找出正确问题所在之道的机会！

问题既然发生了，那么我们如何来解决这个问题呢？我和leader一起想了若干种方法结果都被我们一一否决，最后拿出了一个折衷的方案，该方案虽然不存在上述问题了，但是它也让我们的系统不能完全满足用户的需求。这个方案说来也简单那就是采用’池策略’，而且这个池也是一个扩展性不好的池，也就是说我们在系统初始化的时候就预先映射完毕所有的内存，这样所有的A进程的子进程都会继承A的内存映射关系，从而解决上述问题，不过这样做实际上就给系统加了一个限制，容量上的限制。

在接下来的另一个类似需求的项目中我们还需要使用这样的架构，而且这个延续的项目需要的系统容量更大，在这个系统中我们需要对整体的系统架构进行改动了，否则一旦出问题，就不再是’亡羊’就可以’补牢’的了！

目前部门内所有项目的架构基本上都是基于’共享内存’的，虽然’共享内存’是最快的IPC对象，但是它同样给系统带来进程同步性能低下、亲缘关系错综复杂等弊端，甚至于对于我们目前项目这样的需求都不能很好的支持。程序庞大，动一发而牵全身。当然对架构的改造也不是一朝一夕之事，需要的是魄力、时间和耐心，起码让我们的Unix程序符合K.I.S.S这种最适合Unix的文化，目前我们采用的这种架构还是比较臃肿的。

最近看了Eric S. Raymond的被称为开源文化圣典的'Cathedral and Bazaar'(大教堂与市集)以及他的另外一篇文章'How To Become A Hacker'，必须承认的是我不能够完全理解其中的内容，因为没有体验，或者说我还不够资格对Hacker Culture高谈阔论，所以这里仅作部分摘要，并说说自己第一时间的感受，望日后能温故知新。

在开始了解Hacker Culture之前我们应该知道'什么是Hacker'。Hacker不同于Cracker，前者指那些热衷于计算机技术，水平高超的电脑专家，他们把通过自己的实践而获得的知识广泛传播；而后者则尤指那些为了个人利益利用计算机技术搞非法破坏的人。像我们耳熟能详的Hacker先驱包括开源软件运动的发起人Richard M. Stallman、Unix之父Ken Thompson、C语言的发明人之一的Dennis Ritchie、Linux之父Linus Torvalds以及Eric S. Raymond等等。我相信这些人才是从事计算机行业的人们心目中真正的'Hero'。

'Cathedral and Bazaar'可谓是开源世界对Hacker Culture的一个阶段性的小结，当然Hacker Culture还在进化，其内容也在不断的丰富当中。下面是从'Cathedral and Bazaar'摘录的一些我觉得能够代表Hacker Culture的语句：

1.Every good work of software starts by scratching a developer's personal itch.
这里有一个生僻词itch，这个词有'发痒'、'渴望'的意思。这句可理解为“每个好的软件工作都开始于满足开发者个人的渴望或为开发者个人'抓痒'”。Unix的起缘可以很好地证明这一点。而现在的大多数商业软件的开发者则不能归为此类，原因不讲自明。

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
Linus之所以能独立完成一个操作系统内核，很大原因是因为他没有'从头开始'，而是利用已有的优秀设计思想。

3. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
Hacker也要'能上能下'。^_^

4. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
把用户当作协作开发者。

5. Release Early, Release Often
这与4相辅相成，互利互惠。Linux已经展现给我们一个Best实践，其“早发布、常发布策略”的一个效果就是利用快速的传播反馈修订来使重复劳动达到最小。

6. Smart data structures and dumb code works a lot better than the other way around.
优秀的数据结构设计总是至关重要的，在平时的开发中这一点体会破深。Brooks曾幽默地说："Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won’t usually need your [code]; it'll be obvious."

7. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
当你认识到你对问题的理解是错误的，这时不要灰心，因为一个具有革新性的解决方案也许正摆在你的眼前，我想很多人都有过类似的经历，Me,too。

8. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
是不是颠覆了你以前对好的设计的理解了呢？

9. To solve an interesting problem, start by finding a problem that is interesting to you.
趣之所在，力之所在。

10. Software is developed for peer recognition not for money.
至高无上的境界，不为'铜臭'打工。

这里再列出一条，这是在一位同行给Eric的回复中提到的一条："杀掉一个项目最快的方法是在你什么都还没有之前就宣布它，我已经见的太多了，尤其是在Linux世界里"，看到这一条相信很多曾组织或参与开源项目的人都会深刻的体会到，Me , too。

中国程序员在开源软件世界中的地位大家也都略知一二，我想这或多或少都与我们对Hacker Culture的理解有关。理解和认同'Hacker Culture'是你进入开源世界的第一步，正所谓思想的融入才是真正的融入。