计算机软件开发文档编写规范-软件开发技术不会作恶，但人可能会会

在软件开发领域，经常会发生由于从业者的职业道德不到位而引发的事件，比如，InfoQ 过往就曾报道过离职程序员利用测试账户套现千万美元、华夏银行一位技术处长利用职务便利在华夏银行总行核心系统内植入计算机病毒程序，成功取款 717.9 万元的 新闻等。虽然软件开发技术不会作恶，但人可能会。

一提到著名的希波克拉底医学誓言时，大多数人可能会马上想起这句话：“首先，不要伤害（First, do no harm）。” 这是人类自然而然的反应，因为即使是不熟悉该誓言的人也能明白这点，在医疗过程中避免额外伤害是至关重要的。

事实上，无论做什么事情，这都是一个顺理成章的道理，即在修复过程中尽量不额外损坏其他东西。其实，软件工程和医学的道理是相通的，要做到“不伤害” ，就应该先做到对可用工具和技术的深入理解，本文提供了一些有关软件工程从业者职业道德的见解。

软件工程道德规范

其实，软件工程也是一个经常和生命关键系统打交道的职业，比如医疗和自动驾驶相关的程序开发，很小的差错都可能造成很严重的后果，但我至今还没发现软件工程师有任何等同于希波克拉底誓言的职业道德誓言。虽然 IEEE 计算机学会制定了“软件工程道德规范和专业实践”，但其内容侧重于个人责任，而不是针对安全实践的规范。说来真是令人汗颜，如果在网上搜索“软件工程师的希波克拉底誓言”，只会得到一堆笑话，例如，“敲键盘快，转脑子慢” 或者 “永远不要写出一行别人能看懂的代码”等。

“首先，不要伤害” ，这条准则在医学实践中很有意义，尤其是考虑到医学的发展历史。从中世纪到 19 世纪晚期，医生们会用仪器戳来捅去，会在人身上用水蛭进行放血，还会在不了解副作用的情况下，给病人注射强力药物。虽然在今天看来这些做法野蛮愚昧，但都是符合当时的技术水平，并怀着良好意图进行的。

软件工程其实和医学过程类似，可能具有侵入性和破坏性。同样地，软件行业使用的工具和技术可能是新的，很多都未经测试或者几乎没有验证过。此外，我们没有类似于医疗许可委员会或食品和药物管理局机构来规范软件工程实践和选用的工具。因此，有时候，我们在没有真正理解风险的情况下就让我们的“患者”——即软件产品置于不必要的风险之下。

软件开发风险

在软件工程中，哪些行为实质上等同于医学上野蛮愚昧的行为呢？其中一个例子是代码重构，虽然重构的出发点是好的，并且控制在一定比例范围的重构通常是有益的，甚至是必要的，但是重构的比例一旦过了某个点，收益不增反减，甚至会带来无法弥补的危害。“如果一样东西没有坏，就不要多此一举地去修理它” 这句古老的格言在今天仍然有它的价值。我认为我们有时会试图去实现软件的极端改造，而把重构做过头了。

在解决问题的过程中，我们有时引入的弊端比利处更多。Steve McConnell 在软件工程的经典著作《代码大全》（Code Complete）一书中认为，如果你没有修复问题的根本根源，而只是修改了问题的症状，那么你的修复行为弊大于利，因为你自欺欺人地以为问题已经消失了。“如果你没有完全理解这个问题，你就不能对代码做出真正的修正。”实际上，这样的修改可能还会将一个相对容易发现的缺陷转换为一个更隐蔽的缺陷，而隐蔽的缺陷发生的频率往往要低得多，因此更难被人发现。

最简单的例子可能是和调试语句相关的 bug。假设正在调试一个嵌入式实时系统，软件开发者可以添加某种类型的 output 语句或者使用源代码级调试器来显示一些中间计算结果。调试过程中，软件问题突然莫名其妙地消失，但删除 output 语句或关闭源调试器后，问题又重现江湖。在苦苦搜索和寻找问题的根源之后，开发者放弃了，并在适当的位置留下一个无意义的 dummy 语句，以克服这个臆想中的时序问题。为这个语句仅留下一个注释来说明该问题，大概会这么写：“如果删除此代码，系统将无法工作。但我真的不明白为什么会这样。”

