“知难行易”的定义是：要做起来容易,要理解却很难。认清事物（本质）是很困难的，实践（或行动）就要比它容易一些。这里到不说他与“知易行难”有什么区别，因为我发现这两者关系比较绕，到最后说的好像都是一个意思：干成个事还真是难啊！大概的结论是“如果是行得不够好，那就肯定是知得不够深。而且，要知得够深，也一定是不能脱离行的。”（1）

抛开这个论题，换一个视角：为什么软件开发一般是“知难行易”合适呢？比如TDD。有篇文章叫做The Design is Dead，说的人对架构师的角色期望全无。设计没有用，因为设计时不可能考虑到方方面面，还不如把这个精力花在代码上，用代码来体现的设计，只要遵循软件的一般标准或者重构的标准即可：大概是提高内聚、降低耦合、消除重复、提高重用。

学习数学，我们要先“知”：背诵各种公理定律，各种解题思路；学习建筑，我们要先“知”：本科就要7年，要观摩各种历史建筑，了解各种建筑流派，才能打好百年大计的基业。

软件则没有这么多的条条框框，学习模仿的活动很少：我又不是写一个OS，没必要了解虚拟内存，这个别人都替我做好了。这体现出了软件集成性很好，level高的没必要了解level低的。建筑则不同，一砖一瓦都是自己搭起来的，数学也一样各个定律都是独立的，没有包含的意思。

所以TDD之所以提倡卷起袖子就干，不要设计，是因为这里是不需要“知”的，而仅有的几个准则（内聚，耦合）是不足以用来指导设计的。（当然OS是需要预先设计的。）

1：我的野蛮成长 http://zbw25.spaces.live.com/blog/cns!BD4EFBFAF436336C!2913.entry