上周末写了一篇《面对高手们时的郁闷》，语气可能有点不大好。mikeshi看了貌似有些意见，还特地回应了一篇《毕竟是干同一个行业的》。而鹿鸣则认为做什么事做熟了都会倦怠，不论是Coding还是Designing。

看来我有必要再次说明一下我的观点。我一向是不太赞同所谓的“软件工程”以及与之相关的一切重方法论，因为我觉得对于绝大多数软件开发工作来说，这些并不是很有效的手段。我的观点是站在XP为代表的轻方法论和软件工艺这边的，Coding即Designing。

因 此，我不会认为Coding和Designing是对立的。但是我们现在很多情况是：相当多的Coder做的就是基本的印度式的机械化的Coding工 作，所做的只是把别人的设计翻译成代码。而问题在于，那些设计人员的设计又往往是高来高去的扯淡，脱离实际情况，二者的矛盾就必然存在。这也是为什么我一 直不太喜欢软件工程的说法。

其实设计不是什么玄事。建筑之所以需要设计是因为一旦开始建设，再要进行改动就要付出很大的代价。但软件开发不是这样的，在TDD的支持下，你可以在Coding的过程中，随时进行重构，调整设计，消除Bad smells。Designing存在于Coding中。

老生常谈没什么意思，主要还是为了澄清在《面对高手们时的郁闷》 一篇里的误会。我上面说了这么多，只是想说明，那天我们几个讨论的并非是什么高深的“设计思想”，我们也不可能谈那些高来高去的东东，而且这也与 BeLost的问题无关，我们只是谈了一下各自对此问题的实现思路，除了没有具体代码以外，并没有离开代码太远。但是他不能理解那个控件的代码，我们总不 能从Windows的消息机制开始给他讲一遍吧。再说，他出言不逊的时候，有没有想过我们的感受呢？

所以每次有人问到我关于线程的一些很基础的问题的时候，我都会建议他们去看看《操作系统原理》这样的基础教科书。因为我认为我没有义务为这些人补上他们应该在学校就学到的知识。

BTW：mikeshi又补了一篇《上一篇文章的中心思想》。不过他这篇把问题扯到决策者上去，那就扯得更远了，离题的话就不说了。

再补：令狐这篇《[技术]也谈设计》表达得更清楚。