先简单描述下项目情况。
该系统是基于share point 做的内部系统支撑平台，自己做的 WF 引擎，据说是一帮人做了1年多，然后接下来的好几个系统，都是基于此平台上进行开发。
接手的项目亦是基于此平台，2个已经做完，一个正在开发中。
再说下其他同事对此平台的看法：
1: 交接的同事给我告诉我：“最好不要再研究这个平台了，说不定等你研究透了，它也该换了” 。听完立刻石化.....
2:其他team的同事给我说，你们那个平台运行好慢，搭载在上面的系统运行都很慢.
抱着“风萧萧兮易水寒，.......”的决心,花了2周的时间看相关的代码,趁热打铁，记下当前的心情:
1:开发时缺少沟通交流,代码风格迥异，水平参差不齐，例如：项目用了JQ，但一些JS文件里，有部分是JQ代码，但另外部分又没有用JQ.囧.
2:平台提供的common的东西不够，导致每个系统有不少重复的东西，而且估计大家态度都比较消极，写的东西看这蛮累的.（PS：不排除写代码的人技术很牛B，锅看不懂）
3:用的新技术不少,而且还有些SAP的东东，倒回1-2年，用WCF,EF,postsharep等这些在生产环境中搞，胆子还是蛮大的，还有些这样插件，那样插件的，so.维护成本比较高，这些东西，我都是边学边看.
4:这是个所有接手项目的人都头痛的问题， 此平台系统，无文档，大部分代码无注释，还好搭载在上面的系统都是有文档的，不然我就真的“壮士一去兮不复返"了.
5:还有就是调试相当麻烦，不像常规项目那样直接F5就可以调试了，要想跨页面的调试，需要copy工程，该东西，附加进程...等等...总之，我搞这个调试的环境，都搞了一天多, 曾经因为一个错误搞了1天，错误是因为调用某个WCF出错，最后发现居然是某个工程的dll不是最新的引起的...当时我就抓狂了.....
6:平台用了大量的接口，基类继承，设计模式这些，命名和工程建立也是千奇百怪，看的我眼花，这些真的全部都有必要吗？
.....其他的，想到了在补充...
以下针对以上的问题简要的记录一些解决方法，稍后在继续完善:
1: 这个问题我实在想不到好的办法去控制这个风险，照理说，项目周会每周要做，沟通交流肯定也强调过，但还是有问题，不理解。(不知道各位看官有啥办法不？)
曾经我看到代码某个地方，不明白，想问下当时为啥这样写。于是乎去问同事A，然后同事A让我去问同事B，同事B又让我去问同事C.....算了，锅自己慢慢看..就是多花点时间而已.
定期做code review，应该也算是个办法，不过说实话，这办法感觉挺水，以前公司也搞这个，项目时间一紧，大家都不愿意搞。
2:我认为初期考虑的不够，导致很多冗余，比如:前台的那些信息提示，验证，数据绑定。 最近筹划把mvc的modelbinder拿来强化一下弄成自己的东东.
3:个人对WCF的印象一直不太好，感觉老慢.个人觉得其实很多时候restful的东完全可以代替wcf.
4:代码注释，设计说明.....项目大了，没这些东西，太耗费维护的成本.
5:以后要多适应用 VS自带的那个test工程....
6:这个问题不好说，无法了解他们当时的设计思路，不好评论，反正我看着挺累的，又不好调试，简直是在考验我的思维能力.
总结：此项目让我感觉是被人复杂化了，不知道是想玩玩这些技术的集合，还是展示自己技术的NB，还是其他什么的，总之，对于项目开发，我认为，设计就该是如何简化成本。扩展性，维护性，是和技术含量成反比的。还会带来很多风险。
因为保密的一些关系，无法贴出项目的相关情况，只好在这里边YY边说.
此文目的仅记录心得体会,为日后项目做参考,如遇熟人,请勿对号入座.
