java开发宝典

总体规约以《阿里巴巴Java开发手册》为主，请开发人员至少阅读一遍该手册。一、java编码规范Springboot约定大于配置，都有哪些约定？目录结构上的约定：依旧按照maven的约定。Spring Boot 项目的主程序类位于项目的根包下，其他相关的组件如控制器（Controller）、服务（Service）、数据访问对象（DAO）等会放在主程序类所在包的子包中。例如，com.example.demo是主包，那么com.example.demo.controller存放控制器类，com.example.demo.service存放服务类。src/main/java目录用于存放 Java 源代码src/main/resources放配置文件（如application.yml）和静态资源（static目录存放CSS/JS，templates存放模板文件）src/test/java目录用于存放测试代码。配置文件上的约定：命名必须是application（.properties或者.yml或者.yaml都可以），但是如果你非要自己起个名字，也是可以的，怎么配上网查吧默认行为与命名规则：主启动类一般以Application或Starter结尾，如DemoApplication一些默认的自动装配：默认集成Tomcat，端口号8080；默认使用 Logback 作为日志框架，日志级别默认是INFO（未完待续。。。怎么看新代码：先找人讲一遍业务背景---》自己看一下大框架-----》跑起来，结合日志去看代码细节开发逻辑：先写大框架，再填充细枝末节。就像学习任何东西一样，先了解整个目录结构，再填充。尤其当调用其他部门接口但没沟通清楚字段取值（或者直接理解为他们不配合）的时候，先写着自己的主要逻辑，最后再填充细节。而不是把每个接口字段都搞明白了，再去开发，除非你这个需求只需要调用一个接口这么简单。优化代码的思路：（1）增强健壮性：null校验；比如字符串的split()方法增加-1参数；（2）低耦合：比如封装ENUM（3）提高运行效率：比如虽然目前只需要12个list，但是我们new一个大小为18的LinkedList，这样避免扩容的时候频繁发生数组的拷贝；比如利用缓存提高接口的响应速度（4）节省JVM内存：比如（5）安全性：加密1.1 java基础规范多使用 jdk自带库和被验证的第三方库的类和函数，不要用野路子来的jar包无论是包、类、方法、变量，见名知意3.内部类定义成static，用的时候（比如Person有个内部类EncryptData，用的时候直接Person.EncryptData），具体是为什么呢？我也不知道4. 有的时候一个系统里，两个厂商的队伍一起开发，开发方式不一样，但是堆到一起给人造成迷惑。就拿访ABC系统的接口来说，有的组他们习惯是： @FeignMethod String sendABC100200(@RequestBody String request) 有的组： @FeignMethod ABC100200Out sendABC100200(@RequestBody ABC100200In abc100200in)。两种写法都行，前者是习惯自己用JSONObject手动填充报文，然后转成String作为入参。后者习惯把报文封装成一个实体类，实体类作为入参。springboot框架会把String转成JSON传输，也会把实体类转成JSON传输。5. 这些代码要写在service层，controller调度层只做调度，具体业务逻辑都在service层，不管代码多少6.分支合并要及时，两天不合并就合不上去了。所以每天要频繁的拉取，合并。5.关于private、public、protected关键字的选择：方法别人不用的话都定义成private，如果后期别人需要用，再改成public或者protected。7.关于注释：（1）先写注释再写代码，写注释的过程就相当于梳理逻辑。（2）大家开发的时候要注意：所有的属性和变量必须要写注释（不能使用尾行注释），方法要写注释，平均每5行代码就要写一个注释（3）方法内才能用//注释，方法外一律用/**/注释”。8.所有接口都用post方法。(根本就不能这样啊，会报错9. 用快捷键把没有用到的import给自动删掉，某公司架构师曾强调“JDK1.8以上版本的项目中不应出现黄色警告”（因为JVM是懒加载，用到哪个类加载哪个类，所以没有被用到的import并不会被加载进去进而浪费资源。但是①导入但未使用会让其他开发者产生困惑“是不是哪里逻辑漏写了？”②如果代码中使用了未完全限定的类名，且存在同名类，编译器可能因导入的冗余类产生歧义，导致编译错误。这种情况在多人协作或依赖库频繁更新时尤为常见）③如果import的这个包被删了你的代码虽然根本没用到这个包，但会爆红10、IDEA里灰色的代码都要删掉（吗？存疑，还是想保留一些废弃逻辑以后看的）10、用快捷键把代码重排一下（空格对齐，括号对齐，好处① 这样看起来更像是一个人写的，好处②merge的时候也不会冲突）。10.前端、后端都去做为空校验，防止恶意攻击绕过前端这种。后端要自己给自己兜底，不要觉得前端肯定能校验出来就不用验了后端层面：（1）controller所有字段都加“required=false”，即便是需求文档规定某个字段不能为空。原因一：判空属于业务校验，而controller层只做转发，业务逻辑应该由service层负责完成。原因二：一个业务可能来自安卓客户端、网页端多个渠道，也就是多个controller接口去调用同一个service接口，那只在service层做就好。原因三：若 Controller 层强制非空，当参数缺失时会直接抛出异常（如MissingServletRequestParameterException），导致请求无法进入业务逻辑，抛出这个错误用户看不懂啊。而设置为required=false后，可在方法内定制化返回友好错误信息，直接告诉用户缺了哪个必填项。数据库层面：数据库没法做为空校验。（iftest'''A!=null'不是为空校验，而是实现“A在的时候用A判断，A和B都在用A和B一起判断”这样正常的判断逻辑），直接默认我需要的必要参数前端、后端都校验过了，走到这一步的都是正常的，数据库直接实现逻辑就行。比如说，我要实现“用userId查用户名的操作”，需求文档上要求userId不能为空，这个校验交给前端、后端去做，写SQL语句的时候，你就认为userId一定不为空就行了。数据库对数据完整性的保护如何实现的呢？该字段在数据库里要求不能为null，那么落库的时候就会报错。11. 什么时候需要把一堆变量封装成一个ENUM？表示某个状态的常量太多，并且多个.java文件都用到了，就可以考虑封装成一个ENUM了。你想，如果多个.java同时用的话，我们新增或者删除一个状态常量，不用挨个文件去改代码，直接在ENUM里改。比如很多.java文件都喜欢遍历访问CoffeeEnum这个枚举类。那就写成ENUM并且用ENUM的values()遍历方式，而不是挨个add进去ArrayListString arrayList = new ArrayList(20); For(CoffeeEnum e : CoffeeEnum.values()){ arrayList.add(e.getXxxxxx(….)); }而不是ArrayListString arrayList = new ArrayList(20); arrayList.add(); arrayList.add(); .... arrayList.add();12、删除IDEA里灰色的东西。import如果没用但是留着不删，一个是给别人造成误解，再一个是如果import的这个包被删了你的代码虽然根本没用到这个包，但会爆红。13、方法参数个数。方法的参数不要太多，虽然阿里巴巴开发手册里没说具体不能超过多少个，开发经验上来说个数不能超过4个吧。一个是便于阅读，再一个是当个数过多时直接封装成DTO类便于维护。14、traceId等各种流水号需要用UUID的原因：多次发起一样Id的会被认为是恶意攻击。15、测试环境跟准生产环境不一定一致，准生产和生产也不一定完全一致？测试环境行得通，准生产不一定行得通（测试环境可能只有4个pod），理论上测试环境=准生产=生产。就像traceId，我在开发环境里写死了，跑通没问题。但是在生产环境上，可能会对traceId进行防攻击的唯一性检查，就会报错了。