在真实项目中使用第三方或开源代的代码，组件，中间件，框架的基本规则
近日老板来找我，让我帮他写一个关于，使用“在真实项目中使用第三方控件，框架的规则”文档
我问题为啥，大大致是这么说的“公司现在各个项目组使用了大量的第三方‘框架’，有的很老都找不到维护，有的很新bug太多，有的太复杂新手不会用，有得项目经理找个很好看的给老板看他也让人家用了，后来才发现使用这个框架做一个界面，要不原来多出3倍的时间党务了项目、还有一些开源的代码太多没人维护的起，诸如这些的一大堆，反正就是党务进度了”太多了我记不住了反正就是要我给他出一个文档，我是不爱出这个文档的，我个人其实喜欢研究一些先进就是和第三方框架的（但我用的很少），而且这些问题有些时候“并不是程序员单方面造成”我就不多解释了大家都是搞开发的都明白，的其中问题不是一句两句能说清楚的，让我出这个东西我本身就不太乐意
但是理论的半天，没说过老板，我能说过他我就可以做老板了，认了吧 哎....；
解释一下：老板所谓的“框架” 可能是一段 js 代码，一个 C# 类库，或者几个界面库，还有可能是一些开源的各种控件，组件什么的，和 Framework 一点毛关系都没有。当然也包括nh这类“ORM框架”类的他都叫框架，哎没办法可能是这个“框架”一词很大气很好听很好记反正我们公司已经用烂了，
我一研发组的，找我写这东西真有点不适合，不过没办法硬着头皮写吧（随让我该下班不走，还在那里上网来者呵呵）
内容如下：
以下下内容【】内是可变的；
一、总体原则
简单实用、易学、易用、易改（口号只是口号）
二、基本规则
- 项目很紧的情况下，如果不能提高开发效率的能不用就不用；
比如项目就几个月，而你却没用过的，如果可以满足客户需求，基本就不要用了 - 必须是，常用的容易找到资料的，并相对容易学习；
包括社区、API帮助、演示例子等等； - 必须是有后续支持的、运行稳定、后续版本及时
举例如果是那种 .net 都出到 4.0 了而它还必须用 .net1.1 的是绝对不可选的 - 学习时间总计，不得超过【一】个月（根据项目情况，有加有减）；
学习成本过大，一定是不能选的,比如：在项目开发期间如果频繁出现因为此引起的技术问题 - 不得因此造成开发成本过高不得超过【1.5】倍
如：你原来用 ASP.net 做一个同样的页面用 1 天，现在却需要 3 天就不好了，如果是1天办还是可以接受的 - 项目上线后因此所引起的bug不得超过 【20%】；
如：如果因为xx第三方控件引起，bug 率过高，这多半是由于使用者学习的不透引起的 - 必须保证项目内或公司内有2人以上比较精通、使用熟练度 【90%】 以上；
为了公司的发展，必须保证这点，否则如果人走了或生病了误事，起码对其了解程度在70%以上，包括属性，类，方法函数，程序流程，特性，常见问题（你用到的，没用到的不算）比如你用一个控件90%以上的属性和函数都要了解，并做过尝试； - 如果不是必须使用的，第一两个版本的不要用，测试的更不能用(除非冻结了API)（无视网络上的评价，现在枪手打手太多）
- 在设计文档上一定要明确指出那里用了、用的什么
三、对于开源的项目
- 必须保证公司内的人有实力维护（可以扩充，修改）本开源代码段或框架的人数，在【2】人以上，基本保证对类库或控件，项目文件的理解在【90%】 以上 （使用的部分，没关联到的不算）；
如使用第3方的开源 GRID 包括 2.7 所提到的那些，还要了解函数方法类的内部处理流程（而不是每行代码都是干啥的、这样可以保证使用者是有能力，修改扩充的，如果有必要要整理，代码流程性文档）、而且一定要亲手做做实例，不能空想；
四、对于成品第三方组件，中间件，框架的
- 必须保证，此为大牌厂商，或应用比较广泛的
补充
在项目时间很充裕的情况下，本条例经审查可宽松对待；
我写这些东西，留给以后有这类需求的人，大家也请帮忙提点意见，加点减点改点什么的，我都是比较欢迎的；
抨击我个人可以，不要抨击我们公司的管理制度（一点用都没有）
放首页了可能不太适合，不过这都是开发人员可能遇到的问题，也属于项目管理类吧，应该可以放在首页的 站长大人开恩吧；
