以下是一些具体措施：

一、命名

常量：全部字母大写，不同单词之间用下划线分隔，如METHOD_TIME_THREAD；变量名和方法名：采用小驼峰命名结构，单词首字母小写，后续单词首字母大写，单词直接拼接在一起，如outNo、orderId；接口名和类名：大驼峰命名结构，所有单词首字母大写；数据库字段、网络请求字段：全部字母小写，单词之间用下划线分隔，如out_no 、 order_id 。

二、常量

对于固定的字符串和整数，尽量使用常量，避免“神奇”的字符串和整数（所谓神奇是指如果你不注意，可能会在不知情的情况下出错）。常量是无状态的，因此在命名常量类和常量时，最好不要包含太强的业务信息。您可以直接使用字面命名。否则别人使用该常量时，名字就会很奇怪。保持常量类尽可能集中，但不要将它们划分得太细。集中放置的原因是常量被认为是公共资源，理论上应该被所有代码共享。它们越集中，后续开发人员就越容易发现并避免重新定义完全相同的常量。不要划分得太细，方便后续开发人员识别。如果将每个业务划分为一组常量，则常量类会迅速膨胀，起不到常量的作用。这是一个例子：

HashMapString,String contentMap=new HashMapString,String();//放入数据时是这样的： contentMap.put('orderId',orderId);//取出数据时是这样的： String orderId=内容映射。获取('订单ID');这里的“orderId”字符串被称为魔术字符串。事实上，很容易犯错误。而如果以后这个参数改名为：movieOrderId，那么这些字符串很多地方都要改，而且不能通过搜索具体字符串一次性替换掉（因为很多变量名也叫orderId，而不是全部“ orderId”应该更改）。而如果用常量来表示“orderId”字符串，那么就在key上形成了一致性约束。以后改名字的时候，只需要改变常量的内容，put和get操作就会自动一致。这是一个简单的变量“高内聚”

三、删掉未使用代码

当前未使用的代码必须删除。一是不整齐，二是影响rd后续的判断。不宜删除或使用非自己编写的代码。不要写一半你没有想到的代码并将其保留在原处。您应该删除代码并编写待办事项提示。

四、代码布局

根据变量和方法的重要性按基本顺序排列它们。人们在阅读和理解的时候，会遵循类似于金字塔的逻辑，所以阅读代码的人应该先看到重要的东西，然后看到不太重要的东西。相关的代码应该分组在一起，不相关的代码应该用空行分隔，这样更容易快速浏览代码的逻辑。变量顺序：静态常量、成员变量，所有变量按重要性顺序排列。这样做是因为人脑具有首因效应，能够最深刻地记住它看到的第一件事。方法顺序：构造方法、静态方法、私有成员方法、共享成员方法也需要按重要性顺序排列，具体顺序可以合理权衡。理论上来说，静态方法，大多是工具类方法，与当前类有很强的绑定关系，可以放在前面。如果没有强绑定关系，可以考虑提取到外部类，避免与当前类绑定。类是模糊的。私有成员方法和公共成员方法需要按照方法的重要性进行排序。例如，提供重要服务的接口需要放在前面，get和set方法必须放在最后。方法内的代码按照功能分块，例如（不同的功能要分开，相关的功能最好集中在一起，进程用序号标识）

五、注释

添加尽可能多的重要系统，比如由于付款和订单，更改的风险很高，因此最好尽可能解释清楚。写多注释的主要原因是代码主要是英文的。以中文为母语的人经常将同一个词理解为不同的含义。例如，凭证等多义词可以被理解为文档、凭证或凭证。卷。尤其是缩写和隐形约定，大家很难理解，所以尽量多写注释。重要流程、算法逻辑、特殊判断，以及接口参数和返回值的限制，以及各种可能出现的情况，都要加上注释。这种情况下，最好用注释来解释

六、日志

。日志要分类，最好每个业务一份日志。如果混在一起，就很难统计和排查问题。日志要分类，区分error、info、debug。错误日志要认真对待，有问题一定要小心； info日志包含提示信息，如请求参数、返回内容、重要进程的节点信息等；日志的重点要明确，一般的模式是：先打印日志目的（比如有异常，说一下异常是什么，如果有提示，参数提示应该是什么），然后连接重要的参数信息。参数可以是您代码中使用的参数。这样，看到日志后，就可以更快的对应到代码上的具体情况，方便排查问题。

七、异常和中断处理

尽量统一处理异常和中断。不要到处使用try-catch 模块或if-else 判断返回。一般情况下，异常在业务接口上统一处理。当下层逻辑出现意外情况时，尽量向上层抛出。以便统一处理。此处提供了参考异常处理和代码中断模式。我们可以先继承RuntimeException，实现自己的异常类TransException。由于RuntimeException是无法捕获的异常，因此当抛出TransException时，自下而上的方法不需要抛出或try-catch，因此我们可以在顶层捕获并统一处理异常。分析上面两个类，异常类包括：错误枚举（包括错误代码、错误信息）和详细错误信息。

