项目总结
通过这次RFID数据采集程序的设计与开发,从编码能力,编码效率,解决问题的能力,分析问题的思维都受益匪浅都获得了很大提高。为以后的软件开发奠定了良好的基础。不过也发现了自己的不足,正视利弊下面就详细的赘述个人项目中的总结。、
一、 开发前期
开发前期设计中存在的不确定性。浪费了快三天的时间,这个问题的产生经过事后的分析,原因有如下。
项目开始的时候没有对开发环境,开发语言做一个深度的可行性分析,从而导致软件和开发语言方向性的错误。本项目中的失误就是开始确定用VB做开发,而忽略了VB在本项目中的不足,导致浪费3天的准备时间。如果开始确定就用C#或者JAVA开发,就可以为本项目的成本节约3天或者为后期的系统完善提供充足的时间。针对这种情况的解决方法,个人观点如下:
首先,立项的时候与下层开发人员做一个了解。 了解他们对这个项目中的观点,及其意见。他们可能会提出或者请教出一套合理高效的解决方案。
其次,加强个人素质的锻炼,如果出现上面的失误或者发现其它类似的问题,能及时提出自己宝贵的意见。这就体现公司团队的智慧,只能加强个人的能力和技术积累。除此之外没有什么特别好的解决方法。
再次,技术交流。这个在软件研发部内部做的比较好,但是如果这样能扩大到一个公司里面的软硬件就会更好。原因:在公司里面部分人员是具有丰富工作经验的技术人员,我们要做某方面的工作。他们可以把以前所在公司里面经验教训给我们说说指点一下。别的公司成熟可行的方案能直接使用,我们为什么不直接用而要自己去琢磨,在别人成功的基础上,加上自己的提升,就是一个更成功的方案或软件。交流不要局限于但前的工作。我们要的思想和知识面。
二、 开发中期
1、 防止盲目开发
刚开始做这个项目的时候就给我来一个致命打击,开发中的盲目性。盲目性的产生有如下这几方面的问题。
项目上问题: 整个项目从立项到开发,没有任何文件,没有任何纲要性的东西,单凭部门主管的口述是无法提供一个可行的依据的,因为有语言上的表述失误也有开发者理解上的失误,避免这种情况的发生不是一个部门主管就能改变的,也不是一个软件工程师就可以解决的。综合考虑公司发展阶段的特点和矛盾,必须让这种盲目开发的现象逐渐有条有序的从项目中取缔掉,这样能省很多时间。
个人问题:当存在疑问的时候,应该抱着求甚解的思想去对待。不清楚目标,不要盲目去动手,这个方面是我在项目中的感触最大的有非常深刻的教训,不要嫌自己啰嗦,了解的越详细,目标会更明确,自己成长的也快,对公司的发展也好。这是一种习惯,也是一种好习惯,一定培养注意,最好不要犯这样的错误。
项目透明:对于负责这方面开发的主要技术人员,最好对他们要做的,他们在做的项目恍┲匾 鞯耐该鳎 庋 梢蕴岣呦钅康淖酆现柿俊?他们自己都不清楚自己要做什么,那何谈把东西做好。
2、 加强基础知识的巩固
这次在做项目中由于对数据结构知识的一知半解,开始的设计上出现了很不合理的状况。从这个方面可以引申到别的方面我们应该从下面这些方面去认识。
首先,加强知识通用性。不管是C语言,还是C#还是Java都有语言上相通的地方,在解决某方面的内容可以用不同语言的思想去解决。例如:C语言里面的链表在C#里面对应了有链表类,有Hash链表,C#不支持指针但是可以用仿写指针的功能。Java里面也同样具有。
其次,牢记基础知识。鉴于这次的失误,花了几天时间恶补基础知识。同时经过这次的经验,也开始对C#做一个系统的复习。对自己有很大的帮助和提升,特在这里提出来还有一个原因,忘记是难免的,但是一定要重视这个现象。
再次,虚心接受别人的指教和提醒,也许会有一语惊醒梦中人的作用。
3、 编码规范和习惯
这个方面是团队中开发非常重要的,无规矩不成方圆,无规范何来高效的代码,无规范何来高效的团队。自己在总结以前做PHP中的一些不足,这次在项目中时刻提醒自己要注意编码规范,这方面我也琢磨出来一些自己特有的感觉比较规范内容。
首先, 根据软件特色自己采用合理的命名规范和书写规范,除了别人经常提到的那些编码规范,你可以加上自己或者开发内部特有的规范。例如:自己声明的变量我们可以self开头然后加上类的简称如果是全局变量还要加上全局变量的属性(如selfHastStrName意思自己定义的在Hast类里面的string类型表示姓名的变量)这样在做之前就有一个规范说明别人一看就懂,这也许不是特别好的方法,但是在团队内部只要统一出一套合理的,那就好方法,不然有几十个类然后要用到某个类里面的静态变量你怎么找。
其次,类和方法命名应该也和上面一样,这样也能提高阅读性。除了像上面一样我还在整个类的前面多加了一个多行注释。这个注释里面包含的东西是当前类里面用过那些全局变量,那些方法名,这个方法的功能、与那些类相关联做一个简单的描述。别看这个小功能,在实际开发中非常重要,特别是多个人操作一个类的时候,防止重复定义方法名和变量名。我使用了快两个月觉得很合理。
再次, 为了弥补上面的不足,强烈建议大家一定要对类和方法加”///”注释。对你的方法功能尽可能的详细出来。当别人使用你的方法和类时就不用花很多时间去理解你的思想,提高团队效率。除了”///”注释外,尽可能的把所有局部变量和局部结构都加上注释。 至少也要把特殊的变量结构加上注释吧,你都这样做了,阅读性也一定会高的。
上面的这些内容都是我的工作经验,我的总结,希望对大家有帮助,能加强公司内部技术交流。