开发规范与注意事项v03.docx
- 文档编号:27792463
- 上传时间:2023-07-05
- 格式:DOCX
- 页数:26
- 大小:32.41KB
开发规范与注意事项v03.docx
《开发规范与注意事项v03.docx》由会员分享,可在线阅读,更多相关《开发规范与注意事项v03.docx(26页珍藏版)》请在冰豆网上搜索。
开发规范与注意事项v03
开发规范与注意事项
日期
主要内容
编写人
版本
2011-03-26
补充开发规范内容
zhangwt
V0.3
目录
1、概述3
2、项目运营与维护3
2.1、服务器安全注意事项3
2.1.1、Web服务器3
2.1.2、数据库服务器3
2.2、事故处理优先级3
2.2.1、事务优先级原则:
3
2.3、工作流程安全4
3、项目开发过程4
4、项目开发前期6
4.1、目录规范6
4.1.1、目录命名规范6
4.1.2、开发框架与模板6
4.1.3、功能模块与角色7
4.2、文件规范7
4.2.1、文件命名7
4.2.2、公用类库7
4.3、数据库规范7
4.3.1、数据库设计7
4.3.2、库表命名8
4.3.3索引与查询优化8
4.3.4、数据库账号8
4.3.4、FTP服务器8
4.4、建立开发环境9
4.5、版本控制9
4.5.1、版本控制目的9
4.5.2、版本控制工具9
4.5.3、版本控制使用原则9
5、项目开发中期10
5.1、变量与函数10
5.1.1、变量命名规范10
5.1.2、函数命名规范10
5.1.3、使用规范10
5.2、排版规范11
5.2.1、排版规范11
5.2.2、代码注释12
5.2.3、代码可读性12
5.2.4、静态化页面12
5.2.5、统一的页面样式12
5.3、开发规范13
5.3.1、优化函数结构13
5.3.2、程序效率13
5.3.3、危险函数的使用13
5.3.4、外部接口调用14
5.4.、页面规范14
5.4.1、HTML规范14
5.4.3、Javascript规范15
5.5、CRM权限16
6、安全与测试17
6.1、数据校验17
6.2、单元测试17
6.3、漏洞攻击与防范18
7、开发后期18
7.1、整体测试与文件整理18
7.2、正式上线前准备18
(这里需要引用目录,目录来源于标题的应用,文档更新后请更新目录)
1、概述
为保证公司网站的正常和安全运行,产品程序的安全、稳健和快速开发。
特制定此开发规范与注意事项。
2、项目运营与维护
为维护正在运行中的项目,必须保持谨慎小心的态度,安全的操作流程。
2.1、服务器安全注意事项
保证服务器安全是每个开发维护人员的职责和义务。
2.1.1、Web服务器
未开发完成的项目和程序不能随意上传到服务器测试;特别是前台服务器;
更新线上文件时,须对原文件做备份;
在线上进行程序调试时,必须查看调试信息时,信息要做隐藏处理(加
--error-->),不能输出账号密码等重要信息。
调试完毕后,及时清理和关闭调试信息;
2.1.2、数据库服务器
避免在业务数据库服务器上进行手工查询,尽量在测试库或从库上操作;
复杂查询在执行前要多次仔细检查;
避免执行耗时较长的SQL语句(多表联立,子查询、无索引字段查询);
2.2、事故处理优先级
2.2.1、事务优先级原则:
在事故发生时,一般事务优先级原则:
先外网,后内网;
先首页,后二级页面;
先主营业务(招聘、广告),后次要服务;
对于网站事故,一般事务优先级原则:
页面信息正确显示;
网站页面显示速度;
对于内网系统,一般事务优先级原则:
Crm系统登录,客户管理系统,合同系统;
其他Crm外围管理系统;
处理时间与事故上报:
五分钟内无法处理完,须通知上级领导及相关人员;
他人协助能提前解决问题的,通知他人协助;
事故发生后,遵照《技术部工作失误积分制及处罚规定》处理。
2.3、工作流程安全
修改和测试线上的项目程序,需要执行规定的安全流程。
1)任何服务器程序的更新,须先通报上级。
2)复制服务器上最新版本的文件到临时测试文件;
3)在测试服务器上测试;
4)无测试服务器时,经许可后使用测试文件测试,测试完毕后及时删除测试文件;
数据库数据导出与更新,需要执行规定的安全流程。
1)任何主数据的更新,须先通报上级;
2)使用测试服务器进行测试;
3)无测试服务器时,经主管同意后,才能使用主数据库;
4)倒库的程序的需在本地数据库测试通过后才可连接待主服务器;
5)数据库更新时间较长(单条语句有超过一分钟)时,需在业务访问量低的时候,才能执行;
3、项目开发过程
软件生命周期(SDLC,SystemsDevelopmentLifeCycle,SDLC)是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。
开发立项与计划
内容包括:
开发项目的具体名称、产品的的属性、功能的详细描述、性能要求的详细描述、稳定性要求的详细描述、开发周期、需要的资源等。
软件需求分析
通过需求分析,逐步细化对软件的要求,描述软件要处理的数据域,并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。
在软件完成后,制定的软件规格说明还要为评价软件质量提供依据。
软件需求分析说明书确认整个系统的物理结构和部署要求、确认各个模块的功能范围和模块间的接口方式。
详细说明系统规模要求和运行环境限制。
明确系统运行所需软硬件资源的要求。
用户界面有初步的设计。
软件概要设计与详细设计
概要设计说明书又可称系统设计说明书,这里所说的系统是指程序系统。
编制的目的是说明对程序系统的设计考虑,包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等,为程序的详细设计提供基础。
用户界面相对需求分析期来说,要有更详细的设计。
详细设计说明书又可称程序设计说明书。
编制目的是说明一个软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,如果一个软件系统比较简单,层次很少,本文件可以不单独编写。
对于内部需求的项目,为加快整体项目开发进度,可以将概要设计说明书和详细设计说明书合并到需求分析说明书里面。
软件编码
软件编码是指把软件设计转换成计算机可以接受的程序。
编写代码过程中要有良好的的编码规范,注意团队合作。
质量控制
在项目的开发过程中,项目经理可组织项目组成员对编制的代码进行相互审核,目的是审核代码是否符合开发编码标准的要求,并在联调前找到代码中的缺陷。
项目测试与联调
按照软件需求分析说明书、软件概要设计说明书和软件详细设计说明书进行测试和联调。
项目交付与验收
在软件测试证明软件达到要求后,软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。
用户验收。
项目维护
项目通常由有开发人员负责维护。
4、项目开发前期
开发前期要求先整体规划目录规范、文件规范、框架使用规范;
4.1、目录规范
目录名及目录结构能影响到整个项目的易管理性和可阅读性。
需要对目录结构和命名制定规范。
4.1.1、目录命名规范
目录命名要求体现该目录的类别(MVC模式划分的目录)、功能(按处理对象划分的目录)和通用命名习惯(系统配置文件);
目录命名尽量使用英文单词;避免使用“admin”,“index”等有二义性单词;
目录的深度尽量不要超过3级。
4.1.2、开发框架与模板
MVC模式
MVC是一种软件设计模式。
MVC是三个单词的缩写,分别为:
模型(Model),视图(View)和控制(Controller)。
MVC模式的目的就是实现Web系统的职能分工。
Model层实现系统中的业务逻辑。
View层用于与用户的交互。
Controller层是Model与View之间沟通的桥梁,它可以分派用户的请求并选择恰当的视图以用于显示,同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
尽管构造MVC应用程序需要一些额外的工作,但是它给我们带来的好处是无庸质疑的。
MVC的优点:
低耦合性、高重用性和可适用性、较低的生命周期成本、快速的部署、快速的部署、可维护性、有利于软件工程化管理。
MVC的缺点:
由于它没有明确的定义。
MVC并不适合小型的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
框架与模板的使用
对大项目应使用简易框架,如crm系统框架。
满足项目的易移植和易管理性;具体要求参考<
对于小项目可以使用fleaphp,满足快速开发和代码易读性;具体要求参考<
对于重要项目,可以根据具体需求使用自定制框架。
满足高效、易扩展,易维护的要求。
对于要求执行效率的单独文件,可以直接以单文件的过程式开发,不采用框架方式;
对于不使用的开发框架的的小项目,可以使用smarty模板。
使用模板可以实现将业务逻辑与视图的分离。
smarty模板的定界符建议使用“<%%>”。
4.1.3、功能模块与角色
要充分理解需求分析、软件设计及页面模型,整理出项目的功能模块。
一个具体的功能模块意味着是一个功能权限。
分析产品的使用用户的角色分类,将功能权限分布到不同的角色上。
程序在进行权限判断时,使用角色包含的功能进行判断,不能直接拿角色名称进行判断。
因为当前用户可能同时含有多个角色,或着多个不同行业的不同角色。
具体权限使用参见CRM权限章节。
4.2、文件规范
4.2.1、文件命名
文件名尽量使用与页面功能相近的单词或缩写词语,避免文件名过长。
文件名全小写,单词间不用分割符。
Index一般用于首页,主引导页,
显示有添加内容的表单页面使用new;
有添加操作(如插入数据库)使用add;
显示有编辑内容的表单页面使用edit;
有编辑更新操作(如更新数据库)使用update;
如果程序中有不同类别的操作可以使用action;
4.2.2、公用类库
在使用类似jquery的外来开源项目时,如果开源项目的升级较频繁时,在文件或目录上标记版本号如jquery_1.3.2.js。
4.3、数据库规范
任何新建的数据库的表结构,经主管上级审核后才能使用。
4.3.1、数据库设计
数据库能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。
遵守第三范式(ThirdNormalForm(3NF))标准。
表类型采用MYISAM型。
尽量把数据列声明为NOTNULL,以提高数据库处理速度。
详细日志类表根据需要记录“谁(user_name)”“在哪(ip)”“什么时间(time)”“做什么事(note)”能内容。
删除操作一般采用修改删除标记的方式。
4.3.2、库表命名
数据库(Database):
格式[db]_[desc]。
表(Table):
格式[tab]_[desc]。
表名长度不能超过30个字符,尽量使用一个单词。
多个单词间不用连接符号,单词首写字母大写。
字段(FieldorColumn):
格式[desc]。
desc:
对字段属性的有意义的描述,可以用英语单词、单词缩写、汉语拼音、字段实际含义的拼音缩写等,单词之间可以用"_"隔开。
4.3.3索引与查询优化
根据查询使用情况,添加合理、有效、必须的索引。
索引应该创建在搜索、排序、归组等操作所涉及的数据列上,同时不要建立过多的索引。
当字段值的变化在10个以内时,避免建立索引。
尽量避免对不同类型的数据列进行比较,例如int与char的比较,甚至char与varchar也是有区别的;
尽量让有索引的数据字段在比较表达是中单独出现,避免对有索引的数据字段作运算或使用函数;
尽量不要在LIKE模式的开头使用通配符;
应该注意避免在查询中让MySQL进行自动类型转换,避免使用MYSQL的类型自动转换,例:
假设field为int型,SELECT*FROMtabWHEREfield=1将比SELECT*FROMtabWHEREfield=‘1’获得更好的性能;因为有些转换过程也会使索引变得不起作用;
定时敦促数据库管理员整理MYISAM型数据库的碎片;
必须严格执行数据库操作语句中的转意操作,即可特殊字符的转换;
多使用EXPLAIN分析语句,对查询量较大的语句,多写几种方案,并多运行几次,找出最合适你的语句;
4.3.4、数据库账号
程序用数据库账号统一格式:
***_PM,***为数据名称;
个人的数据库账号不允许在线上程序中使用,仅限个人的数据库管理软件使用;
禁止随意将自己的账号和密码转给他人使用;
4.3.4、FTP服务器
为方便进行线上测试,给开发人员开通FTP账号。
每个账号为个人专用,禁止随意转给他人使用;
如需知道服务器上其他文件目录结构,请向程序主管查询。
4.4、建立开发环境
应建立与最终产品使用环境一致的开发环境。
基本环境要求:
apache2.0及以上;
php5.3及以上;
mysql5.0及以上;
使用安全性较高的环境配置;
其他要求:
jquery1.3.2及以上;
4.5、版本控制
4.5.1、版本控制目的
1)保证版本的连续和可跟踪(实现程序各版本的回退)
2)指导研发团队,合理安排研发(修复)计划,控制版本的升级
3)指导实施团队,选择合适版本,进行正确的项目实施
4)衔接研发和测试,适时控制版本的发布
5)避免程序代码混乱,修复过的bug被覆盖;
6)记录版本发布信息,版本之间界限清晰;
7)能够规范用户方版本的升级;
8)各个团队能够实现并行开发,划分不同分支。
4.5.2、版本控制工具
版本控制工具很多,为方便团队的开发和规范,统一使用Subversion(SVN),客户端使用TortoiseSVN。
安装使用参见《TortoiseSVN使用手册》。
SubversionFAQ(常见问题解答)http:
//subversion.apache.org/faq.zh.html
4.5.3、版本控制使用原则
项目刚开始阶段,单独开发;项目稳定阶段,完整开发。
项目开发初期,各个项目成员负责自己的文件夹(或者模块),与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹(或者模块),他人的文件夹(或者模块)可以不必关心;
项目稳定阶段,也就是每天的变更量很小了,所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹(或者模块),各个项目成员在其本地编译时本地工作区的全部项目程序(或者资料)均为最新的版本,保证项目作为整体能够顺利运行。
尽量保证一份文件只有一个项目成员在编辑。
举例说明:
程序员A负责底层中文件DBAccess.cs的编写,如果程序员B的工作要求他为DBAccess.cs增加两个方法,程序员B应该通知程序员A来增加而不是自己增加;如果此时A非常繁忙需要B自己增加,就需要B先更新本地的DBAccess.cs,然后开始修改,修改完成后立即提交并通知A更新本地的文件,通过缩短提交间隔来减少冲突。
新版本文件上传使用原则:
1)上传的文件都是原创的(不能包含公用文件),都是源文件(不能包含任何中间文件)。
2)上传的文件在任何一个人的PC上都能直接正确运行,不需要做任何修改。
3)本地的文件随时可以被破坏掉,随时可以通过上传的文件恢复因本地文件损坏而中断的工作。
4)在版本控制服务器上只有唯一的一组源文件,用于编译、仿真、发布。
5)用tag号而不是版本号进行所有源文件的检出。
5、项目开发中期
正式进入项目开发阶段,按照功能模块逐步开发。
开发过程中,及时编写已完成部分的可发技术文档,以方便配合测试工作;
开发过程中,有任何问题都要及时反馈。
产品设计有任何不明确的都要询问产品设计人员和程序主管。
不能想当然,不能完全相信产品的设计,因为不同的人对产品的需求和目标理解是不全一样的。
有怀疑才能完善,有怀疑才有超越,才能保证最终完成的项目是客户最终需要的项目。
5.1、变量与函数
5.1.1、变量命名规范
1)尽量使用英文单词,而非拼音命名;
2)使用的单词和词组要求能表达要代表内容的意义,避免仅使用通用词语。
如admin,manage等通用词,不能表达要管理的内容,应避免使用。
3)变量使用前要求先声明和赋值。
4)统一使用下划线法命名。
5.1.2、函数命名规范
1)尽量使用英文单词,使用的单词和词组要求能表达要实现的功能。
建议只使用2-3个单词。
2)统一使用骆驼式命名法。
3)采用动词加名词的形式,动词小写,后面的名词用大小写间隔。
5.1.3、使用规范
命名空间
各种语言使用的一种代码组织的形式。
通过名称空间来分类,区别不同的代码功能。
同时也是所有类的完全名称的一部分。
通过名称空间方式可以避免不同类和数组等数据结构之间的变量名和函数名的命名冲突,规避潜在的危险。
相关联的变量尽量保存到同一数组内;
相关联的函数尽量封装到同一类内;
Php配置设置中register_globals要求设置为Off。
不要对不能信任的数据(如客户端提交的GET和POST数据)使用extract(),变量释放出来可能会覆盖系统或其他重量变量,从而导致漏洞攻击。
变量使用与传递
变量使用前要求先声明。
避免在函数中使用global关键词,减少和避免直接使用全局变量,需要的变量以参数的方式传递。
如函数需要的参数很多,可以将相关的多个变量参数封装成一个数组参数的方式传递给函数。
以后可以在不改变函数声明的情况下,对函数参数进行后续扩展。
如:
Functionsearch($condition1,$condition2,$condition3,$condition4)
可改为:
$arraycondition=array('condition1'=>$condition1,'condition2'=>$condition2,
'condition3'=>$condition3,'condition4'=>$condition4);
Functionsearch($arraycondition)
常量根据常量的使用范围,分别在全局或类中定义与应用。
5.2、排版规范
程序代码排版要求易阅读性、易调试。
每个程序文件应由标题、内容和附加说明三部分组成。
5.2.1、排版规范
缩进:
缩进以Tab为单位,一个Tab为四个空格大小。
全局数据、函数原型、标题、附加说明、函数说明、标号等均顶格书写。
空格:
数据和函数在其类型,修饰(如__fastcall等)名称之间适当空格并据情况对齐。
关键字原则上空一格,不论是否有括号,对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。
对齐:
原则上关系密切的行应对齐,对齐包括类型、修饰、名称、参数等各部分对齐。
另每一行的长度不应超过屏幕太多,必要时适当换行。
空行:
程序文件结构各部分之间空两行,若不必要也可只空一行,各函数实现之间一般空两行。
Php程序文件中,使用
php?
>完整标签;
5.2.2、代码注释
对注释有以下三点要求:
1)必须是有意义;
2)必须正确的描述了程序;
3)必须是最新的。
注释必不可少,但也不应过多,以下是必要的注释:
1)标题、附加说明(如文件头或重要逻辑处);
2)函数说明:
对几乎每个函数都应有适当的说明,通常加在函数实现之前,在没有函数实现部分的情况下则加在函数原型前,其内容主要是函数的功能、目的、算法等说明,参数说明、返回值说明等,必要时还要有一些如特别的软硬件要求等说明;
3)在代码不明晰或不可移植处应有少量说明;
4)程序修改时的注释内容包括:
修改时间、修改原因、修改人。
4)及少量的其它注释。
注释内容格式参考PHPDocument的格式要求;
PHPDocumentor是一个用PHP写的PEAR工具,对于有规范注释的php程序,它能够快速生成具有相互参照,索引等功能的API文档。
从1.3.0开始,新的版本加上了对php5语法的支持,同时,可以通过在客户端浏览器上操作生成文档,文档可以转换为PDF,HTML,CHM几种形式,非常的方便。
参考文档:
5.2.3、代码可读性
1)注意运算符的优先级,并用括号明确表明表达式的操作顺序,避免使用默认优先级;
2)源代码中关系较密切的代码应尽可能相邻;
3)不要一味的追求紧凑的代码。
紧凑的代码并不代表高效的机器码;
4)不要使用难懂的技巧性很高的语句,程序的效率关键在于算法;
5)一个函数只在一个抽象层下作一件事情;
6)不要设计多用途面面俱到的函数;
7)尽量使用显式的数据类型转换(让人们知道发生了什么事),避免让编译器轻悄悄地进行隐式的数据类型转换。
5.2.4、静态化页面
静态化的页面(make系统生成的)的登录栏状态,尽量使用页面加载完成事件触发ajax请求来更新登录栏状态内容;
5.2.5、统一的页面样式
前台程序页面使用行业统一定制的页面头部和底部文件。
后台页面使用与crm系统相一致的样式文件。
5.3、开发规范
5.3.1、优化函数结构
改进模块中函数的结构,降低函数间的耦合度,并提高函数的独立性以及代码可阅读性、效率和可维护性。
优化函数结构时,要遵守以下原则:
1)不能影响模块功能的实现;
2)仔细考查模块或函数出错处理及模块的性能;
3)通过分解货函数合并来改进软件结构;
4)考查函数的规模,过大的要进行分解;
5)功能不明确较小的函数,特别是仅有一个上级函数调用它时,应考虑把它合并到上级函数中,而不必单独存在;
6)降低函数间接口的复杂度;
7)不同层次的函数调用要有合理的扇入、扇出(扇入是指有多少个上级函数调用它。
扇出是指一个函数直接调用其他函数的数量);
8)函数的功能是可预测的,只要输入的数据相同就会产生同样的输出;
9)提高函数内聚(内聚是一个模块内部各成分之间相关联程度的度量,单一功能的函数内聚最高)。
5.3.2、程序效率
代码效率分为全局效率、局部效率、时间效率和空间效率。
1)在保证软件系统的正确性、稳定性可读性及可测试性的前提下,提高代码效率。
也不应花过多的时间拼命地提高调用不频繁的函数代码效率;
2)以提高程序的全局效率为主,提高局部效率为辅;
3)在优化程序的效率时,应当先找出限制效率的“瓶颈”,不要在无关紧要之处优化;
4)不要追求紧凑的代码,因为紧凑的代码并不能产生高效的机器码;
5)尽量减少循环嵌套层次。
在多重循环中,应将最忙的循环放到最内层,减少切入循环层的次数;
6)与循环变量无关的判断语句移到循环体外,应使循环体内工作量最小化;
7)将重复的浮点除法运算用乘法代替;
5.3.3、危险函数的使用
避免使用可以破坏服务器文件系统和泄露账号信息的函数。
具有危险的系统函数列表:
phpinfo(),error_log(),
passthru(),exec(),system(),shell_exec(),pcntl_exec(),dl(),escapeshellcmd(),
proc_open(),proc_get_status(),popen(),pu
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 开发 规范 注意事项 v03