您的位置:首页 > 编程语言

在真实项目中使用第三方或开源代的代码,组件,中间件,框架的基本规则

2008-09-20 19:56 796 查看
近日老板来找我,让我帮他写一个关于,使用“在真实项目中使用第三方控件,框架的规则”文档

我问题为啥,大大致是这么说的“公司现在各个项目组使用了大量的第三方‘框架’,有的很老都找不到维护,有的很新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 所提到的那些,还要了解函数方法类的内部处理流程(而不是每行代码都是干啥的、这样可以保证使用者是有能力,修改扩充的,如果有必要要整理,代码流程性文档)、而且一定要亲手做做实例,不能空想;
 

四、对于成品第三方组件,中间件,框架的

必须保证,此为大牌厂商,或应用比较广泛的

补充

在项目时间很充裕的情况下,本条例经审查可宽松对待;

我写这些东西,留给以后有这类需求的人,大家也请帮忙提点意见,加点减点改点什么的,我都是比较欢迎的;

抨击我个人可以,不要抨击我们公司的管理制度(一点用都没有)

放首页了可能不太适合,不过这都是开发人员可能遇到的问题,也属于项目管理类吧,应该可以放在首页的 站长大人开恩吧;
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: