parnas-a-rational-design-process.rst: 审阅王海榕的翻译， 第16页

把document的翻译固定为文件

把documentation的翻译固定为文档

1 files changed, 24 insertions, 17 deletions

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