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

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

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


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


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

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


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

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

 

二、说说技术


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

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

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

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

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

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

 

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

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


三、发人深省


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

    前进吧,少年……

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

GooGle推广-Google排名不是靠作弊

前一段,有一个让我做网站推广的客户在做完以后,非要让我把我文章中关于他的内容删除了,最后问其原因,差点让我晕倒。他以为Google排名是一种作弊的网络营销方法。近一段,随在在各个中文搜索引擎中输入“g...

项目说事——信不信反正我信了(合作开发总结之文档)

信不信反正我信了。这句话让我很无耐啊,是啊经历过合作开发的程序猿应该都有着同感——无耐。项目开发应该是件高兴的事,挣钱嘛、工作经验啊谁不高兴,可是问题又来了,以前只是个人开发项目啊,文档好歹写写,图好...

测试人员对 RUP 四个阶段的贡献:另一种观点(一)

1.1.1  本文来自于 Rational Edge:在对软件迭代开发生命周期中的测试人员的作用进行探讨的同时,作者 考虑,除了 RUP 测试规程中提供的描述,测试人员还能如何对项目做出广泛的贡献。 ...
  • szstc
  • szstc
  • 2007-06-05 14:42
  • 327

获取多维数组的行列数(C#)

data是一多维数组,则可以获取该数组的行列数如下: nRow = data.GetLength(0);  // The dimensions of rows. nCol = data.GetLe...

【SSH2(实践篇)】--Struts2文件上传下载实例

struts的文件上传和下载使用的是io流操作完成的,可以使用java.io流,同样可以使用第三方的common.io流实现。Struts2并没有提供文件上传的组件,所以想要实现上传的功能就必须通过第...

8.27

愿意做别人不愿意去做的事情是超越的捷径。站着做人是应有的骨气,然而该低头就低头则是立身处事不可缺少的修养。琢磨他人,只会自寻烦恼。保持泰然自若的风度,审时度势,在有些方面,如果完全有条件与人竞争,则低...

Struts2文件上传下载实例

上篇文章又一次回顾了Struts2的运行机制,对它的运行步骤做了一步步的解析,这个解析不但再一次理清了Struts2的使用方法,而且对它的映射机制进行了深入的解析,并在最后通过一个实例来介绍了Stru...

反射,反射--程序员的快乐?

前几天帮助一位网友解决了一个问题,大概是他们公司的老板做了一个项目,听他的描述项目不是很大,但是他们老板想要做到程序的解耦,也就是说他们封装了一个dll文件,在上层调用时不提供给他们引用关系,对外的设...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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