CS项目总结

最近作了近一年的CS项目终于接近完工了,有一种脱离苦海,跳出泥潭的感受。虽然此项目作的很不理想,但它却给了我颇多感觉,许多经验教训值得总结。性能

1。总的技术解决方案大方向上选择的不合适,致使后期对新的需求,新功能开发上难度上成倍的增长,导致软件的易用性、容错性、扩展性都很不理想,维护起来也至关麻烦,作到后期,bug满天飞,拆东墙补西墙的感受,真的感受本身掉进了一个泥潭,怎么都爬不出来的感受。虽然此方案不是我能决定的,可是在初期,我却历来没有去主动深刻的思考过此方案的利弊,以及对之后扩展性等各个方面的影响,这方面作的很很差,遇到问题必定要深刻思考,要有本身的想法和思路,不能不加思考的人云亦云,跟上上面走。测试

2.软件核心模块的构架设计,这一块主要是由我负责的,因为没有考虑到之后需求的巨大变动,导致它不能根据需求的变化去很好扩展新的功能。出现这种问题时原本能够经过重构来适当的调整设计以使后面的开发工做更容易进行,但因为怕麻烦,存在一种这是最后的需求了,实现了就能够了的心理,导致愈来愈难重构,愈来愈难进行新功能的开发。大数据

3.核心控件的选择上不够谨慎,为后期的开发带来了巨大的困难。spa

4.需求分析作的不够到位,和PM的沟通作的不够,导致需变更的太频繁。设计

经过对这个项目的总结,下面的经验是值得注意的,放之四海而皆准: 开发

1.遇到问题,不要人云亦云,要有本身独立的想法和思路,不要怕麻烦,怕吃力不讨好。不要认为别人已经提供了方案了,我照着作就行,那个不是个人职责范围,只有经过不断的思考,不断的尝试,才能锻炼本身,不断的进步。文档

2.遇到困难时不能不能总想着逃避,越想躲着它,你会发现它越会找上你,必定要主动的想着去解决困难,这样你会发现后的跟会愈来愈好走,不然的话,后面会困难重重,举步维艰。扩展

3.遇到需求和实现有冲突时,不能先从开发人员的角度去考虑怎么样实现起来简单来要求需求的调整,首先要从用户的角度去考虑怎么样更易用,更友好。固然这一点不是绝对的,要找到一个好的平衡点,把握好度,有时候一些小的需求的变动可能影响很大,这时就要进量找到一个折中的方案去说服用户。重构

4.关于控件、技术选择上要考虑到如下几点:  软件

   1)控件的扩展性,能否知足之后的潜在需求。  

   2)控件有没有很好的技术支持,出了问题有没有团队来修复,一些使用上的问题,有没有相关文档、例子、或者团队能够咨询。  

   3)控件的性能问题,要有压力测试,考虑大数据问题

5.团队的协做性方便,不能听任无论,没有主次之分,这样很容易各作各的,相互推卸责任,没有统一的规范和风格,必定要有一我的去主导,去定制规则,使你们在最优的主线下去最大的发挥主观能动性。

相关文章
相关标签/搜索
本站公众号
   欢迎关注本站公众号,获取更多信息