UCHome二次开发规范 - 不同于Manyou的开发模式
2009-08-24 13:05 Otis's Technology Space 阅读(1070) 评论(1) 编辑 收藏 举报本文为转载, 原网址为: http://www.raychou.com/chou/posts/276.htm
注意:此文和UCHome的Manyou开发模式不同,Manyou是利用Discuz的开放平台MYOP开发公共插件,可供所有基于UCHome的网站使用;而此文涉及的开发模式与Manyou不同,是在本地开发,以插件的形式扩展UCHome原有功能。
UCHome是Discuz的一款SNS程序,能让每个网站都用拥有自己的Facebook/校内。Discuz也提供了MYOP开发者平台,所有开发者都可以在此平台上开发自己的应用程序供其他UCHome网站使用,不但可以为自己的网站增加功能,同时也能将自己网站的功能推广到数以万计的UCHome网站中,可谓一举两得。
有时候,开发者并不一定希望使用MYOP开发应用,一是由于产品的需要,并不希望开发出来的应用被其他网站使用;二者MYOP的开发,必须处理联网模式,不能本地开发,较为繁琐。因此,很多有能力的站长会在UCHome的基础之上,以修改UCHome代码的方式增加功能。
但UCHome发展速度很快,经常会有版本更新,往往这个时候,修改了UCHome源码的站长就会面临一个两难的问题:是升级程序?还是为了保留以往的修改,而不升级?在我看来,如果前期做好开发规范,是完全可以避免这个问题的。下面介绍一下我在UCHome Apps开发过程中的一些经验。
想要能够随着官方的程序发布实现平滑的代码升级,无非一点:尽量的少改UCHome原有代码。
少改,但不是不改。一点不改程序的源代码是不可能的。但如何能实现少改呢?我定制了了下面的一些规则:
基本原则
除template目录下的模板文件,其余uchome原有文件尽量不要改动。如需要改动,需汇报项目管理人员记录后才可实施修改。
即使需要对系统原有文件进行修改,尽量不要在文件中增加逻辑代码,也不要修改原有逻辑,使用include的方式来增加逻辑。
例如,需要在系统首页增加growth的表单,设计到两个系统原有文件的修改:
source/space_feed.php
template/space_feed.htm
但请不要直接在这两个文件中增加逻辑代码,对于模板文件,可以使用<!-{template apps/growth/tpl/widget/form.htm}–>的方式加载一个外部文件;同样,针对程序文件,也可以使用include ‘apps/growth/widget/form.php’的方式。
采用这样的方式,即使以后程序文件被覆盖,也不会增加太多工作量。
文件结构
- 以apps.php作为入口文件,所有应用都使用类似apps.php?do=growth&ac=list这样的URL访问应用程序。其中do为应用名称,ac为动作(执行的脚本名)。例如上面的例子,实际是以apps.php为入口,再加载apps/growth/list.php。
- 应用程序统一放在apps目录之下,以应用的名称创建文件夹。例如,成长曲线的名称为growth,则创建apps/growth/目录,所有成长曲线的应用程序都放在此文件夹下。其中tpl文件夹存放模板文件,image文件夹存放图片,可根据应用需求安排apps/growth/内的文件结构。
- growth/doc 目录用于存放当前应用的文档,例如开发文档、api手册、数据库脚本等。
- growth/api.php为growth为外部程序提供的接口。文件内的代码是一个类,命名为AppsGrowthApi,类中方法均为静态方法,方法名采用驼峰格式,例如getGrowthPointByUid,方法名称要足以描述其功能。
- apps/common文件存放一些应用程序公用的文件,例如公用的js库,function库,类库等。
命名规范
程序命名规范
- 文件名一律小写,单词间以下划线分隔
- 类名采用首字母大写的驼峰命名方式
- 类中的方法名采用首字母小写的驼峰方式命名
- 类中的私有方法和私有变量以下划线开头
- 函数名全小写,单词间以下划线分隔
- 变量名同函数名
数据库命名规范
- 数据表以uchome_app_作为前缀,例如uchome_app_growth_point
- 字段名全为小写,以下划线分隔单词
- 建议在建表时注明备注,方便理解字段用处
- 对数据表结构的更改,请在当前应用的doc/sql目录下以日期为单位新建文件,记录更改。