2007-05-29

细节开发3（设计阶段）

毫无疑问,这个阶段是非常重要的环节。但是从这里应该了解到，不管你采用什么的设计
文档，都应该注意细节的问题。
因为每个公司的设计文档都不可能完全相同，所以，我们将脱离文档样式来说说设计中
的细节问题。

 

CASE 描述。
对于项目中的每一个CASE，当描述它的时候，最好也相应的使用另一个文档来描述这个
CASE的数据库操作过程：例如某个表需要查询，某个表需要删除。这样的好处就是可以
保证至少数据库操作是一定正确的。至于这个文档，最好是流程图的样式，用什么工具
画出来都可以。
为什么我们需要额外的这样一个文档？繁多的文档对项目的开发和维护没什么好处。多
一份文档，意味着当我们修改某一个地方的时候，我们要相应修改的文档又多了一个。
但是，这份文档还是非常必要的。因为在开发的时候，开发人员经常明白了CASE的描述，
但是却使用了错误的数据库操作--这样的返工是多么的糟糕！

下面我们来谈谈CASE的描述问题。在上一个段落里，我们已经说了最好需要额外的一个
数据库操作文档。其原因就是描述CASE的时候，很难既把业务逻辑说清楚，同时又把
数据库操作说清楚。虽然有数据库操作文档作为辅助，但是业务逻辑的描述同样重要。
首先，要提高的就是文字水平--大家不要偷笑，你的文字水平未必有你想象的那么好。
尤其是做外包项目的时候，当面对其他国家的语言的时候，你的描述水平是否有那么好？
其次，就是条理要清晰，不要东讲一些，西讲一些，如果你自己都没有清晰的条理，那么
怎么指望看设计的人能写出正确而且高质量的代码？
保证CASE描述的正确，除了通过PM，PL review 外，最好是交叉检查case。通过交叉
检查，可以很容易的发现的CASE描述的失败的地方。

 

UI DEMO。 制作UI DEMO 似乎又有个名称叫原型开发法，不过这并不重要。对于WEB
项目来说，UI DEMO会容易做些。对于APPLICATION项目来说，其实可以用VISIO或其他
工具把界面画出来。
对于UI DEMO，一定要保证它的正确性，不能采用应付的心态。因为UI DEMO什么样，
我们的系统就是什么样。每一个LABEL，字体，位置，都必须注意。可以从以下几个细节
检查UI DEMO：数据信息是否正确（即使举例子也必须和实际相符）；界面风格；文字位置；
窗体（页面）的跳转；文字字体；动态效果。

 

validate.  每个项目都会有validate,每个模块都会有，这个东西是如此的普遍，所以被认为很简单－－我们只需要加一个
检查，来判断条件，不符合的话就中止过程。
因为是如此的简单，所以被很多人忽律，该如何去进行validate? 如何进行？很简单，根据逻辑增加检查就可以了。这是
普遍的想法。
但现实好像没这么简单。
比如一个普通的 edit 框，有的人可以先校验输入的字符串是否符合长度要求，有的人可能先校验是否为空－－这完全取决
于每个人的思维方式。
但是，项目却不能允许如此的自由，一个 edit 框，该是怎么校验的顺序，就该怎么的顺序。所以，在项目的测试阶段，我们发现了，
学多人开始按照测试用例修改校验的方式，或者顺序。
这是浪费时间而且无聊的事情，而且，修改顺序或许会产生新的bug。
如何避免？或许在项目开始阶段，team可以规定一些UI的校验的标准，比如对于 edit,必须先校验是否为空，然后校验
是否包含特殊字符，然后校验长度是否符合，等等。有了一个标准，后期的rework 才不会很多。

我们可以看到，ValidateFactory 确定了校验的顺序，这样，我们能保证整个team的UI的校验过程一致。

或许还有更好的方法，不过我们要认识到，校验－－不是一件简单的事情。

评论
发表评论

您还没有登录，请登录后发表评论

yananay
搜索本博客
我的相册
D35bafa8-5bf0-475f-aa06-16f3080557a1-thumb
tdd
共 3 张
存档
最新评论