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

GreyZeng 2022-06-20 22:32:28

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

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

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

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

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

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

 

原文地址

...全文
5 1 打赏 收藏 举报
写回复
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
GreyZeng 06-20

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

原文地址

  • 打赏
  • 举报
回复
相关推荐
发帖
构建之法
加入

161

社区成员

程序员。写过:移山之道,编程之美,构建之法,智能之门。
社区管理员
  • SoftwareTeacher
  • GreyZeng
帖子事件
创建了帖子
2022-06-20 22:32
社区公告
暂无公告