esri开发大赛项目总结

     esri开发大赛项目已经完结，每一次项目的完成，都应该有一次总结，这也一向是我个人的习惯。

     对于这次参加比赛的作品开发过程，其实这里我也不确定这能否真正称得上是一个项目，毕竟这其中存在着很多问题以及极其不规范的地方。但在这里我姑且将其称为一个项目吧，只是他可能不完整罢。现在已经大四，面临毕业、择业、就业或者其他的选择，在学校的日子也已经不多了，或许这也是大学期间做的最后一个项目了，严格意义来说应该是在大学最后期间做的最为完整的一个项目了，每一次的实战历练，对自己都是一次很好地提升，在项目开发过程中所遇到的问题更是值得去进行总结和反思，这才是项目实战的意义所在。

     三月中旬，四个人的团队组建起来，算是真正开始了开发大赛。但一切都是未知的，很多东西都得打上一个问题。

     第一个问题便是选主题的问题。按照软件项目开发流程来说，便是需求分析的问题。选择什么主题内容？ 选择什么何种开发？ B/S？ C/S？ 这所有的问题都得解决。好在人多，这个想一个，那个再想个，主题算是确定下来，也没有去仔细地去考虑到选择这个主题后面要面临的东西，更多地去考虑这个主题是否够新颖，觉得很新颖，觉得没见过，好，ok就是这个了！。_  。这个主题在B/S(作品是在B/S下)的开发下是否够有优势？选择这个主题是否具有很好的功能扩展性？按照我们自己现有的想法搞下去是否真的可行？我么搞这个主题在数据收集上是否是存在很大的难度？。。。这些问题，在讨论主题的时候似乎都是没有涉及，或是设计的很少，现在想来，的确觉得当时的我们无知的有点过了。好在人多胆大，这个新颖，这个别人没搞过，我们就搞这个吧，主题这样便是定下来了——“基于GIS的中国近代历史名人事件年谱”。需求分析是一个搞清楚接下来应该做什么的过程，而在整个开发的开始，却将其忽略地那么彻底，这算是项目开发中一个致命错误。需求的不明确，将直接导致后面整个系统设计阶段的全面崩盘。

     系统设计怎么搞？数据库该怎么设计，一拖再拖，大家都不知道究竟该怎么搞下去。在这个地方，犯了一个错误——“数据库的设计究竟是应该围绕功能来设计，还是功能应该围绕着现有的数据以及数据库来来设计？”。“数据库与功能谁应该是主导”这个问题其实我一直在思考，

如果把数据库给改了，那之前想的功能又怎么办，功能又实现不了，如果按照功能来，数据库的设计模式好像的得改，怎么办？后来才搞明白数据库与功能之间的关系其实怎么想都应该相互依赖的关系，其实不存在什么主导关系，但如果非要哪个才是主导地位的话，我想是数据。越到后面的开发过程，越会明白这一点的，数据库对数据进行管理，只是作为一个数据的存储管理容器，功能的设计是为了将数据呈现或是在另一个方式下通过数据库的操作来对数据进行管理。所以数据库和功能之间其实不存在什么主导地位，而应该相互依赖的关系。他们两者相互联系的纽带这是围绕着数据来展开的。所以在这一点可见在第一阶段需求分析的重要了，不明确要做什么，不明确系统需要呈现些什么、需要些什么数据，这都直接导致系统设计阶段的数据库设计出现很大的困难。在这里我是搞懂了团队内专门负责数据的伙伴，为什么一直都在说不知道应该怎么找数据了。一切都得归咎于需求的分析不明确。另外，在系统的设计阶段，团队除了一直搞数据库、收集数据库之外，也没有将我们整个系统的各个功能给彻底地细化，尤其是对于做web开发来说，涉及到的东西很多，都没有一个明确的文档性规范，尤其对各个功能实现所要涉及到的大体内容都没一个集体性地讨论，直接导致了开发编码过程中各自为站，进度缓慢，代码风格各异。

     编码阶段。对于这个方面，对于系统框架什么的我就不去讨论了，毕竟自己还是个coder ，只能对在这个阶段中自己出现的很多代码规范性上的东西多做下总结。在做这个开发之前，自己也已经自学过了一段时间的web了，但是，终究纸上得来终觉浅，绝知此事要躬行，缺乏实战是不可能把编程学好的，所以这应该是第一次完整的真正动手实战。webgis的开发不像常规的web开发，除了建立常规的属性关系数据库之外，还需要地理数据库，我主要负责属性数据库边的开发，另外一个同学负责与地理数据库的处理，与地图的交互操作。对于属性数据库的操作部分，我最开始采用的是Apache+PHP+mysql的结构，一开始也没什么问题，指导老师也没有说什么，就这样搞了近一个月，老师让数据库换成access，后台用Csharp，没办法，改吧，其实还是有那么一点抱怨，但是还是花了近一个周的时间给换了过来，好在花的时间不多。在后台结构上采用了常规的三层架构，其实后来我发现这对于我们这个小项目有点大材小用了，对数据的操作基本涉及到的是查询操作，多表查询操作有比较多，采用三层结构，又得一个一个去写实体，一层一层往前端传数据，也是将本简单的东西搞得有点过于复杂了。但经过这样一次的实际操作也让自己对三层结构有了更深刻认识，收获挺大。在编码上，代码命名的规范性特别重要，在项目的编码开始初期，还不会发觉，越到后面越会发现，命名的重要性，对于不同方法，都应该严格根据其实际用途来命名，不能随便给个命名，在某处调用了一个方法，到最后可能自己都得去看方法体本身才知道是干什么的，浪费时间，自己看着也不爽，最好是见名知意，比如GetdeventDescById(),见名知意，看着也舒服。另一个方面就是代码的组织上，十分凌乱，功能分析的不彻底，导致做到哪儿写到哪，写一个小功能模块的时候不能想到在另一个地方还会用到相同的代码，直到写到下一个模块，才发现好像是同上一个功能模块一样，赶快有掉头回去改代码，将前面已经写好的功能又拆开来封装写个方法，如此一来明显感觉到整个代码极其的糟糕凌乱，代码的强健性也极其的降低了。极其浪费时间，在系统设计阶段没有对功能进行仔细的剖析和规划，这些都会导致这一系列的问题。

     最后就是系统整合版本控制问题，两个人或者几个人同时开发者，集成的时候，由于前端也是我在写，我倒是将我所有的东西都写在一块，前端后台都在一块，倒也不存在什么问题。我拿出第一个版本来让另外的人往上面集成他们写的工能的同时，我又发现我这边的前端界面要改一下，后台代码得改一下，改了之后，产生了一个新的版本，而别人又在之前的那个版本上集成了部分功能，没办法，又让在新的版本上集成，如此一来，又浪费了很多时间。版本控制做的也是不够好。

     总结就到这里，仍然还有多需要提高的地方，仍然还有很多需要学习的地方。每一次的历练都是一次提升，每一次提升都来源于点滴的积累。