项目说事--又是一年三月三

原创 2013年12月02日 09:03:19

    这些日子在合作开发一个C/S的项目,在接手项目时对这个项目有过很浅显的了解,只知道这个项目是做一个粮库管理的软件,听了几次她们对项目需求的讨论,那时候认为很简单,错误就出现在了这里。直到如今,接手这个项目有不到半月的时间了,在开发时发现这个项目本身的复杂性。从最初讨论对项目需求的认识,到技术的实现,着实遇到了很多问题。


一、要做好,就要了解好需求


    首先是搞需求。在我们新加入开发小组的时候,这个项目已经开发了有一个多月的时间了,大部分时间都是在搞这个系统到底是要做什么。当进入项目小组时让我很悲凉的一件事是系统需求分析完成后没有一个明确的需求分析文档,更没有明确的概要设计说明,到最后稍微感脚舒服点的总算是有对数据库表结构的一些描述(包括表中的字段及类型的描述)。不过在开发过程中还是有让人很欣慰的事情,就是有系统的原型,对开发人员和客户之间的交流很有帮助。对有经验的开发人员看到原型,就能知道系统背后的技术实现。

    后来为了让我们快速的进入开发状态,小组组织了两次系统需求的讨论,通过讨论发现了很多以前没有发现的问题,尤其是在系统需要串口通信部分,给的那个文档说明有很多疑虑,而且没有实际的硬件作为开发测试使用,也不知道数据获取的方式。俗话说不入虎穴焉得虎子,为了能搞懂我们小组又组织了一次和客户的交流,最后不负众望,项目的需求取得了突破性的进展。


    其实上面说的一些废话并不重要,我看重的是这个过程,在这个过程中发现了很多问题,坚定了我对项目开发写好文档的认识,同时也证明了交流的重要性。对于客户他们往往对系统和技术毫无概念,只知道需要做一个什么东西,于是给了你一大堆的资料,而这些资料中很可能对需求的分析收效甚微。遇到上面的情况怎么办,就必须找到适合的开发模型,据我所知适合的开发模型有两种演化模型和增量模型,它们的优点都是为了降低了风险,其中演化模型是降低软件需求不明确带来的风险,而增量模型可以很好的适应变化,客户可以不断地看到开发的软件,从而降低风险。这两种模型似乎都很适合我们的开发,但实际情况并非如此,现在对于中小企业往往没有这么好的开发规范。所以最后使用的是敏捷开发方法,敏捷开发并不是一种模型只能说是一种方法,开发人员互相交流增加对系统的认识,实现快速开发,再软件完成后在补充文档,然后再通过重构精华软件的开发。这种方法是中小软件公司很盛行的开发方式,从开发方式上就已经衡量出了公司的水平。

    对于上面的问题解决办法有两种,其一:去和客户交流,一点点地获取我们想要的东西,客户是消费者,开发人员是服务者,想要做好服务就要做好客户的需求;其二:利用现有资料快速构建系统原型,让客户使用原型了解自己软件的功能。不过不知道为什么老师为我们选择了一种敏捷开发的方法来开发项目,可能是为了磨练我们这些幼苗吧。敏捷开发很能磨练人……

 

二、说说技术


    对需求有了深入的了解后,就要进行实际的开发了,技术对程序猿来说是小事,需要细心、耐心、时间+开发资料(技术参考资料)。说起来很简单,但在实际开发中着实遇到了些问题,在前期主要是算法、线程、XML和数据库的一些问题。

    有关算法、线程和XML的一些问题,将会在接下来的文章中陆续更新,这里就来说说有关数据库的。

    数据库是很博大精深的一门科目,好的数据库设计能够大大简化开发人员的代码量,同时也增加了数据库的复杂性。这是一把双刃剑,数据库结构设计的越复杂,触发器啦、存储过程啦、主外键约束啦使用的越多,说明数据库的独立性越差、灵活性越差、迁移性越差。

    1、触发器一种特殊的存储过程,缺点:运行不可控制,降低了系统性能,可移植性差。

    2、存储过程,比触发器更高效,类似于编译好的函数,迁移性差,遇到数据库迁移是件很头疼的问题。

    3、主外键约束,看似很重要,在创建表结构时可以通过约束确保数据完整性,这里来说说外键的缺点。外键对业务数据进行了绑定,失去了数据操作的灵活性;对数据进行增删改查时会降低性能;在对数据进行迁移时会遇到很多问题;给大表做表分区时外键不可取(如果分区表很多,不可能对多个分区表都创建主外键关联约束)。

 

    虽然很多问题,但有让我很欣慰的事情,客户为我们提供了他们以前使用的系统。为了能够快速的了解需求,同时也是本着学习和借鉴的目的,使用反编译对原系统进行了架构解析,得到了完整的原系统的源码和架构信息,可是让我愕然的是原系统的架构那是一团糟啊。我们平常开发大多是类爆炸,但是原系统却是程序集爆炸,他们采用的是承包制,也没有接口,都是引用关系,每个功能分配给一部分人去做,做完后供我调用,架构很乱,开发的很多都是组件和用户自定义控件,不过这也是好事省去了我们编写的时间,可以直接借鉴过来。但是很多没有接触过的技术需要我去虚心学习,如:GDIStruct、线程、串口……总之,努力吧!

    有关架构解析的文章也会在接下来的文章中陆续更新。


