对于一个可以跑的版本的经验总结.

看了很多的项目管理.发现大多数人都认为要出来一个可以先跑起来的版本.
但是个人认为这个可以跑起来的版本应该注意以下的几点.(这里只针对做web开发,对于c/s的开发不知道是否适用)
第一:不要为了这个跑起来的版本将代码书写的非常乱,省去大多数的注释.因为当你说要出一个可以跑起来的版本的时候,一定是压缩了很多的时间来做的,可能为了最后的测试我们会把压缩代码时间,压缩注释书写的时间,但是这样做的后果就是,导致在你修改的时候会非常的累.一定要保证代码的书写和注释的书写.

第二:一定要确保代码的模块强分割性.模块的强分割性(我自己造的词)?就是可以很容易的将一个模块分割成两个或者多个模块.为什么这样做呢?对于客户来说一个可以跑的版本就相当于一个只剩下修改修改的版本了.他们脑子里的概念是这个版本已经完成了开发95%--99%的工作,剩下的东西都很简单了.实际上呢?我们最清楚,这个版本可能只完成了80%的工作,里面还有好多存在潜在危险的bug.如果分割性强了,我们可以很容易针对后来客户提出的修改.

第三:模块内要尽量减少冗余.为什么要重申下这点呢?我发现好多的程序员因为一个大的方法里要实现很多功能的时候,就直接在里面写,导致最后模块内的冗余非常的多.那么当客户看到这个可以跑的版本时候,他们会要求一而在,在而三的要求你修改.这个修改很能会将以前的代码有很大的改动,因为我们为了出这个版本很可能没有考虑到减少冗余,很可能这个系统都是冗余的,到最后的结果是改一个地方出一堆bug.

第四:这个版本应该更多的是将展现出来的页面设计的非常漂亮.为什么要说这样说?因为当客户看到一个好的页面后会有很大的赞同,而且他们会在每次看版本的时候重点关注页面上的美化工作,对于修改的部分他们会提出的比较少(客户的注意力都集中到页面上去了).运气好了他们认为这个版本的美化工作已经做完,那就更好了,我们剩下的就是有充分的时间将其他没有加上去的东西和bug弄好.

第五:当这个可以跑的版本出来后多与客户交流沟通.要他们尽量多的提出自己的修改意见.每次提出后就给他们看新版本.这样做有两个好处.1)要他们可以看到我们的服务是多么的周到,可以给公司带来好的形象.2)尽量挖干他们要修改的东西.如果要修改大方向,我们可以拿出来以前的需求给他们看.小地方做好会议纪要就改上就可以了.

以上就是个人总结做b/s的一些经验.这些经验是当时和政府部门做项目的时候总结出来的.希望对大家有帮助.

winnerzone