当我们遇到可控异常时，我们可以构造一个具体的TransException对象，并填写具体的错误枚举和具体的异常信息（如具体参数异常信息、错误堆栈、可显示的底层业务异常信息等）进入详细信息，然后将其扔到任何地方。上层会统一打印错误信息，并逐层组装返回内容，不返回false。如果出现未知的异常，尽量控制所有可控的异常。为了实现这一目标，主要采用以下方法： 1、操作数据前进行检查，如有问题，细化错误场景； 2、try-catch异常时尽量做到精确，不要try-catch太多代码。它要么是一个进程，要么是一个数据操作。要捕获异常，必须清楚地知道异常是什么类型，并细化错误场景

八、模块划分

。模块划分的目的是为了实现“高内聚”，将具有相同含义的项分组。代码和数据放在一起。首先，它方便阅读和搜索。其次，稳定的代码可以移到下层，变化可以抽象到上层。下图就是我们之前讨论的代码分层框架。不一定要完全按照这个模型，但是你可以按照这个思路有意的把代码分开。

我们从下到上说一下每一层的含义：

domain：主要是领域对象，包括枚举、常量、VO对象、服务间传递信息所需的模型等dao：对应于数据库的DO对象、DAO对象等，具体负责处理数据库的事情service：主要负责提供原子服务，包括对外部rpc服务的封装、相对原子的数据处理、dao层的操作等。 thrift服务（server impl）：thrift服务端，在基础服务的基础上，实现thrift服务。一般情况下，领域模型需要封装为thrift模型。 Thrift服务（客户端重新封装）：Thrift客户端，在thrift服务的基础上，重新封装了一层服务，一般包括：thrift模型与领域模型之间的转换、ThriftException异常转换等。 biz：主要处理各种业务流程，结合了原子性服务层的服务实现一定的目的，并处理一定的业务提供者：那些不直接面对客户端的不需要这个模块。主要负责接收外部请求并做权限管理（如验证登录）、参数校验，然后调用biz层接口完成具体的业务处理任务：用于处理定时任务和外部调度任务的模块，负责接受任务消息或者调度请求，然后调用业务层接口完成某个任务常见：主要是一些工具类（时间、MD5工具等），以及一些对象转换约定器。将模块划分为模块的目的是为了减少代码的耦合性，将相关的数据和代码抽象成更集中的方式。每当你想使用某个常量、枚举和对象时，你可以粗略地扫描一下域，知道此刻有什么，这样你就不必为同一件事编写几段代码。至于service，从原子服务的角度来看，由于service足够小，当添加新的服务时，service不需要修改，只需要添加即可。 biz层只需要添加逻辑和组合即可。服务就能达到目的，从而达到“对扩展开放，对修改封闭”的目的，降低修改代码带来的风险。

九、使用模型

处理外部数据时，尝试使用自己的业务模型。除非是特别简单的http响应，否则其他处理应该封装自己的模型。

为什么要将外部数据映射到模型中？

原因一：让读代码的人知道处理时哪些参数与你当前的业务相关，哪些参数是他应该关注的。如果没有模型，直接操作外部数据，知识就会散落在代码中各处。一旦业务发生变化，不知道增加或减少参数是否会影响之前的业务。原因二：转换为模型也是为了一开始就检查所需参数的合法性，业务最好在获取参数时直接判断。不可能经过一些流程之后突然发现参数不可用，然后中断流程。这将消耗服务性能。该转换模型也是对所有参数进行一次性合法性检查。原因三：外部数据映射到模型中，在添加或删除数据时会造成一定的约束。相比json的操作，增删改查更加随意。它既不能约束类型，也不能对对应关系强制约束。后续开发者为了省事，写了很多东西，弄得乱七八糟，无法使用。该模型必须具有商业意义。当它传递给服务时，它必须与服务具有牢固的业务关系。不要单纯为了简单而使用DO，或者使用参数相似但业务不相关的模型图来省事。对于业务绑定不强的模型，经常会出现由于业务修改，当前业务也需要一起修改的情况。减少耦合

避免超级模特。做任何业务时，只需将参数放入模型中即可。一方面，这让人们看代码时不知道哪些参数与当前业务相关。另一方面，修改者担心删除一个参数是否会影响多个业务。因此，尽量避免使用公共模型。如果参数重叠确实很高，则可以考虑模型之间有意义的继承。

多使用模型，少使用哈希图。那时，hashmap相当于一个免费模型。您可以插入任何东西并取出任何东西。使用方便，但不包含任何商业信息。业务越大，修改越多，就越不可控。每一次的修改都会带来一些隐患。