读《DTS分析模型、设计模型》有感

 

昨下午看了DTR的分析模型和设计模型之后，我总结了一些对它们的改进建议：

l         要明确化所有方法的返回类型，及如何消费返回对象！

l         要明确化类与类间的关联类型及关联维度。

l         要明确化设计元素的属性定义。

l         在分析模型中应该有分析类的关联类图。

l         在分析模型、设计模型中包含（ChannelProcessor）的配置信息的对象模型。

l         修正模型，在模型中添加“直接编码”新增的类。

l         类、属性等的命名要一致、统一。

l         方法参数的命名要一致、统一，类型要明确。

l         在设计模型中要表达Processor Chain的设计。

 

今天来公司时，想了想，昨天跟王振骞聊了一会，我在想，有一种正确的态度叫做认真设计，事实上，做设计从来不等于是“闲”。平台产品更要要求按规范的软件过程来开发，我们越是在设计上下功夫，我们的工作产品才越是设计良好和架构良好的。

我们最先要的不是一打又一打的代码，而是思路，清晰的思路和有条理的模型，当然，表达这思路和条理也有多种方式，这跟项目规范直接相关。

同样也是在跟王振骞聊的过程中，我想到了“自己知道”和“能表达（绘制有条理的模型或者其它方式）清楚”的区别，就象是“学生自己懂”和“老师要把别人讲懂”之间的区别一样。试想，当我们是学生时，我们知道“平衡树”的概念，以为自己懂了“平衡树”，假如我们要做老师，单是“知道”的水平是不能让学生真正懂得“平衡树”的。所以，在软件研发过程中，类似的情况是，我们单是“自己知道”还远远不够，除非你能非常清楚规范的表达出来。

避免让代码出现臭味，（自认为）有经验的程序员常常越过设计直接编码，当有这一想法的一刹那，他（她）先前写的代码就已经出现了臭味。

如果说软件开发是艺术的话，分析、设计和编码的工作产品就是“雅俗共赏”的艺术品。“雅”就是“设计之美和架构之美”，“俗”就是“浅显易懂”，假使我们分析、设计和编码的工作产品变成了“印象派”作品，就只能让人去随意想象作品的内涵了，或者也要等到多年之后才能想明白，可是，对于要求严谨和浅显的软件开发来说，“印象派”作品绝对不受欢迎！

我在想，倘若我们在主张和（或）首倡“什么过程流程(XP、RUP)”、“什么方法论（OOP、SOA、AOP)”的问题上煞费苦心，我们常常有些劳民伤财，因为，当你在软件研发领域耕耘多年以后，你“渐行渐远”的回头去看，它们（不论是过程流程，还是方法论）都是一脉相承的。

比较理想的情况是，我们对分析、设计、编码的细心程度要求得就象是跟心仪已久的女孩初次约会前整理衣装、修理边幅时那般在意，我们端庄或潇洒、靓丽或帅气，我们（分析、设计、编码）的工作产品也会美不胜收（请参考《软件涅槃》之软件之美）。我们对“工作”的重视也恰似对那女孩的重视一样，跟那女孩相处是极乐，看我们优美的工作成果也是快乐！

我觉得，在工作中，如果可能，就面对面去交流吧，因为面对面时传递的不仅仅是声音！

 

希望大家指正，欢迎反馈！