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