PHP开发规范

PHP开发规范
yan 2013-02-19

一、基本规范

1.      编辑器统一使用以下编码工具vim、EditPlus或NetBeans,制表符长度统一为4。

2.      所有非view的.php文件,去掉结尾部分的“?>”符号。

3.      所有文件格式统一为UTF-8(NO BOM)。

4.      所有的class基类、common公共文件,修改一定要谨慎,增加配置时需要进行确认。

5.      svn版本库提交时,请先diff一下确认提交的内容为自已所有,避免提交冲突文件或冲掉别人代码的情况。

6.      同一个业务动作,只允许有一处代码,不允许复制粘贴产生冗余代码。

7.      单个model可以实现的功能,封装在对应model里;几个model配合才能完成的一个业务动作,封装到业务service里。

8.      不允许在php或js中拼接大段html代码,为html片段建立element,以便于前端和样式调整结构与样式。

9.      view大片代码foreach或if时,必须使用{}扩起来,不允许使用:endif的形式。

10.  所有ajax的php端都放到业务对应的ajaxcontroll里实现。增/删/改类型的请求统一使用post方式,其它使用get方式。

11.  view页第一行标注此页说明;函数头部标注函数实现的功能。

12.  js绑定单独在js里写bind,不要写到html标签里。

13.  view中除js变量赋值以外,尽量避免包含js代码。

14.  Service与调用者完全解耦。Service中提供的public业务逻辑接口统一使用驼峰命名法命名,命名要简洁易懂。业务逻辑统一增加注释,对实现功能进行说明。不对外开放的方法设置为private。

15.  所有驼峰命名的Model,设置db的表名时统一以下划线分割单词。比如Model为ClubTopics,则表名对应为club_topics。

16.  view文件名统一使用小写单词“_”分隔

17.  ajax表单提交统一返回格式:

成功时:

‘result’=>1,’message’=>”保存成功”,’其它值’=>xx

失败时:

‘result’=>0,’message’=>”失败原因”

未登录时:

‘result’=>-1,’message’=>’请先登录’

18.  service函数返回格式建议

执行业务操作的函数,建议返回格式为 array(‘result’=>0,’message’=>”)

执行检索组织批量数据的函数,建议返回格式为 array(‘result’=>0,’message’=>”,’data’=>array())

19.  文件上写上创建时间,函数写上版本号和人。目的是能在其它人调用、扩展、重构时方便的知道找谁。

/**

* 获得话题列表

* @version 2.7

* @author author@mail.com

* @param int $club_id           达人会ID

* @param int $p                      页数

* @param int $limit                每页显示记录数

* @return arrayarray(‘cnt’=>$count,’res’=>$topics)

*/

public functiongetTopicsList($club_id,$p=1,$limit=20){

20.  Service不应向外部调用者抛出异常,异常需要在内部捕获。有唯一约束的Model在insert时应try catch。

21.  命令行task任务在开始和结束时应打印出任务名和起止时间,以便在shell批量执行任务时能知道当前执行到哪个任务及任务的执行时间。

22.  view上的图片根据页面要求使用对应尺寸,非特殊情况不应使用大图缩放。

23.  全站所有的截字,统一使用mb_substr_ext($str,$len, $ellipsis)函数。参数$str为源字符串;$len要截的长度(一个中文长度为2);$ellipsis截字后缀内容,比如‘…’。

二、安全

1.      所有文本往数据库保存前都用html_encode转义一下。

2.      ajax不能被利用修改无权限的数据,重要表单需要做严格校验。

3.      url中的参数接收后应作格式检验,避免跨站脚本攻击漏洞。

三、性能

1.      不允许在循环中执行sql查询,在外部一次查出来。

2.        能用controll和action实现的,不要用路由。

4.      model内的find函数直接返回对象或对象数组,非必要时不要model内部循环转成array。

5.      非实时性强的部分都加上memcache,统一维护到cache_list文件里。注明:用处、key、过期时间、什么情况下清cache。

6.      查询逻辑比较复杂(比如设计到统计的)、实时性要求不是很强时,使用定时任务跑统计数据,程序直接查询跑好的数据,确保查询的效率。

7.      大数据量数据分批处理时,使用mongoid(>或<)加上limit的方式来分段,避免使用offset。offset在后半断时速度极慢且游标会报错。

8.      发布脚本、定时任务必须注意性能。执行时间在半小时以上的任务必须进行优化。

四、进度

1.        开发任务进度=100%是指:功能编码完毕、单元测试完毕、对照产品设计细节仔细核对完毕。

2.        每天下班前必须更新工作进度 ,工作中遇到问题一定要及时沟通。

五、CheckList

1.        每个迭代周期交付测试前每个开发人员必须进行以下CheckList检查。

2.        开发的新功能可以正常工作,可以流畅完成完整流程。

3.        对照wiki上的产品设计一行一行核对所有需求细节,确保wiki上要求的所有功能细节全部实现,且与wiki完全一致(包括JS效果)。

4.        打开开发模式、监控错误日志,确保程序没有任何warning或error。

5.        安全检查。所有POST表单安全性检查,确保后端表单校验正常、权限控制校验正常,没有安全漏洞。检查url是否存在跨站脚本攻击漏洞。

6.        性能检查。检查页面打开速度、表单执行速度。耗时200ms以上需核查原因并优化。

7.        检查未登录时,相关功能工作是否正常。

8.        同时打开多个TAB页,对有状态变化的功能进行交叉测试。

9.        对功能的所有细节进行像素级的检查。

10.    对其它人开发的功能进行CheckList互测。

六、其它

1.      避免开完完毕的功能出现需求变更的方法

1)在做之前觉得哪不对劲的或wiki上没写的,一定要跟产品确认一下并让维护到wiki上。如果感觉不合理,就公开提出来讨论。

2)已经按照确认完成的功能,除非调起来非常容易,否则没有特殊情况,一概不予处理,如果产品坚持要改,走需求变更流程。

发表评论

邮箱地址不会被公开。