• 从规范性文件想想


           软件开发人员不仅要敲代码,还准备了各种文件。

    有时。写花费了时间上的文档,甚至比花在敲代码的时间更。

    。于是敷衍了事,让之后阅读文档的人看得是云里雾里,极大地影响了工作的效率。

           近期,我看了两个不同软件版本号中的集成測试文档,颇有感触。

           集成測试文档1的结构是这种:

    1. 引言

    2. 术语、定义和缩略语

    3. 集成目标

    4. 集成任务

      4.1 集成任务1

      ……

      1

      ……

      1

      ……

       

      4.2 集成任务2

      ……

      2

      ……

      2

      ……

       

       4.3 集成任务3

      ……

      3

      ……

       3

      ……

      ……

     

    5. 集成工具及环境说明

    6. 附件

    7. 參考文献

     

          集成測试文档2的结构是这种:

    1. 引言

    2. 术语、定义和缩略语

    3. 集成目标

    4. 集成任务

      4.1 集成任务1

      ……

      4.1.1

      ……

      4.1.1

      ……

       

      4.2 集成任务2

      ……

      4.2.1

      ……

      4.2.1

      ……

       

       4.3 集成任务3

      ……

      4.3.1

      ……

       4.3.1

      ……

      ……

     

    5. 集成工具及环境说明

    6. 附件

    7. 參考文献

     

           大家可能已经看出来了。这两份文档仅仅是在红色字体部分有区别。其他部分都是一样的。在集成測试文档1中,图表的编号採用了“图1、图2、图3、表1、表2、表3”的形式。在集成測试文档2中,图表的编号採用了“图4.1.1、图4.2.1、图4.3.1、表4.1.1、表4.2.1、表4.3.1”的形式。大家或许觉得这个区别没什么,就是一个编号的方案不同而已。

            确实。从表面上看仅仅是编号方案不同。但在软件版本号不停演进的过程中,区别就体现出来了。为什么呢?请容我慢慢道来。

            这两个软件的功能在不停地升级,须要从最開始的1.0版本号发展到10.0乃至20.0。

    每次有版本号的升级,都须要在集成測试文档里面补充相关功能集成測试的内容,这主要是在“4. 集成任务”这一节中完毕的。也就是说,第4节的内容在不断地加入,或许会从“4.1”发展到“4.20”乃至“4.100”,而且这些加入可能是由不同的开发者完毕的。

            当第4节的内容足够多时,两份文档表现出来以下的不同:

            (1)对于集成測试文档1,在開始几个版本号。图表的编号还正常,依照“图1、图2、图3、表1、表2、表3”的顺序在发展。在经过多次版本号的升级之后。问题就出来了。某一个版本号的开发者可能是由于工作忙或者是疏忽了的缘故,将图表的编号搞错了,比如。本来应该是图4和表4,他写成了图5和表5,后面版本号的图表编号也就跟着错了。

    在发展到较高版本号之后,图表的编号可能是这种:“图1、图2、图3、图3、图4、图5、6、图6、图6、图7……表1、表2、表3、表3、表4、表5、表6、7、表7、表7……”。

    非常明显。这是非常不规范的,影响了对文档的阅读。

            (2)对于集成測试文档2。即使发展到非常高的版本号,也不会有问题,如“4.10”节。图表的编号就是:“图4.10.1、图4.10.2、图4.10.3…表4.10.1、表4.10.2、表4.10.3…”。

    由于图表的编号仅仅与所在的节有关,不须要与前后节有不论什么关联。所以可以保证其正确性。

            图表的编号尽管是一个非常小的问题,但我们却可以从中看出软件的不同设计方案所带来的不同结果。详细而言,我个人觉得:

            (1)软件产品的设计方案一定要考虑到未来的发展,就可以扩展性。要为以后的版本号打下一个好的基础

    集成測试文档2在这方面就做得比較好,而集成測试文档1没有考虑到未来在编号上出错的可能,这种方案就设计得不合理。

            (2)软件产品的设计一定要遵循“高内聚、低耦合”的设计理念,即要降低一个模块与其他模块在数据、消息等上面的关联,而应该增强模块内部的关联性。集成測试文档1中某节图表的编号与前面节图表的编号的关联性非常强。而集成測试文档2各节图表编号没有不论什么关联。因此,在图表编号上的设计。集成測试文档1比集成測试文档2逊色非常多。

           (3)软件产品的设计一定要体现出专业性。在这点上,“图1、图2、图3、表1、表2、表3”肯定没有“图4.1.1、图4.2.1、图4.3.1、表4.1.1、表4.2.1、表4.3.1”看起来专业。

    因此。从专业性的角度看。集成測试文档1也要比集成測试文档2差。

     

           编写出专业、美观、整洁的文档是对一个开发project师的基本要求,同一时候这也是project师做事态度、专业素养和能力的体现。一个合格的开发project师应该是“代码”和“文档”两手抓,两手都要硬。

     

     

    (本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5。我们的聊天号码:245924426,欢迎关注!)

    版权声明:本文博主原创文章,博客,未经同意不得转载。

  • 相关阅读:
    【转】职场中如何才能学会心理自控
    Gof《设计模式》完结
    阿里巴巴CEO马云最新超经典哲学语录
    大话设计模式感悟(3)——策略模式(Strategy)
    设计模式 ( 十三 ) 命令模式Command(对象行为型)
    数据结构&算法实践Python——序章
    设计模式 ( 十八 ) 策略模式Strategy(对象行为型)
    设计模式 ( 十六 ) 观察者模式Observer(对象行为型)
    金融系列2《借贷记卡应用》
    php 设计模式数据映射模式(应用程序与数据库交互模式)
  • 原文地址:https://www.cnblogs.com/gcczhongduan/p/4821846.html
Copyright © 2020-2023  润新知