From d01e7d3736fa9bd4a15212c85a511e58624fae24 Mon Sep 17 00:00:00 2001 From: Hui Lan Date: Tue, 30 Jul 2019 15:41:26 +0800 Subject: =?UTF-8?q?=E9=98=85=E8=AF=BB=E5=B9=B6=E4=BF=AE=E6=94=B9=E5=88=98?= =?UTF-8?q?=E8=8E=89=E8=8E=89=E7=9A=84=E7=BF=BB=E8=AF=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 她好像是先用有道进行翻译，然后在润色的。 基本上还好。 我把 because it works 与 Get On With It 保留了。 因为比较原汁原味。 写好东西的好处就是几年后你还能用它。 写垃圾交差的话只是浪费时间，是一种自欺欺人的行为。 --- parnas-a-rational-design-process.rst | 23 ++++------------------- 1 file changed, 4 insertions(+), 19 deletions(-) (limited to 'parnas-a-rational-design-process.rst') diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst index d3dc5d2..b6f9001 100644 --- a/parnas-a-rational-design-process.rst +++ b/parnas-a-rational-design-process.rst @@ -536,24 +536,9 @@ VII. 现在， 如何假装理想的过程？ -Page 19 - 刘莉莉 +Page 19 - 刘莉莉 OK ---------------------------------------------------------------------------------- -从这个过程得到回报的例证是由我们几年前写的软件需求文档提供的，其作为理 -想过程演示的一部分[9]。通常，人们认为需求文档在编码开始之前就生成了， -并且不会再使用它。然而，事实证明并非如此。那些满足我们的要求文件的软件， -它的原始版本仍在进行修订。每次更改后就必须测试软件的组织，都会广泛使用 -我们的文档来选择他们所做的测试。当需要进行新的更改时，需求文档用于描述 -那些必须更改的内容和不能更改的内容。在软件投入使用后，该过程中生成的第 -一份文件一直被使用了很多年。可以明确的是，如果一个文档是经过精心制作的， -那么它将在很长一段时间内发挥作用。相反，如果它将被广泛使用，那么正确的 -制作是值得的。成为一个理性的设计师是非常困难的，而且我们可能永远不能实 -现它。在我们尝试遵循这个过程的过程中，我们经常发现我们继承了一个由于未 -知原因而做出的设计决策的地方。例如我们想要使用的等式中常量的值。当我们 -要求推导常量时，我们发现它不存在或推导无效。当我们进一步按下时，我们被 -告知该决定是“因为它有效”。在这种情况下，设计师可以打开一个研究项目，找 -出它的工作原理，或者只是“继续使用它”。那些为我们工作付钱的人已经使用 -“GOWI”这样的标准回答去解决许多此类问题，并且我们并不认为真正的工作会有 -所不同。然而“因为它们起作用”，所以无论我们做出哪些决定，我们都会对我们 -的决定记录诚实的理由，而不是误导未来的维护者认为我们对我们所做的事情有 -深刻的哲学理由。 +几年前我们写了一个软件需求文件，作为对理想过程演示的一部分，这个需求文件说明了这个过程是值得的[9]。 通常，人们认为需求文件是在编码前写成的， 编码完成后就不会再被使用了。 然而，事实证明并非如此。 那些满足我们的需求文件的软件， 它的初始版本仍在被修订。 每次更改软件后， 软件测试机构大量使用这个需求文件来选择他们的测试。 当需要新更改时， 用需求文件描述什么必须被改变、什么必须不变。 软件投入使用很多年后， 该过程中产生的第一份文件至今还在被使用。 可以明确的是，如果文件是经过精心制作的， 它将在很长时间内都有用。 如果文件将被大量使用，那么正确制作它很值得。 + +成为一个理性的设计师很难，而且我们可能永远做不到。 在我们尝试遵循这个过程当中，我们常发现继承了某设计决策， 却不知道当初决策者的之所以决定的理由。 一个例子是等式中常量的值。当我们要常量的推导过程时， 我们发现它不存在、或者原先推导是不正确的。 当进一步追问时，我们被告知做这个决策是 “因为它起作用 ( **because it works** )”。 在这种情况下，设计师可以去研究它起作用的原因， 或者就简单地 “与它友好相处 ( **Get On With It (GOWI)**) ”。 给我们的工作付钱的人把 **GOWI** 作为对许多此类问题的标准回答。 我们并不认为真正的工作会有所不同。 然而， 每当我们把“因为它们起作用”作为决策理由时， 我们就诚实地把这个理由写下来， 以免误导将来的软件维护者去花心思想在我们的决策后面有什么深刻的理由。 -- cgit v1.2.1