1 files changed, 14 insertions, 9 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 8b9601c..cbe567e 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -44,9 +44,9 @@
 论有什么决策改变或者修改，都要如实的写下原因。
 
 在我看来能做到自然是一件很理想的事情，或许在一个长期的软件开发过程中，
-这是重要的。根据我的个人经验，比较多的开发者会写“change log/update
-log”之类的东西，这也算文档的一种，但是可能更面向用户一些。 像这篇论文
-中的文档可能对于短期的私人项目开发太繁琐了，也是有局限性的。
+这是重要的。根据我的个人经验，比较多的开发者会写 change log/update log
+之类的东西，这也算文档的一种，但是可能更面向用户一些。 像这篇论文中的
+文档可能对于短期的私人项目开发太繁琐了，也是有局限性的。
 
 作者在最后几页分析一些他不认同的行为。比如软件做完了再写各种文档。文档
 要么是意识流要么是面向实现。或者干脆文档很少，都靠代码注释，这样的文档
@@ -61,13 +61,18 @@ Page 1
 徐梦旗
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-一个理性的设计过程:如何以及为何要仿制它
+理性设计过程:如何、为何要仿制它
+
 摘要
-软件工程师们一直在探寻最为理性的软件开发过程：从技术规格中派生编程过程，无异于从已被发表的证明公理中导出前提与定理。
-本文在解释为何我们永远无法企及这一高度后，还将描述这样的一个过程。这个过程是，在软件设计的路上，如何根据一系列的文档来描述过程。
-我们也将展示诸如此类的文档产生的多方面的益处。它们不仅为初步设计提供了参考依据，还为编码过程充当了评审资料，也为维护程序员们的工作提供了技术指导。
-我们还将进一步探讨利用统一标准指导软件设计的文档是如何架构的。结果文档远远比通常产生的“事后考虑”文档更有价值。
-如果我们可以苦心孤诣地更新所有文档，那么我们就可以缔造一个相当理性的设计过程。
+
+
+软件工程师们一直在探寻最为理性的软件开发过程： 像从发表的公理中导出引
+理与定理那样， 从软件规格说明中导出程序。 在解释为何我们永远无法做到如
+此之后，本文描述这样的一个过程。 这个过程由一系列应该在软件开发中产生
+的文档来描述。 产生这类的文档有几个方面的目的。 作为初步设计检查的基础，
+作为编程的参考，作为维护程序员的指导。 我们讨论使用与软件设计相同的原
+则来编写文档。 这样产生的文档远比 “事后考虑” 文档有价值。  如果我们经
+常仔细更新所有文档，那么我们就好像有了理性设计过程。