最近做了近一年的CS项目终于接近完工了，有一种脱离苦海，跳出泥潭的感觉。虽然此项目做的很不理想，但它却给了我颇多感受，许多经验教训值得总结。
1。总的技术解决方案大方向上选择的不合适，导致后期对新的需求，新功能开发上难度上成倍的增加，致使软件的易用性、容错性、扩展性都很不理想，维护起来也相当麻烦，做到后期，bug满天飞，拆东墙补西墙的感觉，真的感觉自己掉进了一个泥潭，怎么都爬不出来的感觉。虽然此方案不是我能决定的，但是在初期，我却从来没有去主动深入的思考过此方案的利弊，以及对以后扩展性等各个方面的影响，这方面做的很不好，遇到问题一定要深入思考，要有自己的想法和思路，不能不加思考的人云亦云，跟上上面走。
2.软件核心模块的构架设计，这一块主要是由我负责的，由于没有考虑到以后需求的巨大变更，致使它不能根据需求的变化去很好扩展新的功能。出现这种问题时本来可以通过重构来适当的调整设计以使后面的开发工作更容易进行，但由于怕麻烦，存在一种这是最后的需求了，实现了就可以了的心理，致使越来越难重构，越来越难进行新功能的开发。
3.核心控件的选择上不够谨慎，为后期的开发带来了巨大的困难。
4.需求分析做的不够到位，和PM的沟通做的不够，致使需变动的太频繁。
通过对这个项目的总结，下面的经验是值得注意的，放之四海而皆准：
1.遇到问题，不要人云亦云，要有自己独立的想法和思路，不要怕麻烦，怕吃力不讨好。不要认为别人已经提供了方案了，我照着做就行，那个不是我的职责范围，只有通过不断的思考，不断的尝试，才能锻炼自己，不断的进步。
2.遇到困难时不能不能总想着逃避，越想躲着它，你会发现它越会找上你，一定要主动的想着去解决困难，这样你会发现后的跟会越来越好走，否则的话，后面会困难重重，举步维艰。
3.遇到需求和实现有冲突时，不能先从开发人员的角度去考虑怎么样实现起来简单来要求需求的调整，首先要从用户的角度去考虑怎么样更易用，更友好。当然这一点不是绝对的，要找到一个好的平衡点，把握好度，有时候一些小的需求的变更可能影响很大，这时就要进量找到一个折中的方案去说服用户。
4.关于控件、技术选择上要考虑到以下几点：
1）控件的扩展性，可否满足以后的潜在需求。
2）控件有没有很好的技术支持，出了问题有没有团队来修复，一些使用上的问题，有没有相关文档、例子、或者团队可以咨询。
3)控件的性能问题，要有压力测试，考虑大数据问题
5.团队的协作性方便，不能放任不管，没有主次之分，这样很容易各做各的，相互推卸责任，没有统一的规范和风格，一定要有一个人去主导，去定制规则，使大家在最优的主线下去最大的发挥主观能动性。
