parnas-a-rational-design-process.rst: 融入张俊玲的翻译 (PDF page 16).

1 files changed, 10 insertions, 25 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 9e79606..14e2d94 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -487,31 +487,16 @@ Page 15
 Page 16 
 ------------------------------------------------------------------------------
 
-(王海榕 翻)
-
-如何避免这些问题？
-
-理想设计过程中， 文档既满足了开发人员需求， 也满足了维护人员的需求。上
-面提到的每个文件都记录了设计决策，并在剩余的设计中作为参考文件使用。
-这些文件也提供了软件维护人员所需要的信息。由于这些文件在整个软件开发过
-程中被用作参考手册，因此它们将是成熟的，并且已经准备好在以后的工作中被
-用到。 这些文件总是及时更新的。 在我们设计过程中， 文档不是事后才想到
-的产品; 而是被看作是项目的主要产品之一。 一些检查可用来增加其完整性和
-一致性。
-
-这种产生文档的方法，其主要优点是可以减轻 **神话的人月效应 (The
-Mythical Man Month effect)** [4]。 当新人加入时, 不需要依赖老员工来提
-供项目信息。 因为新人拥有一个最新的且理性的文件集。
-
-为避免“意识流 (stream of consciousness)”和“执行流 (stream of
-execution)”， 我们花大力气来设计每个文件的结构。 通过声明文件必须回答
-的问题, 我们来定义文件； 我们将这一原则贯彻至文件的每小节。 在文件中，
-我们试图为每一个必须要包括的事实找一个位置，并确保只有一个这样的位置存
-在。 只有在确定了文件的结构之后，我们才开始写。 如果我们要写许多特定类
-型的文件，我们就为它们编写并发布一个标准结构[5]。 我们所有的文件都是按
-照与指导软件设计相同的原则来设计的，即关注点分离。 我们要开发的系统的
-每个方面都只在一节中描述， 且在该节不含其他内容。 当我们的文件被审查时，
-我们会审查它们是否符合文档规则以及是否准确。
+(王海榕 翻，张俊玲 改)
+
+B. 如何避免这些问题？
+
+在理想设计过程中的文档既满足了开发人员需求， 也满足了后来的维护程序员的需求。上面提到的每个文件都记录了设计决策，并在余下的设计中被用作参考文件。然而，它们也提供了软件维护者将需要的信息。因为这些文件在整个软件构建过
+程中被用作参考手册，它们将是成熟的，并且在以后的工作中随时可用。 它们将总是最新的。 我们设计过程中的文档不是事后才做的; 它被视为项目的主要产品之一。 有一些检查可以被应用来增加其完整性和一致性。
+
+这种产生文档的方法的主要优点之一是可以减轻 **人月神话效应 (The Mythical Man Month effect)** [4]。当新程序员加入项目时, 他们不需要依赖老员工来获得信息。他们将会有一个最新的且理性的文件集。
+
+我们通过花大力气去设计每个文件的结构避免“意识流 (stream of consciousness)”和“执行流 (stream of execution)”。我们通过规定文件必须回答的问题来定义文件；我们将这一纪律贯彻至文件的所有小节。我们试图为每一个必须要包括的事实找一个位置，并且确保只有一个这样的位置。 只有在确定了文件结构之后，我们才开始写。如果我们要写一个特定类型的许多文件，我们就为这些文件写并且发布一个标准结构 [5]。 我们所有的文件都是按照与指导软件设计相同的原则来设计的，即关注点分离。系统的每个方面都只在一节中描述，且该节不描述其他内容。当我们的文件被审查时，我们会审查它们对文档规则的遵守以及准确性。