在本文中，我将分享我在刚开始开发新应用程序时的经验。有时这不适合您的口味。但我想分享这些让您在应用程序的整个生命周期中生活更轻松的事情。这些不是编码标准，只是可维护应用程序的提示和最佳实践。
选择评论模式
如果您与团队合作，请讨论并选择一种模式以在整个应用程序中添加注释。否则，您可能会看到各种毫无意义的评论。例如，使用日期、开发者昵称、问题编号以及标题注释中的描述。不要讲故事，只解释它的作用。
/** 20211016 RJ 1827添加获取用户的实现方法*20211019 NS 1856重构 getUsers()方法*/
当您将来增强现有功能、重构代码或调试应用程序时，这将非常有帮助。新开发人员可以轻松理解代码。
放置标题评论
标题注释对于未来的增强非常有用。您知道更改何时进行、由谁进行以及目的是什么。
选择命名模式和规则
您是否经历过这种浪费时间命名类、方法或变量的经历？一般来说，想一个名字要花太多时间。如果团队有一个模式和简单的命名规则，那就很容易了。否则，一些开发人员可能会使用长名称、无意义的名称、短名称等。它使我们的代码可读性较差。如果我们能够定义最小长度、最大长度、大小写（驼峰式大小写或蛇形大小写）以及类、方法和变量的模式，那就更好了。请看下面的例子。您需要选择最适合您的一种。
getEmployeePersonalDetails() getEmpPerDetls() empPersnlDtls() getempperdetls()
始终使用有意义的词语。
到处使用有意义的词语。它提高了代码的可读性。新的开发人员将能够非常轻松地适应和消化代码。
维护文件
这是另一件非常重要的事情。我曾在不同的公司从事过多个遗留应用程序。他们中的大多数人没有任何配置应用程序的文档。
没有人知道如何设置应用程序、使用什么证书、需要哪些库、配置更改、服务器配置……等等。有时构建和运行应用程序需要几天的时间。所以我认为文档非常重要。
设计和开发
另一件事是，大多数敏捷团队的工作方式都是这样，只需分配问题，开发人员就开始开发而无需设计。有时候到了春末，开发商的想象可能并不如BA所期望的那样。然后它又拖入另一个冲刺。您可以选择自己的模式和流程。我个人比较喜欢分几步。
创建问题分配问题创建设计批准设计发展分配给审阅
维护 git 分支
看到有些人只使用 master 分支并直接提交到 master 分支是很可怕的。不要这样做，维护多个分支并作为流程提交。例如，这不是 git 工作流程，不要误解。首先，从 master 创建一个功能分支。开发完成后，提交并合并到 dev 分支和 QA 分支。在一些公司中，它为每个问题创建分支。其中一些为每个开发人员使用一个分支。有些公司使用一些常见的分支。无论您使用哪种方法，但都不应该将其直接提交到主分支。
编写可读且有意义的代码
就我个人而言，如果可能的话，我会使用简单的方法和逻辑。如果您将非常简单的事情变得更加复杂，则会影响应用程序的可读性，有时性能也会降低。
另一件事是，始终以积极的方式编写代码，以提高可读性。你可能想知道，我见过类似下面的说法。
if(null != user.getName()){}
这完全没问题，但看起来很负面并且缺乏可读性。不要写这样的代码。让它成为一个流程，然后每个人都能明白这里发生了什么。
如果需要，请始终尝试添加单行注释。当您编写代码行时，请重新检查它们，因为您认为自己是新手。如果您无法快速理解或掌握其中的逻辑，请发表评论。
避免编写长方法
这种情况主要发生在遗留应用程序中。有些方法很长，你需要一遍又一遍地滚动才能阅读它们。试想一下，如果你要调试它会发生什么？我能理解这种痛苦，因为我知道它有多痛。不要这样做。始终尝试使用几行代码编写简单的方法。