代码之外的结构

    我在各种场合一直都在强调结构问题是独立的，在程序语言之外存在着独立的，可研究的，富有成效的结构问题。[url]http://canonical.iteye.com/blog/147424 [/url]在这个方向上更进一步，我们注意到所有的代码并不是天然出现的，而是由人所编制的，因此代码世界内部并不构成封闭的，自足的某个世界。代码中的结构问题并不是由代码本身完全解决的，即在代码之外仍然存在着技术上可研究的结构问题。

    我们在编制代码的同时也在编制着大量的说明文档。这些文档描述了代码片断之间的相互关系，描述了代码未来的扩展方向，描述了代码之间的可能的交互方式，同时也描述了针对现有代码实现的很多具体约束。例如我们在文档中约定某个量要在10和20之间，但在代码中却不一定显式进行了判断。针对代码结构的很多具体约束条件和相关性描述可能只在文档中体现，只在程序员的头脑中存在，而并不一定忠实的在代码结构中得到表达。

    我在设计领域基本持有一种物理实在论，即某种技术相关的约束应该在技术世界中通过技术手段得到表达。只是这里的技术手段却不一定指在应用中加上特定的代码实现，虽然我们在代码实现中更直接的表达设计要求无疑是需要提倡的。为了在程序中有效的维护结构相关性，我们并不一定需要抽象出所有可能重用的代码，并不一定需要确保某一概念在程序中只有精确的唯一的表达。程序中难以直接精确表达的弱关联，仍然可以通过开发/设计工具等技术手段得到有效的维护。我们需要保证的是代码世界中知识的自恰性，而自恰性并不等于唯一性。http://canonical.iteye.com/blog/33788

    在Witrix中我们采用一种物理模型驱动的开发方式，http://canonical.iteye.com/blog/29412 由pdm模型出发，自动生成hibernate的hbm文件，java实体类，元数据meta文件，前台Action注册文件等。生成的配置文件通过 syncWithModel标记与模型保持着稳定的关联。所有配置文件都支持手工修改，开发工具识别syncWithModel标记，当pdm模型发生变化的时候，工具自动将变化信息同步到各个配置文件中。注意到这里并不是采用一个统一的元数据模型的方式，各个配置文件所表达的信息在一定程度上是重复的，也可能是不一致的。例如后台数据库允许保存100个字节，但是前台meta中我们可能配置只允许录入20个字节。根据不同应用场景的需要，我们可以在各个层面对每个配置文件进行独立的调节. 当然,在一般情况下并不存在这种需要。整个开发过程中，信息表达的自恰性并不是在应用程序代码中得到定义的,而是因为开发工具的存在而在技术上得到保证的。放松模型之间的唯一匹配要求，我们可以得到更加丰富，更加灵活的软件结构。实际上我认为RoR(RubyOnRails)采用直接映射的 ActiveRecord的方式虽然有效保证了系统变动中知识的一致性，但是如果不允许在各个层面上都能够自然的定义某种偏离，它在复杂应用中的价值就要打上大大的折扣。

评论

5 楼 uda1341 2009-03-07  

canonical 写道

文档矛盾之处其实很多时候在人的语言层面的理解有一定的容忍度, 大家可以形成某种语境环境下的共识. 很多没有精确定义的概念在一定的语境下在人的思想层面并不会产生很大的误差. 但是要是打成某种精确的一致性,并始终维护它有效,则成本就高多了. 这样说其实已经有些哲学化了. 从实际操作上说, 现在大量的信息仍然处在代码之外, 我们能够以代码表达但却没有表达的东西非常之多, 必然是要发展大量技术手段来捕获这些代码之外的概念.

非精确表达所带来的好处我是承认的，我也同意，目前的技术手段在捕获代码之外的概念时非常的蹩脚。

我所指的说明文档，是那些定义代码结构，流程的说明文档。把这样的说明文挡精确化，代码化，变成程序代码的有机组成，实际上也是一种AOP的概念。写说明文挡的工作，是编程的一部分，并不会增加工作量，由于把这样的代码单独抽取出来，反而让程序结构更加清晰。

4 楼 canonical 2009-03-07  

文档矛盾之处其实很多时候在人的语言层面的理解有一定的容忍度, 大家可以形成某种语境环境下的共识. 很多没有精确定义的概念在一定的语境下在人的思想层面并不会产生很大的误差. 但是要是打成某种精确的一致性,并始终维护它有效,则成本就高多了. 这样说其实已经有些哲学化了. 从实际操作上说, 现在大量的信息仍然处在代码之外, 我们能够以代码表达但却没有表达的东西非常之多, 必然是要发展大量技术手段来捕获这些代码之外的概念.

3 楼 uda1341 2009-03-07  

canonical 写道

文档的形式化并不总是可能的,至少在现实技术的限制下并不总是可能的. 而且一般情况下如果完全通过代码来表达,则意味着我们在概念上必须完全解决这些表述之间的矛盾之处, 这是要付出真实的代价的. 从降低总代价的角度上来看, 追求完全的形式化反而是不明智的

你不觉得这些说明文档存在的矛盾之处，不正意味着我们对程序如何运行还没有清晰的概念所造成的吗？这些矛盾之处不解决，就无法写出正确的程序。我这里所说的说明文档，是关于程序结构的说明，把说明文档形式化，就可以将其做为代码的一个Aspect，将一些独立的概念解耦出来，做为独立的代码。

2 楼 canonical 2009-03-07  

文档的形式化并不总是可能的,至少在现实技术的限制下并不总是可能的. 而且一般情况下如果完全通过代码来表达,则意味着我们在概念上必须完全解决这些表述之间的矛盾之处, 这是要付出真实的代价的. 从降低总代价的角度上来看, 追求完全的形式化反而是不明智的

1 楼 uda1341 2009-03-06  

我的看法是：

这些说明文档在未来的程序设计语言中是不必要的，程序设计语言应该发展出表达这些说明的语法。

用我的说法，这里有两点：

1 在头脑中能够存在的概念，就应该能够在程序语言中用精确的方式表达。
2 从概念上能够解藕的也必须从代码上解藕。

我在设计领域基本持有一种物理实在论，即某种技术相关的约束应该在技术世界中通过技术手段得到表达。只是这里的技术手段却不一定指在应用中加上特定的代码实现

这一点并不同意，形式化代码可以是任何数据结构，具有无限的表达能力。也许是我对代码的定义比较宽泛吧。另外一点是，这些说明文档必须是精确的，可以和其他代码一起正确编译的。