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）已经按照确认完成的功能，除非调起来非常容易，否则没有特殊情况，一概不予处理，如果产品坚持要改，走需求变更流程。
