UCHome二次开发规范 - 不同于Manyou的开发模式

本文为转载， 原网址为： 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}�C>的方式加载一个外部文件；同样，针对程序文件，也可以使用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目录下以日期为单位新建文件，记录更改。