运动会报名系统的启发

 

一、需求分析的重要性

       之前做的程序基本上都是一些练手的小项目，当时，主要以技术为主，不管需求是否合理，不管界面美丑，不管用户体验性好坏，不管代码是否优化，只要功能实现了，心里就挺美的。现在随着报名系统一个个功能的实现，越来越深刻的意识到：在技术方面，真的是只有想不到没有做不到。而最终决定软件成功与否的关键还是在于需求，因为产品最终是要面向用户，做出来的东西不是人家想要的，即使做出花儿来也不会有人说好。最惨的就是如果需求大动一次，可能后面的一堆代码都要推掉。

      如何做出用户满意的软件？目前我体会到的应该包括以下几方面：

     1. 和用户做好沟通，获取更详细的需求。

        需求分析人员要搞清楚用户到底想要干嘛、必要时要诱导客户将自己的需求说清楚，然后在需求分析、开发原型后用实物和客户交流。

       我们这次做的运动会报名比较特殊一点，没有用户面对面的交流需求，只有一份运动会说明的文档还算详细，之后，我们两个体育系学生根据文档和体育经验开始模拟需求。和用户沟通这块就省略不写了。

    2. 软件开发人员也要具备多方面的素质

（1） 熟悉、了解待开发软件的领域。如果自身不了解，至少要在需求分析的过程中去查阅资料，了解一些相关领域的知识。

（2） 要具有全心全意为用户着想的态度。要本着满足用户最大需求、保证用户体验性最佳的目标来设计。

（3） 平时多积累专业性的东西，开阔思维。

          就拿报名系统为例，网上有好多各种各样的报名系统，他们的思路都可以拿来借鉴。借鉴几个报名系统，发现最一般的流程都是：登录——报名须知——报名——注意事项，我们在此基础上增加了短信通知的功能。再看每个系统的报名模块：填写个人信息、上传照片、查询个人信息。再深入一点，关于修改报名信息是个挺庞大的工作量，一修改，会涉及到好多变动，参考多个报名系统发现：有好多系统都不允许修改报名信息。

二、设计系统架构

      一个好的系统架构使程序结构清晰、易于后期维护，同时程序员写起代码来也觉得很舒服。不过，这个架构设计还得需要一定的经验啊！现在水平有限，编码时有时候自己都觉得自己设计的很烂，别人看起来肯定也很不爽，可能这也是我们俩人合作时间有点长的原因之一吧。

     这方面要想取得进步，还得好好积累项目经验，还要多阅读别人的代码，借鉴别人的思路，同时还要多学习设计模式。

三、编码阶段

      1. 技术上的收获：数据库连接、事务、批量导入数据、正则表达式、打印、调用外部接口、SVN的使用……

      2. 编程规范牢记心中，注释、格式都要落实到代码中。方便自己和他人阅读，方便后期维护。只要一写代码就要按照规范来，要时刻培养专业素质。

     3. 大家都知道，保证程序健壮性的代码也占很大的比重，而且也是程序不可或缺的。在做报名系统中，我的切身感受就是：保证程序健壮性的代码不可省略，而且尽量在第一遍写的时候就一气呵成，省得第二遍再补，这样相当于一个地方做了两遍，而且最主要的是不是每次看写过的代码时思路都像第一次时那么那么清晰的。平时也要养成这样的好习惯，不要主要功能实现了，一兴奋其他事情都不管了。

   4. 代码需要积累

       首先，当自己非常熟悉某个实现的原理，却又在代码的语法上花了一些时间，这样就不划算了，所以，平时可以多积累一些代码，会给自己节省好多时间。

      其次，熟能生巧，代码写的多了，就会由量变到质变，自然就越写越顺手、越灵活。

   5. 平时多注意观察、积累。开阔眼界

        写了这么多代码，也深刻的体会到“只有想不到，没有做不到”这句话，技术真的不是问题，怕的是没有思路，没有想法。要想有合理的方案，有更好的方案，怎么办？————多观察、多积累，开阔眼界。

        举例来说：当文本框输入的字符长度、数字/汉字、时间格式等等不符合规范时，看看别人是怎么做的，都是在什么时候给出提示，以及给出提示的位置（美观）……

       某个功能，也许早已存在现成的控件，那么就不需要自己再去苦想了；

      某个功能，它的实现方式也许早已成形，早已被大众认可（例如修改时间：点击文本框直接出现日历），那么，这时候直接参考就可以了，不必再绞尽脑汁，费尽思量了，有可能花时间设计了半天还没有现有的这个好。

   6. 态度

      程序的健壮性和写的代码是成正比的，不要偷懒； 尽量多参考现有模型，多从使用者的角度考虑，使做出来的程序具有更加的用户体验性。

   四、测试、发布待续……