项目总结

通过这次RFID数据采集程序的设计与开发，从编码能力，编码效率，解决问题的能力，分析问题的思维都受益匪浅都获得了很大提高。为以后的软件开发奠定了良好的基础。不过也发现了自己的不足，正视利弊下面就详细的赘述个人项目中的总结。、

一、 开发前期

开发前期设计中存在的不确定性。浪费了快三天的时间，这个问题的产生经过事后的分析，原因有如下。

项目开始的时候没有对开发环境，开发语言做一个深度的可行性分析，从而导致软件和开发语言方向性的错误。本项目中的失误就是开始确定用VB做开发，而忽略了VB在本项目中的不足，导致浪费3天的准备时间。如果开始确定就用C#或者JAVA开发，就可以为本项目的成本节约3天或者为后期的系统完善提供充足的时间。针对这种情况的解决方法，个人观点如下：

首先，立项的时候与下层开发人员做一个了解。 了解他们对这个项目中的观点，及其意见。他们可能会提出或者请教出一套合理高效的解决方案。

   其次，加强个人素质的锻炼，如果出现上面的失误或者发现其它类似的问题，能及时提出自己宝贵的意见。这就体现公司团队的智慧，只能加强个人的能力和技术积累。除此之外没有什么特别好的解决方法。

   再次，技术交流。这个在软件研发部内部做的比较好，但是如果这样能扩大到一个公司里面的软硬件就会更好。原因：在公司里面部分人员是具有丰富工作经验的技术人员，我们要做某方面的工作。他们可以把以前所在公司里面经验教训给我们说说指点一下。别的公司成熟可行的方案能直接使用，我们为什么不直接用而要自己去琢磨，在别人成功的基础上，加上自己的提升，就是一个更成功的方案或软件。交流不要局限于但前的工作。我们要的思想和知识面。

二、 开发中期

1、 防止盲目开发

刚开始做这个项目的时候就给我来一个致命打击，开发中的盲目性。盲目性的产生有如下这几方面的问题。

项目上问题： 整个项目从立项到开发，没有任何文件，没有任何纲要性的东西，单凭部门主管的口述是无法提供一个可行的依据的，因为有语言上的表述失误也有开发者理解上的失误，避免这种情况的发生不是一个部门主管就能改变的，也不是一个软件工程师就可以解决的。综合考虑公司发展阶段的特点和矛盾，必须让这种盲目开发的现象逐渐有条有序的从项目中取缔掉，这样能省很多时间。
   个人问题：当存在疑问的时候，应该抱着求甚解的思想去对待。不清楚目标，不要盲目去动手，这个方面是我在项目中的感触最大的有非常深刻的教训，不要嫌自己啰嗦，了解的越详细，目标会更明确，自己成长的也快，对公司的发展也好。这是一种习惯，也是一种好习惯，一定培养注意，最好不要犯这样的错误。

项目透明：对于负责这方面开发的主要技术人员，最好对他们要做的，他们在做的项目恍┲匾 鞯耐该鳎 庋 梢蕴岣呦钅康淖酆现柿俊?他们自己都不清楚自己要做什么，那何谈把东西做好。

2、 加强基础知识的巩固

   这次在做项目中由于对数据结构知识的一知半解，开始的设计上出现了很不合理的状况。从这个方面可以引申到别的方面我们应该从下面这些方面去认识。

   首先，加强知识通用性。不管是C语言，还是C#还是Java都有语言上相通的地方，在解决某方面的内容可以用不同语言的思想去解决。例如：C语言里面的链表在C#里面对应了有链表类，有Hash链表，C#不支持指针但是可以用仿写指针的功能。Java里面也同样具有。

其次，牢记基础知识。鉴于这次的失误，花了几天时间恶补基础知识。同时经过这次的经验，也开始对C#做一个系统的复习。对自己有很大的帮助和提升，特在这里提出来还有一个原因，忘记是难免的，但是一定要重视这个现象。

再次，虚心接受别人的指教和提醒，也许会有一语惊醒梦中人的作用。

3、 编码规范和习惯

   这个方面是团队中开发非常重要的，无规矩不成方圆，无规范何来高效的代码，无规范何来高效的团队。自己在总结以前做PHP中的一些不足，这次在项目中时刻提醒自己要注意编码规范，这方面我也琢磨出来一些自己特有的感觉比较规范内容。

   首先， 根据软件特色自己采用合理的命名规范和书写规范，除了别人经常提到的那些编码规范，你可以加上自己或者开发内部特有的规范。例如：自己声明的变量我们可以self开头然后加上类的简称如果是全局变量还要加上全局变量的属性(如selfHastStrName意思自己定义的在Hast类里面的string类型表示姓名的变量)这样在做之前就有一个规范说明别人一看就懂，这也许不是特别好的方法，但是在团队内部只要统一出一套合理的，那就好方法，不然有几十个类然后要用到某个类里面的静态变量你怎么找。

   其次，类和方法命名应该也和上面一样，这样也能提高阅读性。除了像上面一样我还在整个类的前面多加了一个多行注释。这个注释里面包含的东西是当前类里面用过那些全局变量，那些方法名，这个方法的功能、与那些类相关联做一个简单的描述。别看这个小功能，在实际开发中非常重要，特别是多个人操作一个类的时候，防止重复定义方法名和变量名。我使用了快两个月觉得很合理。

   再次， 为了弥补上面的不足，强烈建议大家一定要对类和方法加”///”注释。对你的方法功能尽可能的详细出来。当别人使用你的方法和类时就不用花很多时间去理解你的思想，提高团队效率。除了”///”注释外，尽可能的把所有局部变量和局部结构都加上注释。 至少也要把特殊的变量结构加上注释吧，你都这样做了，阅读性也一定会高的。

上面的这些内容都是我的工作经验，我的总结，希望对大家有帮助，能加强公司内部技术交流。