维特根斯坦说“凡是能够说的，都能说清楚；凡是不能说的，就应保持沉默。”
在我看来，这仍然是一个“边界”问题。之于软件工程，Team Leader经常教导我们一句话“编码是个次要问题”（兴许援引自《人月神话》）。当我们想要实现一个用例，一个功能时，我们的确不急于着手码代码，而是应该自问：你能否用自然语言，把这件事情（需求）有条理有逻辑的表述出来，尤其对于核心业务内涵和外延的描述，包括措辞力求严谨，这就是划清边界。而程序语言是比自然语言更严谨、更富逻辑性的表达工具，如果用简单的自然语言都不能清晰的把业务各个层面的边界厘清，那就更不用指望写出整洁的代码了。
当然，要做到“不畏浮云遮望眼”是很难的，因为大多时候我们不是“只缘身在最高层”，而是“不识庐山真面目，只缘身在此山中。”我在我的短博文“什么是架构”里也提及过，架构是不断否定之否定，逐渐划清边界的动态演进过程，“架构演进即架构”这个讲法也不是我甚至也不是我们的Leader提出的，类似思想大牛们早有提及。然而它的确是站在认识论高度的恰当总结。回到维特根斯坦那句名言，再去审视“编码是个次要问题”这个观点就不难理解了。在动笔之前，很大程度上应该有这样一个尽最大努力去厘清当前问题边界的一个过程，如果能有个清晰的视图在心中，那写起代码来就是“胸有成竹”、“下笔如有神”的酣畅淋漓了，因为能把它说清楚；反之，如果脑中一团乱麻，疑云团团，根本没个头绪，那就是基础工作还没有做到位，该做的调研、沟通、查阅资料、整理思路等工作还是欠缺的，此时应该“保持沉默”。凡事都有个度，有些问题光想也是想不开的，以上所说的prepare工作，就像微分学中的线性主部，是要解决大方向问题，解决矛盾的主要方面。如果努力把以上问题克服，此时可以动笔编码了，尽管此时还是谨小慎微探路前行，但轮廓是清晰的，意识的能动作用会牵引着你逐渐拨开云雾见青天。
之所以说，这个认识过程是一个划清边界的过程，是因为当我们去认识、定义一个实体是什么时，一定是有其他参照系，知道它不是什么的，就像择青菜时，我们知道我们要食用的菜不是混在其中的杂草、烂菜叶并将其剔除。回过头来，当我们编码建模时，比如使用java中的class时，你会怎样理解它呢？我们可以说一个class是具有共性的一系列对象的模板，从文件/资源组织的角度也可以说它是一个命名空间，用于标识资源的位置，也可以说它是一个容器，用于盛放数据和函数等，不管怎样理解它，但我们自问，有多少人真正的从边界划分的角度去理解类这个东东呢？事实上，以上提及的几种对于类的理解，边界仍在其中。随意的创建类文件，随意的分包，随意的使用限定关键字public、protected、private、default，虽然使用着OO语言但却充斥着大量的贫血域模型——仅把一个类退化成数据对象（相当于一个Map，那置基础引用类型以及集合框架于何地？），甚至lombok的出现使get/set方法都“省去”了等现象很常见（这里并不是说这样做不对）。“其大无外，其小无内”，在系统的各个层面上，当我们不去仔细的审视问题边界时，大到架构、小到一个函数的逻辑，盲目就开始编码时，也就是混乱的开始。因此，“凡是不能说，就应该保持沉默。”
