3.3 在实际软件工程中，我们如何去评估追求艺术性带来的风险呢？以及如何依据评估结果来制定规范？

[GreyZeng]

工程师的能力评估和发展一节中：

软件设计工程师们在做代码复审的时候，是看“重复字”的多少, 还是程序的艺术性?

这一段中，作者将编程与艺术进行对比，来引发我们对创造性和规范性之间的思考。据我理解，“避免重复字”可以视作诗歌创作的一条规范，而违背这一规范并不影响诗歌的艺术性。

我们不妨去思考，规范是如何产生的？这里我也像前一章节一样引用民航业作为例子。民航爱好者都知道，“航空法规是用血与生命换来的”，每一条条例的背后都可能是一场无比惨烈的空难。911后，美国的很多机场才开始重视机场安检。

回到文中的例子。苏东坡的诗歌违反了重字规范，但是并没有影响他的艺术性。但是当我们放眼历史时，总能看到那些因为违反重字规范而显得无聊枯燥的诗歌。如果我们看到一趟没有进行安检的航班顺利完成它的旅程，就片面地认为遵守规范并没有意义，那么总有一天会面临911那样的灭顶之灾。

对于软件来说，我认为也是一样的。遵守规范或许不会总是有用，但是抛弃规范而追求艺术性，总是要承担更高的不可预料的风险。我的困惑是，在实际软件工程中，我们如何去评估追求艺术性带来的风险呢？以及如何依据评估结果来制定规范？

 

原文地址

[GreyZeng]

在我自己实际参与的软件开发过程中，我们采用静态检查工具来对团队的代码规范进行检查。我们默认，任何符合静态检查规范的代码都是合格的，而在这个大框架内追求艺术性是被允许的，也就是规范性优先于艺术性。这是因为我们必须明白，对规范性进行检查永远比对艺术性进行检查更加方便。而至于评估艺术性会导致的风险，我认为是不应该考虑的。我的想法是，艺术性本身是因人而异的，而团队本身是需要统一性的，因此我们应该避免在团队事务中讨论艺术性的价值与风险。不过，仅就规范性而言，也存在有多套不同的成熟的方案，它们就像不同国家的汽车一样，它们之间的异同有其内在的历史原因，但是都能很好地完成优化团队开发流程的任务。

原文地址