《软件设计精要与模式》读书笔记(一)

     最近在学习设计模式方面的内容，买了几本关于设计方面的书籍，这两天在看《软件设计精要与模式》，本书是博客园开发者征途系列、由张逸所著。

 

     第一章：设计之道。

     1.1 计划的设计和演进的设计

     其实以前自己并没有意识到设计还是分方式的，这里作者提出两种方式：计划的设计和演进的设计。我个人认为对于设计的取舍可以根据软件的开发模型来决定，比如采用瀑布模型使用计划的设计比较方便(因为需求变化较小或者说需要扩展的可能性不大等)，采用螺旋形模型/迭代模型可以采用演进模型。这里有些人可能会有些疑问，到底是先由设计还是先确定模型，个人认为是先确定模型（因为模型是项目开发的整个过程，而设计只是里面的一个环节）。其实无论设计或者开发模型都是以需求为驱动的。这里我需要引用作者“拷问自己”的几句话：

     “我对客户的需求都理解了吗？”

     “我能确定客户的需求不再变化吗？”

     “我设计的软件架构真的能满足需求吗？”

 

     1.2 架构设计的标准

     本节可以作为架构设计的参考：

     （1）程序组织(Program Organization)

     （2）数据设计（Data Design）

     （3）安全性（Security）

     （4）性能（Performance）

     （5）可扩展性（Scalability）

     （6）可靠性（Reliability）

     （7）可用性（Usability）

 

     1.3 过度设计，还是简单设计

     本节我引用一句话来概括吧：“然而简单并非意味着简易，所谓‘大道至简’，自简入繁并不难，化繁为简才真正需要大智慧。”

 

     1.4 需要设计模式吗

     废话啊，不然我还看这本书干嘛？

     需要提醒的几点：“重要的不是你熟记了多少个模式的名称，关键在于付诸实践的运用。”

     “言必谈‘模式’，并不能是你成为优秀的架构师。真正出色的设计师，懂得判断运用模式的时机。”

 

     1.5 重构是必然的

     看看《重构--改善既有代码的设计》吧，最少偶是买了一本的，但是推荐在项目后期有时间改进时买，感触颇深啊。

 

     1.6 UML 重要吗

     作者这里提到“演进的设计降低了UML 的重要性，按照极限编程的开发原则，我们仅需要对眼前的需求进行编码、测试，然后重构”，其实如果真正按照演进的设计，那么UML 的设计是否会处于里面的一环？我们这里谈的是设计，干吗非要把极限编程的开发原则作为演进的设计拉进来说？UML 是设计的一种实现。如何去用UML 才是我们需要着重考虑的问题，而不是是否采用极限编程！

 

     1.7 测试驱动开发

     “‘大胆设计，小心求证。’测试驱动开发的精髓。”      “测试驱动开发的主要精神可以概括为‘测试先行，快速反馈’。”

     测试驱动开发，真正能够做到的有多少？虽说是个好东西，但是要去做还需要时间。

     

     计划的设计与演进的设计“它们非但不会在战场上成为敌我双方，反而是相辅相成、并行不悖的协作部队。当我们面对一个大型系统的时候，‘分而治之’是我们唯一能够选择的解决之道。如何‘分之’，正是计划的设计所需要关注的，解构出系统的层次、构成及其之间的关系，将整个系统分为能与外界通信，同时又独立为一体的不同模块。如何‘治之’，则可以应用演进的设计，以简单、适用作为设计前提，从不断的演进中创造客户所需。”这里我有些疑问，两种设计真的能够完全并存吗？或者是过程局部并存？如果将设计作为一个流程，那么是采用两个流程交替还是互相制约？那种设计为主？这里个人疑问太多。