编码开发规范
目 录
- 1.引言... 1
- 1.1 编写目的... 1
- 1.2 使用范围... 1
- 1.3 术语与缩略语... 1
- 1.4 参考资料... 2
- 2................................................................................................................................................. Java开发规范... 2
- 2.1 命名规范... 2
- 2.1.1.................................................................................................................. package 的命名... 3
- 2.1.2....................................................................................................................... Class 的命名... 3
- 2.1.3.......................................................................................................................... 变量的命名... 3
- 2.1.4.......................................................................................................................... 常量的命名... 4
- 2.1.5.......................................................................................................................... 参数的命名... 4
- 2.1.6.......................................................................................................................... 数组的命名... 4
- 2.1.7.......................................................................................................................... 方法的参数... 4
- 2.1.8.......................................................................................................................... 方法的命名... 4
- 2.2 注释规范... 4
- 2.2.1............................................................................................ 使用代码注释的目的和关键... 4
- 2.2.2.......................................................................................................................... Java的注释... 5
- 2.2.3........................................................................................................................... JSP中注释... 8
- 2.2.4.............................................................................................................. 使用javadoc注释... 8
- 2.2.5.............................................................................................................................. 变更注释... 8
- 2.3 代码编写格式... 9
- 2.3.1...................................................................................................................... 缩进4个空格... 9
- 2.3.2................................................................................................................... 页宽为80字符... 9
- 2.3.3....................................................................................................................... if-else语句块... 9
- 2.3.4.................................................................................................................. try-catch语句块... 10
- 2.3.5....................................... 方法与方法之间或者方法体内的逻辑块之间以空行分隔... 10
- 2.3.6................................................................. public方法和public变量要优先排列前面... 10
- 2.3.7............................................................................ 用三目运算符代替简单的if－else块... 10
- 2.3.8............................................................................................................. 运算符的排版格式... 11
- 2.3.9.......................................................................... 使用圆括号来避免运算符优先级问题... 11
- 2.3.10............................................................................................................... import使用规定... 11
- 2.4 Exception异常处理... 11
- 2.4.1.................................................................... 分别捕获子类的异常而非父类Exception. 11
- 2.4.2................................................................... 使用Exception来返回异常，而非返回值... 11
- 2.4.3............................................................................................ 禁止使用空的catch(){}代码... 12
- 2.4.4........................................................................................................... Exception信息输出... 12
- 2.5 性能优化（推荐标准）... 12
- 2.5.1.................................................................................................... 避免不必要的对象构造... 12
- 2.5.2....................................................................................... 不要在循环中构造和释放对象... 12
- 2.5.3................................................................................................... 使用 StringBuffer 对象... 13
- 2.5.4....................................................................... 避免太多的使用 synchronized 关键字... 13
- 2.5.5.................... 不是必要的时候不要使用Vector、Hashtable等同步化的数据结构... 14
- 2.6 设计类和方法的原则... 14
- 2.6.1................................................................................................ 创建具有很强内聚力的类... 14
- 2.6.2................................................................................... 创建松散连接和高度专用的方法... 14
- 2.6.2.1 使所有方法都执行专门的任务... 14
- 2.6.2.2 尽量使方法成为自成一体的独立方法... 15
- 2.6.3.......................................................................... 设计类和方法时，要达到下列目的：... 15
- 3................................................................................................................................................. VUE开发规范... 16
- 3.1 编码规范... 16
- 3.2 Vue项目中的文件/文件夹命名规范... 16
- 3.3 排版规范... 17
- 3.3.1.............................................................................................................................. 代码格式... 18
- 3.4 注释规范... 20
- 3.5 语句规范... 21
- 3.6 项目开发前端注意事项... 22
- 3.7 Vue前端目录结构规范... 22
- 3.7.1............................................................................................................. Vue前端目录说明... 22
- 3.7.2............................................................................................................ Vue目录结构规范... 23
- 4............................................................................................................................. LONE平台实施开发规范... 24
- 4.1 svn使用说明... 24
- 4.2 文件目录结构规范... 25
- 4.2.1............................................................................................................. Java目录结构说明... 25
- 4.2.2............................................................................................................ Java目录结构规范... 26
- 4.2.3............................................................................................................. Java目录结构示例... 26
- 4.3 模块命名规范... 27
- 4.4 命名规范... 27
- 4.5 开发流程... 28
- 4.6 工作流开发流程... 28
- 4.7 开发要求... 29
- 4.7.1....................................................................................................................................... 常量... 29
- 4.7.2............................................................................................................. 通用功能使用要求... 29
- 4.7.3...................................................................................................................... 系统编码规则... 29
- 4.7.4............................................................................................................ VUE前端开发要求... 30
- 5................................................................................................................................. Maximo实施开发规范... 30
- 5.1 文件目录结构规范... 30
- 5.2 模块命名规范... 33
- 5.3 应用程序命名规范... 34
- 5.4 应用服务命名规范... 34
- 5.5 应用程序目录命名... 34
- 5.6 域命名规范... 36
- 5.7 数据库命名规范... 37
- 5.8 其他说明... 39
1.引言
此文档对开发工作提出了一些必须遵守的规范，主要目的是为了使产品、平台的开发更加有序，同时提高产品和平台的可靠性、可维护性、可扩展性和一致性。
本文描述了JAVA开发中的有关包、类、接口、方法、实例变量、变量和常量的命名规则，以及描述Vue开发中文件名称命名、Vue代码规范、通用组件目录结构、Vue代码内容要求，用于规范JAVA、Vue编程过程中的命名和代码书写规范。
本文档提供了JAVA通用的开发规范，以及Vue开发规范，同时参考通用规范定制了更适合基础开发平台开发的个性化规范，目的是为了对产出代码的质量及后期维护提供保障。
北京乐码仕智能科技有限公司的相关项目及产品研发开发人员和相关部门技术管理人员。
API：Java ApplicationProgrammingInterface API（应用程序接口）是事先写好的代码, 组织到相关包；
Applet：（小应用程序）是在WEB浏览器里运行的java程序；
Vue ：（读音 /vjuː/, 类似于 view） 是一套构建用户界面的 渐进式框架。与其他重量级不同的是，Vue 采用自底向上增量开发的设计。
JVM ：JavaTM VirtualMachine1 JVM（JAVA虚拟机），能执行java编译器产生的指令的运行环境；
Package：java语言的程序包；
Class：java编写的程序类；
Exception：异常；
Function object：函数对象；
Method：方法；
Object：对象；
Javadoc：客户程序员通过使用java自动编译生成的doc文档；
Import：导入支持类（可以是JDK基础类或者自己编写的类），可以供本类调用方法和属性；
HTML：（Hyper Text Markup Language 超文本标识语言）是一种用来制作超文本文档的简单标记语言。
JavaBean：是一种JAVA语言写成的可重用组件。
JUnit：是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个。
Servlet：是在服务器上运行的小程序。
StringBuffer：可以存储和操作字符串，即包含多个字符的字符串数据。
SVN：是Subversion的简称，是一个开放源代码的版本控制系统。
《基础开发平台-技术文档V1.0》
《北京轨道交通资产管理信息系统_开发规范》
命名要使用具有实际意义的英文单词，或者单词的缩写，不要使用单个的字母来命名一个变量，一个好的命名，几乎不用看文档就能知道该方法或者变量的意义，如同Java API，它的命名还是很值得借鉴的。
命名的一般规范：
- 尽量使用完整的英文描述符（除非特别必要，尽量不要使用汉语拼音缩写形式）。
- 采用适用于相关领域的术语（如url之类的术语，但术语必须是大家认可的）。
- 采用大小写混合使名字可读。
- 尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一，一些常用的缩写可以参考Java API 如message的缩写可以为msg。
- 避免使用长的名字（小于 15 个字母是个好主意）。
- 避免使用类似的名字，或者仅仅是大小写不同的名字。
- 避免使用下划线（除静态常量等）。
package 的名字应该都是由小写字母单词组成,名字的前两级为com.lone，三级名称为模块名。例如：包名com.lone.modules.system.controller表示system模块下处理类包名。
Class 的名字必须由大写字母开头而其他字母都小写的单词组成，对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
例如：public class ThisAClassName{}
对于变量的命名，要尽量达到能通过变量名知道这个变量表达的含义，变量采用小写字母开头，对于由多个单词组成的变量名，所有单词都应紧靠在一起，而且大写中间单词的首字母。对于常量（static final类型）采用如下方式命名：字母全部大写并使用下划线分隔单词（如：BOOL_FALSE）。
业务常量定义时要在com.lone创建目录constant,放到这个目录下。
参数的名字必须和变量的命名规范一致。
数组命名和变量命名类似，主要是能体现出这是一组数据。
使用有意义的参数命名。同时请参照“变量的命名”条目。
对于javabean中简单的set和get方法，可以使用和要赋值的字段一样的名字。
setSize(int size){
this.size = size;
}
方法的命名遵循变量的命名，方法的名字必须用一个小写字母开头。后面的单词用大写字母开头。
- 文字说明代码的作用（即为什么要用编写该代码，而不是如何编写）；
- 明确指出该代码的编写思路和逻辑方法；
- 使阅读者注意到代码中的重要转折点；
- 使阅读者不必在他们的头脑中仿真运行代码的执行方法。
- 何时书写注释：
-
-
- 请在每个if语句的前面加上注释；
- 在每个switch语句的前面加上注释。与if语句一样，switch语句用于评估对程序执行产生影响的表达式。
- 在每个循环的前面加上注释。每个循环都有它的作用，许多情况下这个作用不清楚直观。
- Java的注释
-
-
单行注释：// 注释一行
多行注释：/* ...... */ 注释若干行
文档注释：/** ...... */ 注释若干行，并写入 javadoc 文档 ，对共有变量、方法，使用该种注释。
说明：提供给客户程序员使用的接口、公用类要严格按照文档注释进行注释，并生成doc文档，做到客户程序员通过阅读doc来使用共有类，而不是阅读源代码来使用一个公共接口或者类。
- 边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性，注释要简单明了。
- 要区分两种注释的区别，一种是文档注释，是给客户程序员使用的，他们不会阅读你的源代码，因此要尽可能的提供更多的信息，让他们使用起来方便；另一种是非文档注释，是提供给代码的维护人看的，是为了给代码的维护人员看的，他们是要看到你的源代码的，因此非文档注释要简单明了。
下面是一个公用类的注释：
package java.blah;
import java.blah.blahdy.BlahBlah;
/**
* 对类的用途的描述.
*
* @version 1.82 1999-03-18 （版本信息，变更关键字），加上版本作者
1.82 1999-09-23
* @author Firstname Lastname（作者信息）
*/
public class MyClass extends SomeClass {
/** 对公有成员变量的注释（单行的格式），建议采用单行的格式，节省版面*/
public int classVar1;
/**
* 对共有成员变量的注释（多行的格式）
* more than one line long
*/
private Object classVar2;
/**
* ...对该方法用途的描述
* @param userName对参数userName的描述
* @param password 对参数password的描述
* @exception 对抛出异常的说明
* @return String 对返回值的描述
*/
public String classMethod(String userName,String password) {
// 对代码片断的注释（如，以下用于密码验证）
if( flag == true){
//对代码逻辑块进行注释（如：如果密码验证通过）
}else{
//对代码逻辑块进行注释（如：如果密码验证未通过）
}
}
}
- 注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被其他开发人员理解。
- 保持注释的简洁。
- 注释信息不仅要包括代码的功能，还应给出原因。
- 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
- 一般有参数有返回值有异常的方法自动生成的注释类似如下：
/**
*
* %方法的一句话概述。
* <p>%方法详述（简单方法可不必详述）%</p>
* @param s 说明参数含义
* @return 说明返回值含义
* @throws IOException 说明发生此异常的条件
* @throws NullPointerException 说明发生此异常的条件
*/
以下情况必须添加注释：
- 私有方法，除构造函数外，添加该方法的注释。
- 复杂方法（如方法体超过30行），或包含关键算法的方法，必须对内部的操作步骤添加注释（行注释//或块注释/* */均可）。
- 方法内部多次转换含义的变量，必须对该变量的含义发生变化时添加注释。
- 方法内部存在不易理解的多个分支条件的表达式，必须对每个分支添加注释。
- 新创建的类需要在类前有如下注释：
/*
* 作者：***
* 创建日期：2019-05-31
*/
修改已经提交后的类时候，在修改的方法或函数里面需要注释修改时间、修改人员、修改内容及原因等内容；
/*
* 增加人员功能
* ***
* 日期：2019-05-31
*/
＜%-- comment --%＞ JSP注释，也称为“隐藏注释”。JSP引擎将忽略它。标记内的所有JSP脚本元素、指令和动作都将不起作用。这种注释不会出现载JSP编译后的JSP 页面中，建议使用。
＜!-- comment --＞ HTML注释，也称为“输出的注释”，直接出现在结果HTML文档中。标记内的所有JSP脚本元素、指令和动作正常执行。
在自定义类中必须使用javadoc注释以保证客户程序员通过使用java自动编译生成的doc文档就能够使用你的类。
这里的注释请通过eclipse开发工具辅助生成，对参数、返回值等要做必要的说明。
为了方便的让代码维护者看到文件的变更信息及历史，对于重要的修改请使用变更注释。在javadoc的@version条目下请标明版本信息、修改日期、修改关键字和简单的修改说明信息。在修改代码的开始和结束处使用修改标识和关键字进行标示。注释时尽量不要删除变更前代码。同时保证其他人员可以使用变更关键字来查找变更位置（后起的关键字必须保证和前面的关键字不重复并尽量保证非类似）。
举例如下：
//变更修改注释：变更关键字：modify。张三（2006-04-26）。因为错误进行了变更修改。
/*首先注释修改前的代码*/
开始进行变更修改
//变更修改完毕。变更关键字：modify
缩进应该是每行4个空格。尽量不要在源文件中保存Tab字符。在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度。
页宽应该设置为80字符。源代码超过这个宽度可能导致无法完整显示，但这一设置也可以灵活调整。在任何情况下，超长的语句应该在一个逗号或者一个操作符后折行。一条语句折行后，应该比原来的语句再缩进4个字符。
if-else语句块的格式如下，else紧接着if的结束大括号。
if（……）{
……
}else{
……
}
即使if条件语句语句后面如果只有一行代码，最好也放在大括号中
如：
if( flag == true){
flag == false;
}
String username ＝ new String();
……
而非以下形式：
if( flag == true)
flag == false;
String username ＝ new String();
……
try-catch语句块应遵循如下格式：
try{
……
}catch(Exception ex){
……
}finally{
……
}
方法与方法之间，或者一个方法体中的逻辑块之间用空行来分割，增强代码的可读性。
变量的排列顺序：首先是类的公共变量，随后是保护变量，再后是包一级别的变量(没有访问修饰符，access modifier)，最后是私有变量
方法的排列顺序：同变量的排列顺序。这样使得首先看到得是类得公有变量和公有成员函数。
在判断关系简单并且稳定不变的地方使用可以增强代码可读性和提高性能。
一元符与操作数之间不要空格，如i++，i--，i与++之间不要空格。
二元操作符与操作数之间要空格分开，如a = b + c;加号两端都加空格。
即使运算符的优先级对你而言可能很清楚，但对其他人未必如此。你不能假设别的程序员和你一样清楚运算符的优先级。
应该在表达式中明确的制定优先级，避免难以理解的代码出现。
引入jdk及j2ee标准类时可以使用*，如import java.io.*；
引入自定义类时，请一个类一条import语句，以增强代码可读性。如import
com.lone.modules.system.model.SysUserRoleDepartVo;代码中禁止出现魔术字
代码中禁止出现魔术字，代码中出现的数字应该增加详细说明。
-
- Exception异常处理
通常的思想是只对错误采用异常处理：逻辑和编程错误，设置错误，被破坏的数据，资源耗尽等。
通常的法则是系统在正常状态下以及无重载和硬件失效状态下，不应产生任何异常。异常处理时可以采用适当的日志机制来报告异常，包括异常发生的时刻。不要使用异常实现来控制程序流程结构。
比较合理的做法是分别捕获各个子类异常之后，分别处理不同的异常，不要一个方法内就一个try{}catch(){}块。
尽量使用Exception来反映函数运行中的异常，而不是使用返回值来反映，除非有充分理由这样做。越是底层的类越应该使用Exception来反映函数运行中的异常。
绝对不允许代码中出现catch(){}而什么也没做。因为这样做还不如直接把异常抛出，让使用该方法的人来处理。同时只要你catch了一个异常，JVM就认为你已经处理了该异常，其实你什么也没有做，这样就使很多的异常可能隐藏起来了。
在每一个catch到一个异常的时候，在调试状态下请使用ex.printStackTrace()来输出错误信息；在运行状态下请使用ex.getMessege()来输出错误信息。通常情况下应该加上比较容易读懂的中文信息的输出。
有的时候，构造了一个变量由于某种原因，您可能没有使用它，每构造一个对象可能会花销一定得CPU时间，正确的做法是先申明，到需要使用的时候才构造它的一个对象。一般不要在申明时构造一个对象（尤其是针对类变量）。
不要象一下代码一样构造对象：
for(int i = 0;i < 50 ;i ++){
Double doubleObj = new Double;
doubleObj = ……；
}
而应该使用如下方法：
Double doubleObj = new Double;
for(int i = 0;i < 50 ;i ++){
doubleObj = ……；
}
在处理 String 的时候要尽量使用 StringBuffer 类，StringBuffer 类是构成 String 类的基础。String 类将 StringBuffer 类封装了起来，（以花费更多时间为代价）为开发人员提供了一个安全的接口。当我们在构造字符串的时候，我们应该用 StringBuffer 来实现大部分的工作，当工作完成后将 StringBuffer 对象再转换为需要的 String 对象。比如：如果有一个字符串必须不断地在其后添加许多字符来完成构造，那么我们应该使用 StringBuffer 对象和它的 append() 方法。如果我们用 String 对象代替 StringBuffer 对象的话，会花费许多不必要的创建和释放对象的 CPU 时间。
例如：常用的是定义SQL语句时，你可能会用到过+=来扩充SQL语句的内容，由于String对象是长度不能改变的，其实使用+=是每次构造一个新的String对象。该字符串的内容是原来字符串内容与新加入的内容之和,再把新字符串赋值给原来的字符串变量。
比较合理的做法是使用StringBuffer类来代替String。
StringBuffer stringBuffer = new StringBuffer("初始内容");
StringBuffer.append("＋加上新的内容");
StringBuffer.toString();
StringBuffer的append还重载了许多实用方法，如append(int intValue)等等，支持基本数据类型的，省去了你再将基本数据类型转换为对应的String ，再使用+=连接字符串的麻烦。
说明：在字符串长度大于100时，必须使用本标准。
避免不必要的使用关键字 synchronized，应该在必要的时候再使用它。
这些数据结构是同步化的，会对性能造成一定的影响，因此，不是必要的时候不要使用，可以使用他们的替代品ArrayList和HashMap代替。
- 方法的重要性往往比类的重要性更容易理解，方法是指执行一个统一函数的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。
- 之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。
- 类应该用来将相关的方法组织在一起。
- 当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。
- 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。
- 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。
每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。
创建专用方法有许多好处。首先调试将变得更加容易。
当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法会使调试和修改变得比较困难，因为它牵涉到更多的因素。松散连接的方法优于紧密连接的方法，但你不可能使每个方法都成为独立的方法。
若要使方法具备较强的独立性，方法之一是尽量减少类变量。
创建方法时，设法将每个方法视为一个黑箱，其他例程不应要求了解该方法的内部工作情况，该方法也不应要求了解它外面的工程情况。这就是为什么你的方法应依靠参数而不应依靠全局变量的原因。
创建专用方法时，请考虑下列指导原则：
- 将复杂进程放入专用方法。如果应用程序使用复杂的数学公式，请考虑将每个公式放入它自己的方法中。这样使用这些公式的其他方法就不包含用于该公式的实际代码。这样也可以更容易发现与公式相关的问题。
- 将数据输入/输出（I/O）放入专用方法。
- 将专用方法中可能要修改的代码隔离。如果你知道某个进程经常变更，请将这个多变的代码放入专用方法，以便以后可以更容易的进行修改，并减少无意中给其他进程带来问题的可能性。
- 将业务规则封装在专用方法中。业务规则常属于要修改的代码类别，应与应用程序的其余部分隔开。其他方法不应知道业务规则，只有要调用的方法才使用这些规则。
1. 创建更加容易调试和维护的方法；
2. 创建具有强大内聚力的类；
3. 创建高度专用的方法；
4. 创建松散连接的方法；
5. 尽量使方法具有独立性；
6. 提高方法的扇入性；
7. 降低方法的扇出性。
优秀的项目源码，即使是多人开发，看代码也如出一人之手。统一的编码规范，可使代码更易于阅读，易于理解，易于维护。尽量按照ESLint格式要求编写代码
- 使用ES6风格编码源码
- 定义变量使用let ,定义常量使用const
- 使用export ，import 模块化
- 组件 props 原子化
- 提供默认值
- 使用 type 属性校验类型
- 使用 props 之前先检查该 prop 是否存在
- 避免 this.parent4.谨慎使用this.parent4.谨慎使用this.refs
- 无需将 this 赋值给 component 变量
- 调试信息console.log() debugger 使用完及时删除
- Vue项目中的文件/文件夹命名规范
- 文件或文件夹的命名遵循以下原则：
- index.js 或者 index.vue，统一使用小写字母开头的(kebab-case)命名规范
- 属于组件或类的，统一使用大写字母开头的(PascalCase)命名规范
- 其他非组件或类的，统一使用小写字母开头的(kebab-case)命名规范
- 列宽
代码列宽控制在100字符左右。
- 换行
当表达式超出或即将超出规定的列宽，遵循以下规则进行换行：
1、在逗号后换行；
2、在操作符前换行；
3、规则1优先于规则2；
- 缩进
缩进应该是每行一个Tab(4个空格)，不要在代码中使用Tab字符。
- 空行
空行是为了将逻辑上相关联的代码分块，以下情况应加入一个空行。
1、类与类的定义之间；
2、方法与方法、属性与属性之间；
3、方法中不同的逻辑块之间；
4、注释与它注释的语句间不空行，但与其他的语句间空一行；
- 空格
关键字和( 应该用空格隔开。
方法名和( 之间不要使用空格。
多个参数用逗号隔开，每个逗号后都应加一个空格。
语句中的表达式之间用空格隔开。
- 变量声明
总是使用var声明变量。
一行只做一个声明。
在变量声明时就做初始化。
应避免不同层次间的变量重名。
方法内禁止定义和使用全局变量。
- 大括号的使用约定。
| * 如果是大括号内为空，则简洁地写成{}即可，不需要换行 例：{} * 非空代码块则: （1）左大括号前不换行有空格； （2）左大括号后换行； （3）右大括号前换行； （4）右大括号后还有else等代码则不换行; （5）表示终止的右大括号后必须换行。 例： methods: { testFunc () { console.log("测试方法"); var flag = false; if (this.num === 0) { flag = true; } else { flag = false; } } } |
- 左右小括号与中间字符之间不出现空格。
| 例： if (this.num === 0) { // 左右小括号()中间字符直接不出现空格 flag = true; } |
- if/for/while/switch 等保留字与括号之间都必须加空格。
| 例： if () {} for () {} while () {} switch () {} |
- 任何二目、三目运算符的左右两边都需要加一个空格。
| 例： int a = 1, b = 2, z, c = 3; z = a > b ? a : (b > c ? b : c); |
- 注释的双斜线与注释内容之间有且只有一个空格
| 例： // 我就是个注释信息展示 /** 我就是个注释信息展示 **/ /** ** 我就是个注释信息展示 **/ |
- 方法参数在定义和传入时，多个参数逗号后边必须加空格
| 例： methods: { testFunc (pra1, pra2, pra3) { console.log("测试方法"); var flag = false; if (this.num === 0) { flag = true; } else { flag = false; } } } |
- 在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用 单行的编码方式:if (condition) statements;
代码注释在一个项目的后期维护中显的尤为重要，所以我们要为每一个被复用的组件编写组件使用说明，为组件中每一个方法编写方法说明。
以下情况，务必添加注释：
- 公共组件使用说明
- 各组件中重要函数或者类说明
- 复杂的业务逻辑处理说明
- 特殊情况的代码处理说明,对于代码中特殊用途的变量、存在临界值、函数中使用的hack、使用了某种算法或思路等需要进行注释描述
- 注释块必须以/**（至少两个星号）开头**/；
- 单行注释使用//；
单行注释
普通方法一般使用单行注释// 来说明该方法主要作用
多行注释
组件使用说明，和调用说明
<!--公用组件：数据表格
/**
* 组件名称
* @module 组件存放位置
* @desc 组件描述
* @author 组件作者
* @date 2018年8月13日17:22:43
* @param {Object} [title] - 参数说明
* @param {String} [columns] - 参数说明
* @example 调用示例
*
*/
-->
- 需要用请求和公共方法的文件，要用import引入,例如:
import AList from 'ant-design-vue/es/list'
import AListItem from 'ant-design-vue/es/list/Item'
- 子组件引入方式
| 公共组件经常使用如： header,footer等会一起打包到公共js文件。 先import xxx(UserModal) from './xxx.vue' components: { /* 引入子组件*/ UserModal }; export default { name: UserList, 名称 components: {}, 组件 data() { 数据 return{ } }, methods: {}, 操作方法 watch: {'checkboxModel': {}}, 监听 computed : {"val" : function() {return "123";}} 计算属性 beforeCreate: function () {}, 创建之前 created: function () {}, 创建完 beforeMount: function () {}, 挂载之前 mounted: function () {}, 挂载完成 beforeUpdate: function () {}, 更新之前 updated: function () {}, 更新完成 beforeDestroy: function () {}, 销毁之前 destroyed: function () {} 销毁完成 } |
- Css要求
（1）vue以局部css来写<style lang="less" scoped></style>只作用于当前vue文件。
(2）公共使用的css要单独放在一个文件夹里（less.css）。
项目开发时，配置菜单必须遵循如下要求：
- 一级菜单路径必须“/”开头+自定义名字（取有意义的英文名字），二级菜单路径要对应一级菜单路径
比如:首页portlet菜单，一级菜单路径: /portlet
二级菜单路径:/portlet/userInfo
注意：如果有三级菜单可按照上面一级、二级菜单路径配置。
| ├──ant-design-lone-vue ├── node_modules *项目依赖 ├── public * ├── src *源代码 │ ├── api *所有请求 │ ├── assets *主题 字体等静态资源 │ ├── components *全局公用组件 │ ├── config *项目配置 │ ├── mixins │ ├── router *路由菜单 │ ├── store *全局store管理 │ ├── utils *全局通用方法 │ ├── views *基础模块根目录 │ │ └── account │ │ └── dashboard *首页组件 │ │ └── exception *异常处理 │ │ └── form │ │ └── jeecg │ │ └── list │ │ └── modules *项目开发使用这个目录开发 │ │ └── profile │ │ └── advanced │ │ └── basic │ │ └── result │ │ └── system *开发平台基础模块 │ │ └── user ├── package.json *项目配置文件。 ├── stop |
- 项目开发模块时模块放在：\src\views\modules\+(模块名称)
- 根组件命名
\src\views\modules\(模块名称),如果前端是table界面以（模块名+List）内容名结尾，如UserList.vue。
- 其他自定义组件命名：可在\src\views\modules\(模块名称)\modules,创建子组件命名, 以（模块名+Modules）内容名结尾,注意大小写区分，单词首字母大写。
- 项目通用组件位置：\src\ components
- 首页组件文件位置：\src\views\dashboard\portlet\xxxx.vue
- LONE平台实施开发规范
-
- svn使用说明
公司内部代码要求统一通过svn进行管理，研发人员应及时将开发或修改的完成的代码上传至svn服务器。
- 项目SVN目录地址：
http://124.204.57.82:8887/svn/Dev-Project/Framework-boot/trunk
- 项目下设置了8个文件夹：
| ├── 入口 │ ├──ant-design-lone-vue │ ├──lone-boot-cloud-consumer │ ├──lone-boot-cloud-provider │ ├──lone-boot-cloud-server │ ├──lone-boot-common │ ├──lone-boot-core │ ├──lone-boot-parent │ ├──lone-boot-prj ├── 结束 |
ant-design-lone-vue：存放前端Vue代码文件。
one-boot-cloud-consumer
lone-boot-cloud-provider
lone-boot-cloud-server
lone-boot-common：提供了各种功能齐全的Java通用类。
lone-boot-core：基础开发平台基础模块代码,未经许可不可乱动。
lone-boot-parent：项目jar包版本管理，通过parent工程统一管理项目所有的jar的版本。
lone-boot-prj：正式项目开发在当前lone-boot-prj Maven工程基础上编写业务代码。
| ├── src │ ├── com.lone │ │ └── common *存放相关业务通用类 │ │ └── config *项目启动需要加载的配置信息 │ │ └── constant *存放相关业务常量 │ │ └── modules │ │ └── system *模块名称 │ │ └── controller *前端控制,负责转发请求,对请求处理。 │ │ └── entity *存放实体类对象，模型， │ │ └── service *业务逻辑处理 │ │ └── impl *业务逻辑处理 │ │ └── mapper *数据库交互工作 │ │ └──vo *非持久化数据，注重前端和业务逻辑之间数据传输 ├── stop |
- 存放位置
模块程序包命名规范com.lone.modules.xxxx(system)
总共分四级，每一个级别必须用小写：
第一级别必须为:com
第二级别必须为:lone
第三级别必须为:modules
第四级别参看<模块名命名>
- 每一模块程序对应的目录命名规范
-
- 小写
- 不大于10个字节长度
- 英文全称或英文缩写
-
java文件命名规范，遵循MVC设计模式。假如我们的实例对象是：SysUser具体目录名称规范如下图：
| MVC设计模式 | 文件命名规则 | 备注 |
| com.lone.modules.system.controller | SysUserController | 每一单词的首字母为大写，其它部分为小写。 |
| com.lone.modules.system.entity | SysUser | |
| com.lone.modules.system.mapper | SysUserMapper | |
| com.lone.modules.system.service | SysUserService | |
| com.lone.modules.system.vo | SysUser |
- 模块命名规范
-
- 不大于10个字节长度
- 英文全称或者缩写
-
- 模块命名
-
-
- 系统已定义模块（开发平台原有模块）
-
-
| 系统已命名 | 描述 |
| system | 系统管理 |
| flow | 流程业务 |
| shiro | 权限控制 |
| quartz | 定时任务 |
| gantt | 甘特图 |
| 序号 | 类型 | 命名规范 |
| 1 | 数据库表 | 业务模块部分统一用一个前缀，比如资产系统用asset开头。 格式：前缀_模块缩写（汉字第一个首字母）_英文业务 英文业务如果没有通俗的，可以用汉字首字母代替 |
| 2 | 数据库字段 | 字段后缀命名规则： 1、日期：_Dt 2、代码：_Cd 3、金额：_Amt 4、次数：_Cnt 5、距离：_Distance 6、序列号：_Num 7、编号或编码：code 8、名称：name 10、备注：remarks 11、删除状态：del_flag 12、审批状态：approval_status 13、XXX状态：xxx_status |
| 3 | Java和Vue的命名 | 所有文件名以数据库表命名一致 存放位置： 参考“3.8.2 Java目录结构规范”和“4.7.2 Vue目录结构规范” |
| 4 | 变量命名 | 参考第三章和第四章 |
数据字典等具有业务意义的内容必须定义到BaseConstants类。
在开发过程中，可能重复用到的组件或方法都要放到通用类里面去，有需要通用化需求的招项目技术负责人讨论并统一安排。不要碰到类似通用方法的都要自己开发，优先参考平台通用类有没有符合自己要求的util类。
Java通用类参考“lone-boot-common”
Vue通用类参考“mixins、utils”目录，通用组件参考“components”目录。
使用平台自带的“填值规则”功能实现，方便后面灵活配置
- 编码规则实现类开发参考下面的类。
- 使用FillRuleUtil类来启动编码规则实现类。
尽量不要重写“JeecgListMixin.js”等mixin封装的方法，可以使用“functionAop.js”提供的before、after、around方法实现本页面需要实现的额外功能。使用例子：
- 每一应用对应的类文件
- 存放位置
应用程序包命名规范com.litmus.app.pr
总共分四级，每一个级别必须用小写：
第一级别必须为:com
第二级别必须为:litmus
第三级别必须为:app
第四级别参看<应用名命名>
每一应用涉及的类文件存放在：
Maximo_Home\applications\maximo\businessobjects\classes\目录之下。
-
- 每一应用程序对应的目录命名规范
- 小写
- 与应用同名
- 不大于10个字节长度
- 英文全称或英文所写
- 每一应用程序对应的目录命名规范
例如：新定义一应用取名为：test。
-
- 每一应用对应的java文件命名规范，放置应用程序包目录下
| 文件命名规则 | 举例 | 备注 |
| 应用名+Mbo.java | TestMbo.java | 每一单词的首字母为大写，其它部分为小写。 |
| 应用名+MboSet.java | TestMboSet.java | |
| 应用名+MboSetRemote.java | TestMboSetRemote.java | |
| 应用名+MboRemote.java | TestMboRemote.java | |
| 应用名+MboService.java | TestMboService.java |
-
- 字段捆绑类, 放置应用程序包目录下
以Fld开头 + 字段名称（首字母大写）
- 自定义的相关applet/ beans/servlet
Applet/beans/servlet命名规范
com.litmus. webclient.beans.pr
com. litmus. webclient.servlet
第一级别必须为:com
第二级别必须为:litmus
第三级别必须为: webclient
第四级为以下几种：
beans
servlet
applet
第五级级别参看<应用程序目录命名>
存放位置为：
Maximo_Home\applications\maximo\maximouiweb\webmodule\WEB-INF\classes\ 目录之下。
- 模块命名规范
-
- 全部大写
- 不大于10个字节长度
- 英文全称或者所写
-
- 菜单模块命名
-
-
- 系统已定义模块（Maximo原有模块）
-
-
| 系统已命名 | 描述 |
| WO | 工单 |
| ASSET | 资产 |
| SAFETY | 安全 |
| INVENTOR | 库存 |
| PLANS | 计划 |
| PM | 预防性维护 |
| PURCHASE | 采购 |
| SETUP | 管理 |
| SUPP | 资源 |
| UTIL | 配置 |
| INT | 集成 |
| SD | 服务台 |
| CONTRACT | 合同 |
| FINANCIAL | 财务 |
| REPORTING | 报表管理 |
| SECURITY | 权限 |
| SSDR | 自助 |
| SLA | 服务等级管理 |
| IPC | 浏览器 |
| 目录 | 描述 | 备注 |
| actionscfg | 快速插入设置 | |
| appsetup | 应用程序配置 | |
| asset | 资产 | |
| assetcatalog | 资产类别 | |
| budget | 预算 | |
| bulletinboard | 公告栏 | |
| calendar | 日历 | |
| common | 通用 | |
| company | 公司 | |
| compmaster | 公司模板 | |
| configure | 配置 | |
| contract | 合同 | |
| craft | 工种 | |
| crewtype | 班组 | |
| currency | 货币代码 | |
| designer | 应用程序设计器 | |
| doclink | 附件 | |
| dpamadpt | 适配器转换 | |
| dpammanu | 制造商转换 | |
| dpamos | 操作系统转换 | |
| dpamproc | 处理器转换 | |
| dpamsw | 软件转换 | |
| dpamswusg | 软件使用设置 | |
| dpldasset | 计算机 | |
| escalation | 上报 | |
| eventresponse | 事件相应 | |
| faconfig | 喜爱的应用程序 | |
| failure | 故障代码 | |
| financial | 财务 | |
| fusion | 整合 | |
| inbxconfig | 收件箱 | |
| integration | 集成 | |
| inventory | 库存 | |
| invoice | 发票 | |
| ipc | 浏览器 | |
| item | 库存项目 | |
| jobplan | 标准作业计划 | |
| knowledgebase | 知识库 | |
| kpi | KPI管理器 | |
| kpigconfig | KPI配置 | |
| labor | 员工 | |
| location | 位置 | |
| masterpm | 预防性维护模板 | |
| measurement | 测量结果 | |
| meter | 仪表 | |
| mr | 物料请求 | |
| ndasset | 网络设备 | |
| npasset | 网络打印机 | |
| person | 人员 | |
| persongroup | 人员组 | |
| pm | 预防性维护 | |
| po | 采购订单 | |
| pr | 采购申请 | |
| qual | 资质 | |
| rcncmprule | 比较规则 | |
| rcnlnkrule | 链接规则 | |
| rcnresult | 调整结果 | |
| rcntskfltr | 任务过滤器 | |
| reconlink | 任务链接 | |
| recontask | 任务过滤器 | |
| report | 报表 | |
| rfq | 询价单 | |
| route | 检修路线 | |
| rsconfig | 结果集设置 | |
| safety | 安全计划 | |
| scconfig | 布局和配置 | |
| servicecontract | 服务合同 | |
| serviceitem | 服务项目 | |
| sets | 集 | |
| signature | 签名 | |
| site | 地点 | |
| sla | 服务等级协议 | |
| solution | 解决方案 | |
| system | 系统 | |
| ticket | 服务受理单 | |
| tool | 工具 | |
| workorder | 工单 | |
域命名以LMS_ ，采用英文单词，域值可以采用英文单词或者汉字命名
- 表名全部采用大写
- 长度不超过15个字符
- 必须以LMS_开头，采用英文命名
例如：“运行”表可以命名“LMS_OPERATION”
- 对象引用的类如果是自定义类，不要多张表共用同一个类；
- Columns 列
- 列是表的组成部分，所以不要在其中涉及表名
- 列名的长度不超过15个字符
- 对于Maximo已有的表的字段命名采用＂LMS_＂+＂英文描述或缩写＂
例如：在工单表中添加部门字段，则可命名为LMS_DEPT
- 对于自建表中的列，则直接采用英文描述或者英文缩写
- 字段如果是其他对象的外键，必须建立等同对象；比如地点、人员、组织等；
- 自建表需要有以下列：
| 序号 | 列 | 名称 | 等同对象 | 等同字段 | 默认值 | 备注 |
| 1 | ***num | 编号 | &AUTOKEY& | 自动编号，命名为该列名 | ||
| 2 | CREATEDBY | 创建人 | PERSON | PERSONID | &USERNAME& | |
| 3 | CREATETIME | 创建日期 | &SYSDATE& | |||
| 4 | CHANGEBY | 更改人 | PERSON | PERSONID | ||
| 5 | CHANGEDATE | 更改日期 |
- Indexes 索引
- 索引一般与表或视图相关，所以使用表或者视图的名字来命名比较恰当
- 长度不超过20个字符
- 对于主键索引，采用maximo自动命名
- 对于自建索引，采用”对象名” +“_NDX” + 自然序列号
- 关系的备注要写详细
- 对于maximo原有表的关系，则以 LMS_开头
- 对于第一次使用的子对象，可以采用子对象名称作为关系名称
- 主对象与子对象有多个关系时，采主对象中与子对象有关系的字段名作为关系名
- Views 视图
- 表名全部采用大写
- 长度不超过15个字符
- 必须以VW_开头
- 对于一二个表组成的简单视图，甚至没有条件参数，就可以以涉及到的表名作为视图名
- Stored Procedures 存储过程
- 存储过程与表或字段没有任何逻辑绑定关系
- 以前缀”SP_”开头
- 存储过程命名采用该过程功能的英文描述
- Triggers 触发器
- 以前缀T_开头
- 以该触发器所完成的功能英文描述作为触发器名称
- 注释要求
- 注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被其他开发人员理解。
- 保持注释的简洁。
- 注释信息不仅要包括代码的功能，还应给出原因。
- 除变量定义等较短语句的注释可用行尾注释外，其他注释当避免使用行尾注释。
- 一般有参数有返回值有异常的方法自动生成的注释类似如下：
/**
*
* %方法的一句话概述。
* <p>%方法详述（简单方法可不必详述）%</p>
* @param s 说明参数含义
* @return 说明返回值含义
* @throws IOException 说明发生此异常的条件
* @throws NullPointerException 说明发生此异常的条件
*/
- 以下情况必须添加注释：
- 私有方法，除构造函数外，添加该方法的注释。
- 复杂方法（如方法体超过30行），或包含关键算法的方法，必须对内部的操作步骤添加注释（行注释//或块注释/* */均可）。
- 方法内部多次转换含义的变量，必须对该变量的含义发生变化时添加注释。
- 方法内部存在不易理解的多个分支条件的表达式，必须对每个分支添加注释。
- 新创建的类需要在类前有如下注释：
/*
* 运行培训主 Mbo
* 作者：***
* 创建日期：2010-04-11
*/
-
- 修改已经提交后的类时候，在修改的方法或函数里面需要注释修改时间、修改人员、修改内容及原因等内容；
/*
* 增加人员状态过滤功能
* ***
* 日期：2012-04-11
*/
- 工作流配置
- 业务如果需要多级审核功能，则在页面增加审核人选择字段，由用户选择进行多级审核；
-
- 工作流中的应用的人员组需要采用系统中原有的人员组，如果需要新建立人员组则需要整个项目组进行讨论；
- 工作流中如果多个操作公用一个类进行依次更改状态值，则需要进行页面刷新操作，在appbean中增加如下代码：
public int ROUTEWF() throws MXException, RemoteException {
MboRemote mbo = getMbo();
if (mbo != null) {
if (!mbo.toBeSaved()) {
mbo.getThisMboSet().reset();
structureChangedEvent(this);
fireChildChangedEvent();
sessionContext.queueRefreshEvent();
}
return super.ROUTEWF();
}
return 0;
}
-
- 多个应用程序公用同一表的时候，并且都需要工作流，则配置工作流必须是同一个工作流，在工作流内部进行分支判断。
- 工作流中配置中业务是驳回情况的，必须用《反向操作》。
- 页面
- 如果应用程序有工作流则需要增加《审批信息》tab页面
- 更新测试
- 页面符合用户业务需求，页面上控件测试；
- 测试用户需要用实际用户（多地点）进行测试，禁用系统管理员进行测试
- 业务数据（新建、修改、删除等功能）测试
- 工作流测试（各个节点）
- 确定是否影响其他应用程序，如影响则受影响的程序也需要进行测试
- 权限组测试，新增应用程序授权测试。
- 报表测试
- 脚本抽取
- 类由配置服务器提交的代码生成；
- 数据库对象包括字段的更新必须通过maximo来进行统一提交更新到DB2数据库。
- 应用程序、工作流、对象、域等脚本提交，需要注明先后顺序及是否需要confingdb；
- 提交进行系统更新时候，需要填写4个文档（见附录）：
- 更新内容概述（用于系统公告）；
- 更新脚本操作说明（用于系统更新操作）
- 更新内容详细说明（用于系统更新历史记录备份）
- 测试说明（对更新内容需要进行的测试）
- 配置管理
附录一：
系统更新通告（时间-人员）
- 运行管理：
- 停复役年度计划页面增加其他检修计划
- 停复役月度计划页面增加其他检修计划
- 技术监督：
- 技术监督年度计划执行修改
- 技术监督试验项目参数修改
- ******
附录二：
系统更新操作（时间-人员）
-
- 首先执行文件夹sql里面的***.txt,然后进行confingdb；
- 执行文件夹sql里面的***.Txt；
- 覆盖目录***的类；
- 导入xml文件夹下的xml文件；
- 在系统LOOKUPS.xml增加如下节点：
<table id="xj_appitem" inputmode="readonly" selectmode="single" >
<tablebody id="xj_appitem_tablebody" filterexpanded="true" filterable="true" displayrowsperpage="20" >
<tablecol id="xj_appitem_tablebody_col_1" dataattribute="ainum" mxevent_desc="Go To %1" mxevent="selectrecord" sortable="true" type="link" />
<tablecol id="xj_appitem_tablebody_col_2" dataattribute="appdesc" mxevent_desc="Go To %1" mxevent="selectrecord" sortable="true" type="link" colwidth="10" />
<tablecol id="xj_appitem_tablebody_col_3" dataattribute="crew" mxevent_desc="Go To %1" mxevent="selectrecord" sortable="true" type="link" colwidth="10" />
<tablecol id="xj_appitem_tablebody_col_4" dataattribute="description" mxevent_desc="Go To %1" mxevent="selectrecord" sortable="true" type="link" colwidth="100" />
</tablebody>
</table>
-
- *****
附录三：
系统更新记录（时间-人员）
- 数据库更新：
-
- 对象变更：
- 数据列修改：
- 关系变更：
- 索引：
- 存储过程;
- 视图：
- 函数：
- Job：
- 其他：
-
- 应用程序：
- 新增应用程序****，授予***权限组；
- ****
- 工作流：
- 修改****工作流：
- 增加*****人员组：
- 域：
- 增加、修改***域
- 页面;
- 修改***页面(***变更为只读)
- *****
- 权限组：
- 增加***权限组
- 报表
- 增加于***应用程序下增加报表****，赋予权限组（****）
- 类修改说明：
| 序号 | 类变更类型 | 类原文件 | 方法函数变更类型 | 变更方法函数 | 变更原因 |
| 1 | 修改/增加/删除 | app\***\**.java | 修改/增加/删除 | 修改***方法 （***行-**行） | 增加过滤 |
| 2 | webclient\beans\**\***.java |
- 其他
- *****
附录四;
系统更新测试说明（时间-人员）
- 对***应用程序的测试：
- 用***人员进行登录，测试该应用程序，主要测试以下内容：
- 页面检查（有无错误控件，有无上一行、下一行按钮（工具栏），高级查询功能测试等基本操作检查）
- 弹出窗体检查
- 新建检查
- 修改检查
- 删除记录检查（子记录）
- 报表测试
- 附件上传检查
- 选择操作选项检查
- 关联应用程序检查
- 工作流测试
- 其他需要进行的测试说明
扫一扫
1801
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