很多方法不是万能的

纵观历史，总有一些江湖庸医，为患者提供安慰剂甚至有害的治疗，仅仅是因为他们对病症不甚了解。虽然此处并不是指责人们在软件行业中故意歪曲事实，但是，例如净室软件开发（clean-software development）、结对编程和其他实践的相对优势在被误用时可能会产生类似安慰剂或有害的影响。

这就好比敏捷方法在某些环境下有显著功效，但在不恰当的使用环境下也可能导致盲目自满。例如，有些团队很容易就打着敏捷开发的旗号，让团队完全无纪律地“自组织”管理，声明代码是最重要的产出，并用这些借口来逃避撰写技术文档。但是敏捷并不适用于那些大型生命关键性系统，也不适用于团队远程合作的系统。还有一些其他环境，尚不清楚敏捷方法是否适用。

在《代码大全》中，McConnell 警告了与“蛇油”（一般用作骗人的“万灵药”）等价的“自动方法”，即热门词语“方法论”。他让我们总是报以怀疑的态度去问：“有多少系统实际上是使用这种所谓的‘自动方法’构建的”。在这种情况下，如果我们采用的方法恰好奏效了，我们就会欢欣庆祝。当它不奏效时，我们总能找到借口说这个方法本来就不应该在那种环境中使用。对于推广这些“自动”方法的人来说，这似乎是一个稳赚不赔的局面。

避免只做不想

历史学家、哲学家 Thomas Carlyle 说过：“世上最可怕的事情莫过于只做不想。” 如今软件工程已经退化到这种境地了吗？在计算机发展的早期，电气工程师、数学家和物理学家通过调整电路、用二进制汇编语言编程，后来他们使用熟悉的编译器来编写计算机程序。这些为数不多的先行者经常被戏称为“大神”，因为在外人看来，他们这些超自然壮举只能归因于神力或魔法。但对他们来说，这些并不是魔法，而是他们所做的每件事的细微末节都被彻底消化理解。我并不怀念用打孔卡编程的岁月，但至少软件行业过去的“医生”们貌似对他们所使用的疗法有非常透彻的理解。

从复杂的集成开发环境（IDE）和框架、重构工具、庞大而神秘的代码库，到现成的体系结构，许多大多数人无法详细解释的技术每日辅助着当代软件工程师们。可重用抽象组件的时代也已经成为黑匣子和魔法的时代。我不是一个路德分子（19 世纪初强烈反对机械化或自动化而捣毁机器的人），但是基于对数百名软件开发从业者的观察，让我感到恐惧的是，我们在没有彻底理解上述技术的作用或原理的情况下，就直接在软件开发中使用了这些技术。因此，当我们使用这些技术时，出现弊端而不是利处的可能性总是存在的。

为什么我们会觉得，除了那些特别简单的小型系统之外，其他软件的开发、维护和扩展也是很简单的事情？而没有人会争辩说设计宇宙飞船是件容易的事，毕竟，这是所谓的“火箭科学”（美语俚语中指尖端科技），也没人会觉得设计现代汽车是件轻而易举的事。那么，为什么我们认为开发复杂的软件系统会比这些“高科技”更容易一些呢？

外包会造成大规模危害吗？

好心办坏事，这样的事有可能造成大规模危害。软件行业中，有些人认为易于使用、可移植的软件所付出的代价是“黑盒式重用性”，而这些人正在迫使自己最终将业务外包给成本更低的竞开发商。由于广泛可用的基于 GUI 的工具、易于构建的 Web 解决方案，以及市场对 Web 程序员的需求膨胀，导致了整整一代互联网公司的崛起，许多刚刚高中毕业的“神童”，他们在并未真正了解自己在做什么的情况下就可以将组件拼凑在一起，并快速出炉现成的解决方案。市场对 IT 专业人士的需求膨胀也足以让这个行业最平庸的人才的工资水涨船高。

