您认为程序员很累吗？实际上，作为一名程序员，技术对个人很重要，但是对于工作，编码习惯比技术更重要。您的大多数访谈不需要在工作中使用。您编写的代码很差，代码冗余是重复的，并且许多无关的代码和业务代码都被搅拌在一起，这使您厌倦了处理各种问题。
良好的编码习惯和各种开源工具可以提高我们的生产效率，并降低许多不必要的加班时间。衡量开发人员的输出，质量和效率，组件与组件越多。我认为，有以下几点。
首先，我建议安装ALI插件：Alibaba-Java编码Guidelines，它可以帮助您纠正许多不健康的写作方法
概念：诸如DTO，实体等的业务对象。
关于对象类的后缀，行业没有硬化。只要知之甚少，相同的项目规格才是统一的。例如，某些项目称为实体，有些是模型。以下是我个人认为的解决方案：
关于CRUD操作的完整命名方法与DTO相关：{business Word} {action} {suppix} .java .java
示例：教师，老师
与示例相反：ClassCoursedto（无法从命名中获得业务场景）
参数的数量应在4之内控制。如果不是99％，将来将没有参数。请构建DTO。像多条件查询方法一样，您必须构建一个对象。
此外，请控制代码的长度。如果您太长，请学习更改跑步。原则是滚动条无法出现。例如：
类的代码和方法不应太多。如果您可以预见一堂课将有很多方法，则应根据单个设计原则进行分配，例如教师提供教师信息，教师秩序，教师数据同步等等。服务完成所有职责。在文件数量超过数千行之后，维护成本将逐渐变得更高。
一种方法的数量不应太多。根据Ali的规范，应从80行分开一种方法。
不要在不使用尝试捕获的情况下使用它。如果您有异常，请不要害怕隐藏它。只需将其提供给全球异常处理器即可。
原因：商业代码不应单独捕获异常，不要关心处理内容，也不应将其交给全球处理器来处理它。InsprumentRecords，可以通过代码复制这一点。更重要的是，代码是美丽的，更可读的。
例如，我想在出现异常时处理特殊待遇，例如发送电子邮件。如果使用了TryCatch，是我想编写很多重复的代码吗？即使您将其封装到一种方法中，也必须在许多捕获中调用它，这根本不是优雅。
每个人都了解这一点，只要您在没有评论的情况下维护代码，您就会了解此事的重要性。
这里有几个建议
定义服务层时有两种常规方法：
思考1：在日常业务开发中，在传统的三层架构（控制器+服务+映射器）中使用服务来撰写业务，并使用不带有设计优势和使用界面的最初意图的服务+ServiceImpl。相反，它带来了一些不必要的工作量。
因此，开发业务的大多数方案无需使用界面来定义界面层。如果您不需要实施它，也不使用设计模式来直接定义实现的实现效率。
当然，也有缺点：
思考2：使用服务 + ServiceImpl。实际上，互联网上的许多开源项目主要使用Service + ServiceImpl，但我认为我们的日常业务开发并未发挥这种模型的优势，例如:::
结论引用了互联网上的文章：实际上可以说这些情况反映在界面的好处中，因此Java对界面编程有建议。但是，是否返回服务层必须具有接口？这不一定，因为在最终分析中，另外一个接口只是一个接口，只是接口，只是接口，只是接口只是唯一的界面。在某些情况下，它是可扩展性和优势，但是是否方便接口将使用。在不确定的情况下，我们可能不必为“五月”付款。只需写更多的代码行。未来的“麻烦”
因此，这里给出的建议是基于实际情况。
我相信每个人都知道hutool的人造艺术。建议在编写工具时查看此文档。
但是，如果您遇到它，例如，当您执行顺序学科时，您会发现Collutil不会将两个清单的笛卡尔积聚。请创建一个新的ExtCollutil并继承IT.custom方法。
PS：实际上，公司应该拥有自己的工具项目。原则上，开发人员不能在各自的项目中秘密撰写UTIL。如果您需要向专业工具项目提及PR，则可以有效地减少重复轮子的时间。
伦波克相信每个人都会使用它，但是除@data外，还有更多优雅的用法
合理的代码结构可以有效地降低代码的维护成本。通常，常规项目中通常有两种类型的存款想法。
首先了解这两个是什么
By-Tech使用文件类型作为顶级软件包，其次是业务
BY-BIZ将业务用作顶级袋子，然后是文件类型进行分割
如何在我以前的项目中选择第二个，原因如下：
作者在文章“谈论DDD应用程序的代码结构”中写道：
根据业务分包的想法在互联网上具有绝对优势
因此，建议选择一个方案二。