三、发人深省


    事在人为,没有过不去的门槛。又是一年三月三,开发还在继续,需要学的东西还有很多,我是幸运的,可以得到一次这么好的学习机会,这都是我们宝贵的经验,同时也是提升价值的利器。

    前进吧,少年……

又是一年三月三

  又是一年三月三   风筝飞满天   牵着我的思念和梦幻   走回到童年      记得那年三月三   一夜难合眼   望着墙角糊好的风筝   不觉亮了天   叫醒村里的小伙伴   一同到村边   ...
  • treeclimber
  • treeclimber
  • 2011年03月04日 12:36
  • 479

又是一年好风景

Normal 0 7.8 磅 0 2 false false false Microsof...
  • dancing999
  • dancing999
  • 2009年02月16日 11:13
  • 401

又是一年木棉红

生命的价值,是语言所无力描述的。你以自己的微薄之力,奉献了一份最伟大的礼物,享受人生的美好吧。当明天你看到旭日在海面照耀时,你就会对自己说:“如果没有我,世上就会少一人欣赏这瑰丽的旭日。” ——毕淑...
  • zhulin75
  • zhulin75
  • 2014年04月22日 17:43
  • 162

又是一年了。

斗转星移,花开花落。希望可以在新的一年里做的更好。
  • Fandehena
  • Fandehena
  • 2010年12月31日 09:54
  • 197

又到三月三

    今天同学带了个鸡蛋给我吃,说是过三月三。很诧异三月三是个什么日子,所以上百度查了一下,贴过来,看看有没有人会到我这里看到。     每年农历三月初三,畲族百姓都欢度“乌饭节”,家家都做乌米饭,...
  • ssrzw
  • ssrzw
  • 2008年04月07日 22:27
  • 222

又是新的一年,我要有新的开始

从今天开始一定洗心革面,从新做人!!!!
  • ironox
  • ironox
  • 2006年02月12日 16:59
  • 456

又是一年,我的2013年终总结

今天是冬至(2013年的12月22日),日历摆了乌龙,不少人提前把节给过了,再过一周2013也就算过完了,我的博客在这一年中一直没有更新,惭愧!过去的一个年头里,一直感觉很忙,也不知道在忙活些什么,来...
  • liquanhai
  • liquanhai
  • 2013年12月24日 00:04
  • 6447

跌跌撞撞的2017有感

蓦然回首,2018逼近,距离自己刚踏入校园已有3年之久。昨日恍然如梦,似乎不是那么真真切切。若有所思所感,就全写入这博客里。到通信工程学院报道的第一天,那时我还是那么青涩懵懂【ps:有点傻^_^,高德...
  • qq_32468225
  • qq_32468225
  • 2017年12月31日 19:52
  • 34

2016年终总结——碌碌无为无所事事的一年

越长大越觉得时间过的真快,浑浑噩噩的日子,机械式的生活,眨眼之间突然发现2016即将逝去。每每此时即是我们回望过去,展望未来的日子。 回首我的2016,八个字总结:碌碌无为,无所事事。 是的,自从去年...
  • zsp765098084
  • zsp765098084
  • 2016年12月30日 15:28
  • 393

又是一年

      2006年是郁闷的一年,也是离别的一年,还有奔波的一年。365天似乎只是几个小时,而我现在仍然在挥霍自己的时间。朋友的blog上 写着:曾经最渴望不平凡的人如今却日渐平凡。想想看我不也是如...
  • mars131
  • mars131
  • 2007年01月08日 14:01
  • 613
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:项目说事--又是一年三月三
举报原因:
原因补充:

(最多只允许输入30个字)