文档驱动式超敏捷开发

 

 

  敏捷开发大家都不陌生,他对文档的态度是偏向于反对,但是也不是说一点文档都没有。他的说法是 代替文档。

 

  那么敏捷开发为什么会这么认为呢?其实大家在做项目开发的时候都会有这样的体会:

 

  •   时间紧任务重,哪有时间写文档呀?代码都写不过来。
  •   辛辛苦苦把文档写好了,但是但是项目才进行一小半好不好,需求怎么就变了呀!需求变了,代码都改不过来,那还有时间去修改文档呀?于是乎一开始写好的文档就变成了一个个的坑。默默的坑着后来的人。

 

  于是就有了这样的现象:

  •   当接手一个遗留项目的时候最希望的就是有文档,但是没有文档——郁闷;
  •   啥?!找到文档了,太好了……但是当看完了文档再去看代码的时候就会——更郁闷。

         (各位前辈呀,为后来人着想着想呀!)

  •   等自己完全接手项目,流程都弄明白了之后呢?忙改代码做新功能,至于文档?哪有时间去想文档呀。

 

  于是乎文档就成了一个包袱一个累赘,有还不如没有。

 

  为啥会这样呢?因为文档和代码没有直接关系,没有“联动”关系!

 

  那么啥是联动关系呢?我们举个例子,PowerDeszner做数据库设置的时候,我们不仅可以用这个工具做数据库文档,而且设计好了之后,还可以直接创建数据库。当文档有变化的时候,也可以自动修改数据库。还可以反向工程,就是指定一个数据库,然后根据数据库里的表和自动,自动生成文档。这就是联动。

  如果您对powerdes不熟悉的话,我在举一个CodeFirst的例子。CodeFirst就是先写代码设计类,然后用vs里面的来自动创建数据库,类结构发生变化了,可以自动的去修改数据库的表结构。这样就可以达到代码和数据库的一致性,而且有变化只需要修改一个地方(代码)就可以了,另一个地方可以自动变更。

  这就是我所说的“联动”。如果所有的文档都可以和代码进行这样的联动,需求有变化了,先去修改文档,然后代码会自动随之变更,那么文档就不会成为负担了!

  这就是我所说的“文档式驱动”!

  当然在实际中,并不是所有的功能都是先文档在代码。而是根据具体的情况来灵活控制的。

  这里在举一个WebAPI的例子。我们打开VS201*,新建一个webapi的默认项目,我们会发现有一个help的目录。进去一看,哇,api的使用文档!有接口名称、参数名称和他们的注解,还有调用实例。这还不是最神奇的,更神奇的是,当代码修改了之后,help里面的内容也会随之更新。这样写接口再也不用担心更新文档的问题了。

  这是有代码“生成”文档。这个仅仅是对程序员来说的,写代码用的文档。除此之外还有给客户看的文档,等等。如果这些都可以“联动”起来,做到有需求的时候,只需要改动一个地方,其他的地方都会随之更新。这是不是很爽!

 

  可能有人说,我这是痴人说梦,该醒醒了,别浪费大家宝贵的时间。这个当然不是无稽之谈,今天也不是愚人节。下面还是用例子说话。

  公司以前用asp.net mvc做项目。后来发现开发速度跟不上,于是找了一个国外的无后端的东东 ,叫做backendless。他的思路就是,凡是服务器做的事情(UI除外),都可以不用写代码了,都由他来包办。Backendless提供了一个平台,在这个平台上面配置各种服务,配置完了前台就可以直接调用。这个前台包括:web、手机web、安卓、苹果、flash(Flex)、等,并且可以生成对应的调用代码。我们写点前台代码就OK了。

  每一个环节都有人在做“联动”的事情。只是从整个项目的角度来看,把各个环节用一条线,从始至终的串联起来,让各个环节可以“联动”。目前还没有发现做这种事情的人(自己除外)。

  这么做的难度很大,推广也很难。其实大多数的情况都是只做一块,比如选择日期的my97,分页的Aspnetpager,在线编辑器,各种ORM,各种UI,单点登录,用户中心等。他们都只做一块,其他的不管。这样才能够让大家灵活的选择和使用。

  再举一个盖大楼的例子。要盖楼首先要一个图纸,然后请建筑公司来按照图纸把大楼盖出来。盖楼之前图纸可以修改,盖楼的时候会按照最后修改后的图纸来施工。但是楼盖好了,再去改动图纸,大楼就不会受到影响了。大楼改好之后,图纸和楼失去了联动,图纸不会去影响大楼了,因为楼已经盖好了。

 

  再来看看导航软件,我们输入出发地和目的地,然后导航就会规划一条路线出来,我们按照这个路线开车,开着开着发现前方路口堵车,怎么办?重新规划路线绕过堵车点。然后我们按照重新规划好的路线继续行驶。路线实时指导我们的行车方向,路线变了,我们的车就跟着变。这样就是实时联动。

 

  说了这么多,大家可能都蒙登了,我到底要说啥?还是来张图吧。

 

 

 

 

  总之呢,就是不能让文档孤单单的存在,要让文档和代码和页面互动起来。需求有变化了,首先想到的是改文档,然后对应的地方会随之自动更新,不需要修改代码!

 

  最后说一下啥是“超敏捷”,前面说了敏捷开发,那么超敏捷开发呢,顾名思义说的就是开发速度会更快。

 

 

