二次开发模式讨论
sap r/3实施过程中有很多要修改sap标准功能的需求，这时就用到了系统修正系统修正有五个层次：定制、个性化、修改、增强和客户化开发
定制是针对公司业务的，由业务顾问来做，主要是根据客户的特点设置系统参数。sap产品设计过程中考虑了40多个行业的特点，所以配置参数非常多，可能有上万项，而且相互关联，一组参数实现一个个性化流程。sap还针对各个行业开发了叫做“最佳业务实践”的预配置参数包，其实就是行业老大咋做咱咋做，对快速实施很有帮助。恩信每个模块的设置功能类似这个。
个性化是针对特定用户的，由业务顾问或系统管理员来做，设置权限啦，个性化的菜单啦，日期、数字等显示格式啦。还可以用字段状态变式等技术手段把某个人不用的字段隐藏起来或者设置为必输，这样同一个界面展示在不同人的面前就不一样了。无非是为了简化操作。恩信的权限分配功能让用户只能看到有权限的菜单项，用xml来做输入有效性检查，也是类似的功能。
下面就涉及二次开发的部分了。写代码之前得说明一个事儿，为了区别sap的代码和非sap的代码，sap定义了程序名的 name space，所有 y z 开头的程序是非 sap的代码。写代码要先申请access key，两个级别，改sap代码的access key 和 写非sap代码的access key。这样，无论项目上线系统代码作了多少修改，很容易区分哪些代码是sap写的，哪些是咨询公司写的。特别是，出现bug的时候...
修改是指直接修改sap标准程序。这是sap公司极力反对的。因为标准程序改了，升级以后被新版本覆盖了，还得再改一次。再就是sap公司不能保证实施公司代码的功能符合软件的全局设计。但是客户是上帝，如果客户坚持非要修改，实施公司和客户共同向sap申请一个access key，也是可以改的。经验证明，每个公司这种修改都是恶梦的开始。有个例外，就是你发现了sap一个bug，等不到出patch或升级，这种修改就是必要的了。
增强很巧妙，sap根据经验知道在某些流程中的某个时间点用户需求很难确定，一家一个样，那索性就在这里留个口子，代码由实施公司在项目上写，爱写啥写啥，只要输入输出定义好了。有两种实现方式：
1、用户出口
调用一个函数，函数里只包含一个source，没其他代码，这个source程序名是z开头的。是的，以写非sap代码的access key就可以在这个source里加code。当然能访问的变量都在函数接口里定义好了。
2、badi
调用一个接口的方法（是的，就是面向对象）。项目实施公司新建一个此接口的实现类就好了。当然这个实现类也得y或z开头啦。
增强很牛，系统升级也不会丢。国内的软件没看见过这么弄的。恩信应该借鉴，java是oo的语言，jsp支持include语句。面向接口编程，可以这么用。
客户化开发就最简单了，可以新建一个y或z开头的程序，也可以建新数据库表（y或z开头）。想要什么功能自己设计开发，sap就管不着了。升级的时候copy过去就行了。我在恩信的目录里看到了extend目录，应该就是干这个的吧。
说了一大堆，都是原创。不同意可以拍砖，不懂可以问。大家研究，贡献经验，才能发展。 此帖是我2006年研究恩信的时候提的建议，没有被采纳。可能恩信的合作伙伴们更倾向ajax下代码级的修改。准备有机会在webERP的二次开发中应用这些模式。虽然在产品架构和主要功能上还要遵循主项目的惯例，相信我们有能人把这块做得更好
关于php源文件和函数的命名规范
在对开源软件进行二次开发的时候，我们还要考虑到升级的问题。那就要求我们在命名源文件和函数名的时候遵循特定的规则。因为我们的二次开发分为三个层次，所以我建议针对此三个层次的修改建立如下规范：
1、修正系统BUG - 针对标准系统。比如我们修正了在线翻译工具。对于这种修改，我们会在论坛上发布系统补丁并将修改结果提交给weberp项目。这样的修改我们只需修改源文件就可以了。但代码注释要说明修复了哪个bug。
2、增强系统标准功能 - 针对标准系统。比如我们开发一个中国的资产负债表。对于这种修改，建议在程序源文件命名时遵循 系统标准功能 加 _CN的规范，如balancesheet_CN.php。并在原页面基础上改写。这样即使做了系统升级，我们只要把我们的_CN后缀名的文件重新copy进新版本的目录即可。这部分我们不会提交给weberp项目。
3、客户化开发 - 针对特定客户系统。比如给客户开发了一个特殊的功能。对于这种修改，建议在程序源文件命名时遵循 功能描述 加 _CN 加 _公司 的方式。这样即使做了系统升级，我们只要把客户 CN_公司 后缀名的文件重新copy进新版本即可。这部分不在weberp项目和本地化项目的工作范畴内，属于二次开发者和最终用户的项目行为。 至于如何让标准功能和二次开发的功能协作，这个我正在构思和测试中。
初步设想是在header.inc里加页面跳转。如页面是 test.php 则跳到 test_CN.php。
如果可以的话，这些跳转的语句最好维护在一个单独的cn.inc文件里，这样就很容易看出当前的系统对标准功能做了哪些修改。 遵循这些规范虽然看起来麻烦，但是对项目今后的运作有长远意义。
比如，我们可以清晰地界定weberp项目的bug和我们本地化项目的bug；可以从地址栏看出这个页面是不是该公司特有的功能（非标准功能）。 很有参考价值，多谢。 翻译成英文交到作者那里去 算我一个
页:
[1]