好文档就是一把金锄头!
欢迎来到金锄头文库![会员中心]
电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本

数据中心产品开发规范.doc

40页
  • 卖家[上传人]:今***
  • 文档编号:105741089
  • 上传时间:2019-10-13
  • 文档格式:DOC
  • 文档大小:276.50KB
  • / 40 举报 版权申诉 马上下载
  • 文本预览
  • 下载提示
  • 常见问题
    • 数据中心产品开发规范XXXX公司XX业务部XXXX年XX月 开发规范(JAVA部分) 文档说明本文档所涉及到的文字、图表等,仅限于内部使用,未经双方书面许可,请勿扩散到第三方文档属性属性内容客户名称:项目名称:文档主题:文档编号:文档版本:版本日期:文档状态:作者:文档变更版本修订日期修订人描述文档送呈单位姓名目的审阅参阅目 录1 概述 51.1 最根本原则 52 Java技术规范 62.1 平台使用的相关技术 62.1.1 基本核心框架包 62.1.2 其他框架包 62.2 程序设计标准 72.2.1 命名约定 82.2.2 包名,类名,方法名,属性名,常量名命名约定 92.2.3 注释约定 102.2.4 快速浏览JavaDoc 112.3 开发规范 122.3.1 项目结构说明 122.3.2 整体包结构说 122.3.3 项目模块包结构及命名 132.3.4 各子项目模块功能包结构 142.3.5 配置文件包结构 142.4 命名规则 152.4.1 共用类 152.4.2 业务层 152.4.3 展现层 152.4.4 模型层 162.4.5 持久层 162.4.6 XML配置 162.4.7 资源文件 192.4.8 JSP文件 202.4.9 事务命名约束 202.4.10 JS命名约束 213 数据库技术规范 223.1 概述 223.2 命名基本规则 223.3 数据库表空间 223.3.1 命名基本规则 223.4 默认用户方案 223.5 表的命名规则、约定 223.6 视图的命名规则、约定 233.7 字段命名规则、约定 233.8 存储过程的命名规则、约定 233.9 序列对象的命名规则、约定 243.10 触发器命名规则、约定 244 HIVE技术规范 255 HBase设计规范 265.1 Namespace命名空间设计 265.2 1.2. Table表设计 275.2.1 理想HBase表 275.2.2 预创建分区 285.2.3 列族数量 285.2.4 可配置的数据块大小 295.2.5 数据块缓存 295.2.6 激进缓存 295.2.7 布隆过滤器(Bloom filters) 305.2.8 生存时间(TTL) 315.2.9 数据压缩 325.2.10 数据分割 335.2.11 单元时间版本 345.3 ColumnFamily列族设计 355.4 Qualifier列设计 365.5 版本设计 375.6 HBase命名规范 371 概述本文提供一整套编写高效可靠的Java代码的标准、约定和指南。

      它们以安全可靠的软件工程原则为基础,使代码易于理解、维护和增强而且,通过遵循这些程序设计标准,你作为一个Java软件开发者的生产效率会有显著提高经验证明,若从一开始就花时间编写高质量的代码,则在软件开发阶段,对代码的修改要容易很多最后,遵循一套通用的程序设计标准将带来更大的一致性,使软件开发团队的效率明显提高1.1 最根本原则r 运用常识当找不到任何规则或指导方针,当规则明显不能适用,当所有的方法都失效的时侯: 运用常识并核实这些基本原则这条规则比其它所有规则都重要r 驼峰命名法驼峰命名法(Camel-Case):就是当变量名或函式名是由一个或多个单字连结在一起,而构成的唯一识别字时,第一个单字以小写字母开始;第二个单字的首字母大写或每一个单字的首字母都采用大写字母,例如:myFirstName、myLastName,这样的变量名看上去就像骆驼峰一样此起彼伏,故得名驼峰命名法的命名规则可视为一种惯例,并无绝对与强制,目的是增加识别和可读性2 Java技术规范2.1 平台使用的相关技术平台使用的框架包分核心框架包和其他必须的框架包,各框架包本身所依赖的开源包不做列举,由框架包本身的信息来定。

      2.1.1 基本核心框架包平台采用Spring+Struts2+myBatis的三层架构作为基本框架JDK1.6+)参考如下:名称版本备注Struts22.2.1Spring3.0.5mybatis-core3.1.1不支持跨数据库建议,目前开发在mysql上,现网环境在db2上mybatis-spring1.1.1MySQL5.0Tomcat7.0jQuery1.82.1.2 其他框架包除基本框架外,平台其他将采用的一些框架包,参考如下:(JDK1.5+)名称版本备注Spring Security2.0.4Apache Commons2.6常用的工具包等SLF4J1.6.1Apache Logging log4j1.2.15Apache Ant1.7.1Oscache2.4.1XMemcache1.2.5C3P00.9.1Dom4j2.0commons-beanutils1.8.3Mybatis-spring1.1.1Hadoop-core0.20.2-cdh3u5Hive-cli0.7.1-cdh3u5Hbase0.90.6-cdh3u52.2 程序设计标准Java的程序设计标准很重要,原因在于它将提高开发团队各成员的代码的一致性。

      一致性的提高会使代码更易理解,这意味着它更易开发和维护从而降低了应用程序的总开发成本你必须牢记的是:你的Java代码在你已离开并开始另一个项目之后,会保留相当长的一段时间因此开发过程中一个很重要的目标就是要确保在开发成员或开发团队之间的工作可以顺利交接,不必花很大的力气便能理解已编写的代码,以便继续维护和改进以前的工作如果代码难以理解,很有可能被废弃和重写s2.2.1 命名约定我们将在整个标准中讨论命名约定,以下是几个基本点:r 使用可以准确说明变量/字段/类的完整的英文描述符例如,采用类似firstName,grandTotal 或 CorporateCustomer这样的名字虽然象x1,y1或fn 这样的名字很简短,输入起来容易,但是我们难以知道它们代表什么、结果是什么含义,因而使代码难以理解、维护和改进r 采用该领域的术语如果用户称他们的“客户” (clients) 为“顾客” (customers),那么就采用术语Customer 来命名这个类,而不用 Client许多程序开发者会犯的一个错误是,不去使用工业或领域里已经存在着很完美的术语时,却生造出一些普通词汇r 采用大小写混合,提高名字的可读性一般应该采用小写字母,但是类和接口的名字的首字母,以及任何中间单词的首字母应该大写。

      r 尽量少用缩写,但如果一定要使用,就要谨慎地使用这意味着应该保留一个标准缩写的列表,明智地从中选取,并且在使用时保持一致例如,想对单词“number”采用缩写,那么可从 nbr,no 或者 num 中选取一个,说明一下采用了哪一个(具体是哪个倒无所谓),并且只使用这一种形式r 避免使用长名称(不超过15 个字母)例如: PhysicalOrVirtualProductOrService 看起来似乎是个不错的类名,但是名字太长,应该考虑重新给它起个短一点的名字,比如象 Offering r 避免使用相似或者仅在大小写上有区别的名字例如,不应同时使用变量名 persistentObject和persistentObjects及anSqlDatabase和 anSQLDatabase这样的名称r 避免使用下划线作为名字的首末字母以下划线为首末字母的名字通常为系统保留,除预处理定义之外,一般不用作用户命名更重要的是,下划线经常造成麻烦而且难输入,所以尽量避免使用2.2.2 包名,类名,方法名,属性名,常量名命名约定r 包命名包命名全部使用小写英文字母,中间不允许有数字下划线等特殊字符r 类,接口命名类,接口名开头使用大写英文字母,多单词使用驼峰命名法。

      类名中不要使用下划线和数字等特殊字符,正确的写法示例:HibernateDaoSupport如果表示特殊功能的类,在类名的末尾加上所要表示的功能英文名称,如:****Listener,表示监听器等r 方法命名方法命名使用驼峰命名法,方法名中间不要使用下划线和数字等特殊字符,正确的示例:processing()方法的参数以及方法内部的局部参数可自定,符合要求就行r 特殊Bean类的属性命名约定Bean的属性命名规则严格使用驼峰命名法,不允许使用下划线,名字长度最长不要超过15个字符,确实需要长名字时,适当缩写部分英文字母r 常量属性命名常量的命名规则一般为常量名全部采用大写字母,多单词之间使用下划线隔开,不允许使用数字等特殊字符,并且常量的声明一定要是static final的r 普通类的属性命名普通类的属性命名除常量依照常量命名法外,其他的属性的名字使用“英文名字(首字母大写)”命名,多单词可使用驼峰命名法或用下划线隔开2.2.3 注释约定本文还会对注释进行约定,相关注释风格可以在eclipse中导入codetemplates.xm文件以下是几个基本点: r 注释应该增加代码的清晰度代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。

      r 如果你的程序不值得注释,那么它也很可能也不值得运行 r 保持注释的简洁最好的注释应该是简单明了的注释注释不必洋洋洒洒,只需提供足够的信息,使别人能够理解你的代码r 先写注释,后写代码写代码注释的最好方法是在写代码之前就写注释这使你在写代码之前可以想想代码的功能和运行而且这样确保不会遗漏注释另一种方法是边写代码边写注释因为注释可以使代码更易理解,所以在程序开发的过程中,也可以利用这一点如果打算花些时间写注释,那么至少你应从这个过程中获得些什么r 注释信息不仅要包括代码的功能,还应给出原因例如,下面例1中的代码显示金额在 $1,000 以上(包括 $1,000)的定单可给予 5% 的折扣为什么要这样做呢?难道有一个商业法则规定大额定单可以得到折扣吗?这种给大额定单的特殊是有时限的呢,还是一直都这样?最初的程序设计者是否只是由于慷慨大度才这样做呢?除非它们在某个地方(或者是在源代码本身,或者是在一个外部文档里)被注释出来,否则你不可能知道这些2.2.4 快速浏览JavaDocSun 公司的 Java Development Kit (JDK) 中有一个名为 javadoc 的程序它可以处理 Java 的源代码文件,并且为 Java 程序产生 HTML 文件形式的外部注释文档。

      Javadoc 支持一定数目的标记,标识注释文档中各段起始位置的保留字详情请参考 JDK javadoc 文档标记用于目的@author name类、接口说明特定某一段程序代码的作者每一个作者各有一个标记@deprecated类、成员函。

      点击阅读更多内容
      关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
      手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
      ©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.