diff options
| -rw-r--r-- | parnas-a-rational-design-process.rst | 41 |
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]。 我们所有的文件都是按 +照与指导软件设计相同的原则来设计的，即关注点分离。 我们要开发的系统的 +每个方面都只在一节中描述， 且在该节不含其他内容。 当我们的文件被审查时， +我们会审查它们是否符合文档规则以及是否准确。 + + |