ps:好久没有写博客了。沉寂了一段时间,好好的思考了一阵子,现在是新的开始,重新打造!后续会更精彩。

 

时间: 2024-09-16 06:47:15

文档驱动式超敏捷开发的相关文章

文档驱动式代码设计器——代码是设计出来的!

  代码是敲出来的吗?是批量生成出来的吗?   No no no,代码是设计出来的!   如果说到代码生成器,大家可能会想到三层.动软代码生成器.数据库表等等.其一般的思路是,先有数据库然后根据库里的表自动生成一系列的代码,包括实体类.持久化.业务层(空函数).页面代码等,还可以生成数据库文档.这个确实很好很强大,可以免除程序员的机械式的敲代码的工作.   ("主要实现在对应数据库中表的基类代码的自动生成,包括生成属性.添加.修改.删除.查询.存在性.Model类构造等基础代码片断,支持不同3种

语音读取文档技术java技术的开发

问题描述 语音读取文档技术java技术的开发 我想做一个语音读取,电子书的开发软件 ,就是想问问,现在的这些软件开发的优缺点在什么地方? 解决方案 主要的难题是朗读,毕竟机器的智能不如人类,读起来会有些不像. 另外就是电子书的阅读体验不同于纸质书,所以需要优化.举一个简单的例子,人翻阅纸质书寻找一个有插图的章节,可能一秒钟看100页,很快就找到了. 可是电脑的速度有限,你做电子书加载页面肯定有延迟,就达不到这样的流畅度.

api文档-有关NAVISWORKS二次开发API文档的问题

问题描述 有关NAVISWORKS二次开发API文档的问题 我按照您所说的路径在navisworks2014的安装目录下并没有找到相应的api.pdf文件,我想咨询一下是否版本的问题? 解决方案 2013版本以后NV就没有自带的api文档了,在autodesk官网上下个SDK文件,安装过后什么都有了.

文档完整的超棒 iOS 开发框架 - NimbusKit

  NimbusKit是一个非常适合有经验的开发人员使用的文档完整的iOS开发框架,并且提供了模块化的方式来将解决iOS开发的各种不同需求.最重要的在于经常的性的发布新的组件和特性. 主要组件包括: 支持超链接的label web view 组件 标准化的程序通信 强大的debug工具 完整的文档 其它更多特性   支持超链接的label web view 控制器   信息提示徽章 图片浏览 标准化的程序通信   更多的特性,请参考网站的组件介绍,希望大家喜欢这个iOS开发框架!

ISO文档管理——企业BPR的助手和驱动引擎

随着企业业务发展及与国际化接轨的要求,国内企业迫切需要采用成熟的ISO管理标准体系改善自身管理环节,提高管理水平,同时通过对自身管理体系的认证来给客户以信心和保证.因此目前国内企业对ISO 9000(质量管理体系).ISO 20000(IT服务管理体系).ISO 27001(信息安全管理体系)等先进管理体系的认证方兴未艾. 在各种ISO管理体系中,都需要对大量文档进行管理,包括: ·对文档生命期进行管理.任何管理体系都需要用文档定义各种规程.表单等,这些文档从就绪.公示.发布.生效.版本升级直到

设计理论:制作网页前端开发的文档

前端开发的文档相信大多数情况下都没有后端的服务描述详细,而大多数测试也仅仅在黑盒测试,所以很多情况下对这片文档的描述都廖廖无几. 前端文档缺失的原因 前端开发的文档相信大多数情况下都没有后端的服务描述详细,而大多数测试也仅仅在黑盒测试,所以很多情况下对这片文档的描述都廖廖无几. * 前端开发的代码分散--没有规范化,没有很好的设计,大多数人仍以业务为主的开发方式.* 测试人员对前端仍然处于黑盒测试,有没有文档都不影响到他们的测试进程.* 一旦业务定型,用传统方式的文档模式,很难复制到前端开发来.

jax rs-请问在REST开发中有没有类似Javadoc的文档生成器

问题描述 请问在REST开发中有没有类似Javadoc的文档生成器 请问在REST开发中有没有类似Javadoc的文档生成器,@后能快速生成文档? 目前使用的Spring,Jersey,Mybatis开发.

敏捷开发学习分享

程序员都很懒,你懂的! 敏捷不是快,而是拥抱变化(不断反馈的一个过程).                                                        简单的说,敏捷开发是一种以人为核心.迭代.循序渐进的开发方法.在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态. 敏捷原则:主张简单,拥抱变化,可持续性,

敏捷开发 PK 瀑布模型

   在去年12月底开始接触高校平台项目,到现在也快有小半年了.这次的开发不同以往.是以敏捷开发作为开发方式.以前都是遵循传统的瀑布模型,而新方式的开发思路直接与传统的开发思路来了个正面碰撞,擦出了阵阵"火花".     在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经根深蒂固,再加上对需求不熟悉,对开发环境不熟悉,新方式的开发反而让人感到别扭,麻烦,甚至抵触.     由于对敏捷开发的不理解,大家也爆发了很多争论,不过也正是这些争论,引导我们逐步走