现在，印度、前苏联地区和其他地方的开发人员也可以同样轻松地以更低的成本使用相同的工具和技术。所以，项目经理们纷纷外包软件开发业务，但是，外包真的弊大于利。失去控制、失去知识产权、性能不佳、还引入了很多隐性成本以及难以在法律上获得补救，这些都是外包项目出问题时可能产生的危害。

软件工程师的誓言

人们普遍认为，新时代的医疗程序最重要的一条规矩是洗手消毒。我们需要在软件工程实践中也采用与洗手相同的简单方法，无论是在小的方面，例如采用新工具或实践，还是在大的方面，例如尽力将业务外包。我认为软件版的希波克拉底誓言会对所有从业人员有所帮助。让我来尝试写一写这样的誓言。这是南丁格尔护士誓言的一个变体。

我郑重承诺，第一，不损害委托给我的软件产品；不故意采取任何有害的做法，也不使用任何我所未能彻底理解的实践或工具。我以满腔热忱发誓，戒绝那些有毒有害的行为。我将尽力扩充我的技能和知识，并保持和提升我的专业水平。我将以至诚的态度尽力帮助软件产品的干系人，在软件工程实践中为接触到的所有信息保密，并致力为我所从事的项目获得福利。

也许这样的誓言太平淡无奇计算机软件开发文档编写规范，也太长了，人们可能会忽视或嘲笑它。也许，我们需要一个强有力的，朗朗上口的口号，这样就可以在软件开发公司里反复播放；也许，需要创建一些划时代的故事去讲述那些重要的软件系统在开发过程中所经历的考验和磨难，让开发者记住这些事迹，在关键时刻背诵部分的软件生命周期（例如，一个菜鸟采用了最低级的重构，把方法移动到最经常使用的类里面，然后就自我欺骗地宣布“重构完成”）。无论如何，这些不是应该由个人来决定，而是应该由相关委员会和组织来负责发起的事情。

我知道，你可能会说：“这样的誓言有什么意义？它只是浪费时间罢了。“ 而我对此的回答是：这说明，在医学和护理行业，忠诚的誓言非常重要，足以在毕业典礼上背诵，而软件工程师们类似的仅有誓言只是一堆笑话。也许通过某种宣誓的象征性行为是一种声明，表明我们在软件工程实践中想更严肃地对待我们的职业。

更重要的是，希波克拉底誓言是健康怀疑主义的基础。毕竟，相关监管机构的存在很大程度上是为了确保医疗创新的弊端不会大于利处。这样的誓言其实是一个提醒，提醒软件开发者在采用新的工具、方法和实践时要谨慎行事。但是，如果在说了这么多之后，我仍然没有说服你，那么我为这个论点再加点砝码，类似 Edsger Dijkstra 和 Steve McConnell 这样的计算机界杰出人士，以及其他许多人已经建议软件行业也应该设立“希克拉底誓言”。

无论做什么，首先，不要伤害。毕竟，我们不希望 100 年后的批评家无情地嘲笑我们现在认为合法的那些做法，尤其是如果我们采用这些做法的唯一原因是盲目的信心而不是透彻的理解。

作者介绍：

PHILLIP A. LAPLANTE 博士是宾夕法尼亚州立大学 Great Valley 研究生院的软件工程副教授。他的研究兴趣包括实时和嵌入式系统、图像处理和软件需求工程。他写了许多论文，17 本书，并共同创办了《Real-Time》杂志。他编辑了 CRC 出版社的图像处理系列书籍计算机软件开发文档编写规范，并在四家期刊的编辑委员会任职。Laplante 拥有计算机科学的学士学位，电子工程的工程学硕士学位，史蒂文斯理工学院颁发的计算机科学博士学位，科罗拉多大学的工商管理硕士。他也是 IEEE 高级会员，ACM 和国际光学工程学会（SPIE）会员，是宾夕法尼亚州注册的高级工程师。

翻译来自：

英文原文：《First, Do No Harm: A Hippocratic Oath for Software Developers?》

链接: