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

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

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

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

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

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

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

 

二、说说技术

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

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

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

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

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

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

 

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

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

三、发人深省

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

    前进吧，少年……

 

转载于:https://www.cnblogs.com/fuhaots2009/p/3454053.html