我在一个程序语言的研究室做软件工程的研究，平时读到的都是程序语言的文章。这次读了一下Alexander的文章，发现软件工程社区和程序语言社区在论文的写作风格上还是有很大差异的。

 

Alexander是软件工程领域如日中天的人物，他在博士毕业后几年就做到了ASE的Chair，毕业后不到十年就成为了奥地利的教授。我以前考虑traceability的时候就一直关注他的文章，这次发现他也做了和我相关的inconsistency-resolving，就把这个系列的几篇论文都找来读了一下。

 

ICSE06:

Instant Consistency Checking for the UML

 

ICSE07:

Fixing Inconsistencies in UML Design Models

 

ASE08:

Generating and Evvaluating Choices for Fixing Inconsistencies in UML Design Models

 

阅读的过程非常有意思。首先论文的标题都很吸引人。然后往下读Introduction讨论问题但不介绍具体的解决方案，非常吸引人想继续看下去。再往后的讨论也很精彩，但各种语法拼写错误就出来了，甚至有一篇论文的running example我怀疑是错的。之后的解决方案只讲概要不讲细节，但看完后还是让人感叹：原来不过如此。

 

如果是程序语言领域，这样的文章甚至可能不会被一个二流会议接收。方法没有细节，没有详细的证明，怎么说明方法的正确性？作者的文章有那么多语法错误甚至错误的例子，怎么能表明作者是在严谨的做科研。

 

但是这些文章却被软件工程最好的会议接收了。是软件工程的审稿都不认真吗？是Alexander地位太高大家不敢拒吗？我觉得情况不会这么简单。一系列文章都被接受，这个工作肯定有它的出彩之处。软件工程领域的专家们所看重的地方肯定与程序语言领域不一样。那么，他的文章优秀之处究竟在哪儿呢？抱着这个问题，我仔细分析了他的文章，总结出下面几点：

 

1. 论文中说的每一句话都有证据证明
   程序语言的文章，或者可能更多的是我自己的文章，在一些显而易见的假设面前就不多做讨论，但Alexander的文章几乎对论文中从Introduction开始的每一句话都提供了数据一类的证据支持。比如，在论文中有一句，如果采用另一个UML模型元素的Attribute来提供选项，那么通常会有不超过10个选项。然后下面就是一副图，显示他对工业界的几百个UML模型的分析结果，其中90%的都不超过10个。虽然有时对于一些显而易见的事实进行证明显得有些傻，但这样却保证了论文中的每一条假设都是正确的。
2. 在更高的层次讨论方法的选择
   程序语言领域常常是花很多篇幅描述一个方法的细节。而一个方法即使没有非常优秀的特征，但只要它提供了解决旧问题的不同方法，也认为是很有意义的。但Alexander的论文更多的是在更高的层面讨论方法的选择。对于每一个设计决策，他都列举数据说明：根据我们的统计，由于工业界的模型具有XX特征，所以我们只能采用A方法，不能采用B方法。而对于方法的细节，大概只描述到了程序语言领域的Introduction的程度。
   软工圈子里都是工程师，这种对设计决策的探讨可能更容易读。而工程师是不严谨的。只要程序能跑，那程序就是正确的。所以方法的细节就显得太琐碎了。
3. 用强烈的词语和句子
   在水木上有人去了美国发帖子说：words are cheap。我读Alexander的论文也是这个感觉。类似Significant improvement, very difficult problem的描述比比皆是。这样的应用词语，让我这样的东方谦虚国度出来的人很不适应。
4. 用大量的数据对方法进行验证和讨论
   几乎每一篇论文最后列举数据的验证和讨论section都达到了两页。每个section中都是大量的图表证明多次实验的结果。而且值得注意的是，这些实验并不仅仅是为了验证方法的正确和有效性，方法用在不同场景的各种特性、方法的缺点和不足也都表示了。

对不同的重点的关注可能来自于软工领域的工程师和语言领域的数学家们的不同背景。我不想评论说软件工程领域看重的重点和程序语言领域相比哪个更好。所有这些都是有意义的点，都在一定程度上保证了我们论文更有效更正确更能被读者使用。如果我们自己的论文能把每一方面都做得很好了，当然接收的可能性很大。但是往往由于篇幅和精力等原因不能把所有方面都做得很好。那么就在投软工的会议的时候关注软工的点，投语言的会议的时候关注语言的点吧。