1 files changed, 35 insertions, 13 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 671d997..4725a3e 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -17,19 +17,41 @@
 伍泰炜
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-读完全文之后，我感觉作者能把前面十几页的内容写出那么多字，真是十分了不起，可能这就是科研工作者的特长吧，把一个东西反复讲述，使得论文的篇幅变得很长，让人看起来好像内容很多。以下是我没有做第二遍阅读，单凭印象做出的理解。（而且我也相信第二遍和第一遍不会又很多改变）
-
-作者核心观点是，一个合理的设计过程需要写一大堆东西，比如“设计文档/需求分析/母子模型/接口说明”，这点写东西就在设计之初就开始写，在设计过程中每一次改变都要做清晰的更新。然而这是很难的，甚至一般都是不可能也做不到的，作者大人就说了，那就假装有一个。
-
-有一个合理的设计过程有什么用呢？如果有的话，可以帮助开发过程中，有助于估算一个过程的时间金钱花费，减少重复做决策，减少大改的次数，方便后来人维护，防止人员变动地时候对接困难，等等。这些前提都是一个合理的设计过程的时候，没有的时候，或者说实施得不那么周全得时候，也不会有那么理想的辅助效果。
-
-那么怎么假装呢？这篇文章写了很多，方法论式的表述，缺少举例——可能也很难举例，毕竟是理想状况——总之就是文档多花时间写。具体而言，在最开始的时候就照着自己理想的目标去写，不要去考虑实际实现的过程，防止后期忘掉了最开始的想法。开发的过程中，要秉持“write everything down”的原则，无论做什么决策改变或者修改，都要如实的写下原因。
-
-在我看来能做到自然是一件很理想的事情，或许在一个长期的软件开发过程中，这是重要的。根据我的个人所见，比较多的开发者会写”change log/update log“之类的东西，这也算文档的一种，但是可能更面向用户一些。像这篇论文中的文档可能对于短期的私人的项目开发太繁琐了，也是有局限性的。
-
-作者在最后几页分析一些他不认同的行为，比如各种文档软件做完了再写，写的文档要么意识流要么面向实现；或者是干脆文档很少，都靠代码注释。这样的文档会很难看懂，过多的注释也会导致后续的修改很麻烦（改了一个注释，还有多少注释要牵连呢？）
-
-
+读完全文之后，我感觉作者能把前面十几页的内容写出那么多字，真是十分了不
+起，可能这就是科研工作者的特长吧，把一个东西反复讲述，使得论文的篇幅变
+得很长，让人看起来好像内容很多。
+
+.. 作者之所以能写那么多，是因为8年前有 A7E Aircraft 需求分析的经验。见
+   第9篇参考文献：software requirements for the A-7E Aircraft
+
+以下是我没有做第二遍阅读，单凭印象做出的理解。（而且我也相信第二遍和第
+一遍不会有很多改变。）
+
+作者核心观点是，一个合理的设计过程需要写一大堆东西，比如“设计文档/需求
+分析/母子模型/接口说明”，在设计之初就开始写，在设计过程中每一次改变都
+要清晰的更新。然而这是很难的，甚至一般都是不可能也做不到的，作者于是说，
+那就假装（尽力）做一个。
+
+有一个合理的设计过程有什么用呢？ 在开发过程中，有助于估算一个过程的时
+间与金钱花费，减少重复决策，减少大改次数，方便维护，防止因人员变动而对
+接困难，等等。这些的前提都是有一个合理的设计过程，如果没有，或实施得不
+那么周全，就不会有那么理想的辅助效果。
+
+那么怎么假装呢？ 这篇文章有很多方法论式的表述，但缺少举例 —— 可能也很
+难举例，毕竟是理想状况 —— 总之就是多花时间写文档。具体而言，在最开始的
+时候就照着自己理想目标去写，不要去考虑实际实现的过程，以免后期忘掉了最
+开始的想法。开发的过程中，要坚守 **Write Everything Down** 的原则，无
+论有什么决策改变或者修改，都要如实的写下原因。
+
+在我看来能做到自然是一件很理想的事情，或许在一个长期的软件开发过程中，
+这是重要的。根据我的个人经验，比较多的开发者会写“change log/update
+log”之类的东西，这也算文档的一种，但是可能更面向用户一些。 像这篇论文
+中的文档可能对于短期的私人项目开发太繁琐了，也是有局限性的。
+
+作者在最后几页分析一些他不认同的行为。比如软件做完了再写各种文档。文档
+要么是意识流要么是面向实现。或者干脆文档很少，都靠代码注释，这样的文档
+很难看懂，过多的注释也会导致后续的修改很麻烦（改了一个注释，还有多少注
+释要受牵连呢？）