JAVA项目程序员开发手册-word可编辑.docx

程序员开发手册  目录 TOC \o 1-3 \u 1 前言 1 2 编程规约 1 2.1 命名风格 1 2.2 常量定义 5 2.3 代码格式 6 2.4 日期时间 9 2.5 集合处理 11 2.6 并发处理 17 2.7 注释规约 23 2.8 其它 25 3 异常日志 27 3.1 错误码 27 3.2 异常处理 29 3.3 日志规约 32 4 单元测试 35 5 安全规约 38 6 数据库 40 6.1 建表规约 40 6.2 索引规约 42 6.3 SQL 语句 44 7 工程结构 47 7.1 应用分层 47 7.2 二方库依赖 49 7.3 服务器 52 8 设计规约 53  PAGE 1 前言 现代软件行业的高速发展对开发者的综合素质要求越来越高，因为不仅是编程知识点，其它维度的知识点也会影响到软件的最终交付质量。比如：数据库的表结构和索引设计缺陷可能带来软件上的架构缺陷或性能风险；工程结构混乱导致后续维护艰难；没有鉴权的漏洞代码易被黑客攻击等等。所以本手册以Java 开发者为中心视角，划分为编程规约、异常日志、单元测试、安全规约、 数据库、工程结构、设计规约七个维度，再根据内容特征，细分成若干二级子目录。另外，依据约束力强弱及故障敏感性，规约依次分为强制、推荐、参考三大类。 在延伸信息中，“说明”对规约做了适当扩展和解释；“正例”提倡什么样的编码和实现方式；“反例”说明需要提防的雷区，以及真实的错误案例。 手册的愿景是码出高效，码出质量。现代软件架构的复杂性需要协同开发完成，如何高效地协同呢？无规矩不成方圆，无规范难以协同，比如，制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全，试想如果没有限速，没有红绿灯，谁还敢上路行驶？对软件来说，适当的规范和标准绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，以一种普遍认可的统一方式一起做事，提升协作效率，降低沟通成本。代码的字里行间流淌的是软件系统的血液，质量的提升是尽可能少踩坑，杜绝踩重复的坑，切实提升系统稳定性，码出质量。 编程规约 命名风格 1. 【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。 反例 ：_name / name / $name / name_ / name$ / name 2. 【强制】所有编程相关的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，纯拼音命名方式更要避免采用。 正例：ali / alibaba / taobao / cainiao/ aliyun/ youku / hangzhou 等国际通用的名称，可视同英文。 反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3 3. 【强制】类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。 正例：ForceCode / UserDO / HtmlDTO / XmlService / TcpUdpDeal / TaPromotion 反例：forcecode / UserDo / HTMLDto / XMLService / TCPUDPDeal / TAPromotion 4. 【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格。 正例： localValue / getHttpMessage() / inputUserId 5. 【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。 正例：MAX_STOCK_COUNT / CACHE_EXPIRED_TIME 反例：MAX_COUNT / EXPIRED_TIME 6. 【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。 7. 【强制】类型与中括号紧挨相连来表示数组。 正例：定义整形数组 int[] arrayDemo; 反例：在 main 参数中，使用 String args[]来定义。 8. 【强制】POJO 类中的任何布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。 说明：在本文 MySQL 规约中的建表约定第一条，表达是与否的值采用 is_xxx 的命名方式，所以，需要在resultMap设置从is_xxx 到 xxx 的映射关系。 反例：定义为基本数据类型 Boolean