读《设计原本》，想到IPCore项目

    最近在读Brooks的新书《设计原本》，这位大师是软件工程名著《人月神话》的作者，这部新书却不仅仅局限于软件的设计方法，而是抽象出许多领域在进行设计时共有的特性和一般规律。

    读了其中的“案例研究：System/360体系结构”这一章节，这部分记述了System/360项目诞生的缘由和研发中的重要事件，分析了成功和失败的原因，在章节的末尾Brooks总结了一些经验教训，结合自己的IPCore项目来看，还是很有意义的。

•     在项目安排中留出充裕的设计时间。它改善了产品质量，使其更长久地可用，并且由于减少了返工，往往还能使项目提前交付。

     在1.1的版本初始，对PRV解扰算法做了比较细致的概要设计，这主要是指算法在逻辑上可实现程度和对实现速率的估计，可以说这一部分的工作还是比较细致的。不过在对PRV算法做详细设计（状态机设计）的时候，乐观地认为设计可以满足速率的要求（达到设计需求需要在2707个周期内完成一个TS包的处理），但是事实证明该状态机没能满足速率要求，主要是因为忽略了IO占用的时钟周期。在实现了这个不合格的设计后，为了加快进度，只好增加了额外的电路来减少处理周期，这样一种修修补补的行为在项目结束之后来看，是不优雅和不完美的。

    Jin在项目的中后期才开始着手设计开发汇编器，从之后的效果来看，汇编器大大提高了代码编写和调试的速度，效果非常好。如果在项目之初就花一些精力来讨论和设计开发汇编器，那么项目的进展会更快，而且汇编器也会因为更深入地被讨论和更久地被使用而更加完善。

    如何解放测试人员而又不因为开发人员过多地介入测试工具的开发而影响测试的独立性，这也是项目结束后我一直思考的问题。让测试人员在项目的初始就参与到需求规格的讨论是必要的，让他们提出一些使项目更易于测试的建议。做为开发人员和项目经理，个人希望测试可以在测试人员的监督下，由测试工具自动完成，使得测试的准确性和进度加快。这就需要测试人员和开发人员共同设计用于自动测试的工具，在该工具开发完成后由测试人员认证后投入使用。至于有没有必要花额外的人月来做自动测试工具这个问题，我想结论是清晰的，这些“额外”的成本对于改进项目实施方法和提高工作效率的影响是明显的，是值得投入的，所谓“磨刀不误砍柴工”就是这个道理。