你好 我叫Nikolai Izhikov。 在这篇文章中，我想谈一谈我们在软件开发过程中，尤其是在开源过程中遇到的一个重要的交互元素。 这是一个演练和代码审查。
在社区成员之间的文化，时间，概念和其他差异的背景下，我将就如何制作我的功能并将其合并到开源项目向导中提供
有害的建议。 这通常是一个棘手的问题，特别是对于那些刚开始使用开源软件的人。
让我们从一个小的介绍开始。 与人交流时，特别是通过聊天或通过邮件（尤其是英语）进行交流时，请切记，您收到的信息可能与预期的完全不同。 谁来读这封信是未知的。 他可以是印度教徒，英国人，也可以是一个困倦的人。 在理解特定单词方面总是会有差异的，在不涉及技术细节的情况下，我将告诉您如何将其最小化。
警告：故事包含讽刺。
给贡献者的坏提示
不要与任何人讨论新功能
如果您想实施一项新功能，请不要与任何人讨论您的修订。 有人可以在您之前进行监听！ 或者，在听完详细信息后，他们可能会告诉您您不了解某些内容-批评您的想法。 批评带来很多伤害。 也许像您这样的功能已经被讨论过了，您还需要另外一个功能……一般来说，决不告诉任何人您想做什么。 没关系
从不做技术文档
来自社区的提交者和经验丰富的人非常喜欢理解收到的补丁的代码。 因此，在任何情况下都不要做技术文档。 Wiki，Jira，邮件列表讨论-所有这些都是完全废话。 废话不适合你！
当您向[+5000，-3500]发送补丁并以“工厂方法改进和其他一些改进”的形式描述改进时，每个人都会自己弄清楚，同时也将了解您的水平。
永远不要运行测试
任何测试都是危险的，因为它们会破坏某些东西。 如果仍然设法运行测试，请不要显示其结果。 结果中的错误可能导致补丁被拒收！ 绝对不要编写新的测试。 “全部运行”将更长，CPU消耗将增加。 无论如何，优秀的开发人员编写的代码没有错误-任何有经验的同事都会查看您的补丁程序，并了解那里没有错误。
从不阅读操作方法
进入开源项目时，请不要阅读任何操作方法。 他们是为傻瓜写的，对吗？
以自己的方式设计代码。 否则，每个人将如何理解您是一个优秀的开发人员，又是具有丰富美感的多才多艺的人？
发送补丁，因为它对您来说很方便。 例如，该项目与GitHub基础架构相关联-在发送给linux内核时就按字母顺序发送它。 您甚至可以不在附件中，而可以直接在文本中。 毕竟，Linus Torvalds不会建议不好！ 如果项目采用的方式不同，那么这就是项目的问题。
随意使Public API复杂化
在开发新的Public API时，请尝试使其尽可能抽象和复杂。 任何有关API的非显而易见行为的用户问题都可以始终得到回答：“您还没有阅读手册吗？ 第42页，所有内容均写清楚！ 再读一次！” 在严肃的项目中，一切都应该很复杂。 我们有一个认真的项目吗？
不建议或谈论问题
不要与任何人协商，也不要告诉任何人开发中遇到的问题。 理解一件事更有趣。 无论如何，好的开发人员总是第一次成功，他们没有问题。 如果其他人发现了您的问题，他们将变得比您更聪明，编写代码的速度更快。 这不应该被允许。 确实，谈论一个人的问题不是惯例。
最后决定的局限性也不值得一提。 毕竟，可能要求解决方案完成。 谁在乎限制？ 当用户开始将您的产品介绍到产品中并遇到限制时，他会变得更加有趣和有趣。 他会来找你，请你完成。 到目前为止，在任何情况下都不要告诉他有关限制的信息-如果他决定不执行任何措施该怎么办？
一个非常好的评论者会找到所有内容，他会要求您提供详细信息。 绝对不要告诉他任何事情。
如有疑问，请写信给开发人员列表
本技巧是对上一个技巧的补充。 最好不仅不告诉任何人任何内容，而且主要在开发人员列表上提出任何问题。
以下是每个人都喜欢回答的问题示例。 如果您编写某种测试，请务必询问：“是否需要检查此集合的null？”。 您不必自己搞定，您可以随时在开发表中询问。 毕竟，有很多人正等着被问到这样的问题。 他们将寻求对此做出更快的反应。
“我该如何完成任务？” -另一个好问题。 在任何情况下都不要指出任何细节：任务ID就足够了。 所有需要它的人都会自己看到。
“使用哪个框架？” -也是一个很好的问题。 回答总是很有趣，而且您可以辩论。
一站式解决所有项目问题
这是我最喜欢的提示。 在一个请求中解决项目的所有问题，尤其是在企业中工作时。 在您面前的项目中只有傻瓜，他们编写的代码很差。 而且你写得很好。 因此，您只需要：
- 重构所有您不了解的现有代码；
- 在您看来，重命名所有错误命名的变量；
- 修复所有现有的javadoc注释。
通常，您可以取出和取出一些类，工厂等，进行其他转换以使代码更好。 在与您的任务无关的领域中，这看起来尤其令人印象深刻。 因此，您可以更充分地发挥自己的潜力。 为了OOP的荣耀！ 阿们！
提前请求代码审查
当您执行一项任务，然后发送代码审查请求时，该过程可能需要一段时间。 所有专家通常都很忙。 利用这个技巧：当您的任务在您看来似乎即将结束时，请提前进行审核。 毕竟，它们不会立刻出现-在您的手伸向您之前，您只需完成所有操作即可。
好吧，如果审阅者突然有时间，而任务尚未完成，那么他很不幸。 解释情况，说明天一切准备就绪。 这样，您可以加快流程（至少通过审核）并更快地合并。
厌倦了任务-放弃它
每个从事开源工作的人都有很多时间。 无需完成任何操作。 通过代码审查，收到评论。 为什么要编辑并带来合并的内容？ 做以下难题。 这就是成功的方法！ 审阅者有很多时间，下一个补丁看起来没有结果！
审稿人是你的敌人
还有什么要说的是站在你和主人之间的人呢？ 对代码的批评是对您个人的批评！ 他认为他是谁？ 在个人交流中，“炸弹”越多越好！ 否则，审阅者如何知道您在乎？ 这是发展的基本原则！
我建议在日常开发中使用此建议。 这有助于获得结果并正确执行。
给审稿人的坏建议
不要自动执行例行检查
如果您已经达到了项目级别，并且已经将修补程序发送给您，则决不要自动执行例行检查！ 花几个审核周期进行故障排除和讨论会更加有趣：
- 代码格式化；
- 变量命名
- 检查这些变量是否标记为最终变量，可以将它们标记出来；
- ...以及其他所有内容。
在任何情况下，常规检查都不应自动进行。 是的，并且测试没有结果。
直到最后，都不要透露游戏的所有规则。
要保持领先地位，您总是需要保持一对ace。 不要告诉任何人向后兼容性的需求。 最好在提交之前说一句：“在这里，根据我们的规则，必须确保向后兼容。 请更正。” 如果您已经审核了五遍，这将特别有效。 第六个人仍然可以说：“我不是专家，所以您需要等待X先生的复审，X先生将再次出庭。”
这样的评论，尤其是在审查的最后阶段，总是会增加贡献者的动力。
情绪，权威，不用了，谢谢
该技巧与最新的贡献者技巧重叠。 尽可能在情感上对请求请求发表评论。 如果未在某处检查是否为null或未使用该方式命名变量，请对您的注释添加热情。 让他们看到您的关心。
如果发生争议，请不要提出任何技术论点。 通过技术论证，可能证明您错了。 请向当局咨询-这是争执中最好的论据，您将永远获胜。
如果有人确实通过了您的审查，则永远不要说谢谢。 他们仍然想致力于开源！ 在任何情况下都不必感谢，因此它们会再次出现！
现在认真点：准备和进行代码审查时应该考虑什么？
我希望每个人都了解如何进行和通过审核？ 在这些技巧中，除了讽刺外，在实践中还会经常出现疼痛。
我将担任证据负责人，告诉您在准备和进行代码审查时您真正需要考虑的问题。 注意事项还适用于开发该功能的人员和将对其进行审查的人员。 这些仍然是同一枚硬币的两个侧面。
首先，可以达成沟通共识，其次，该项目必须向前发展。 当前，很少有产品可以单独开发。 通常这是团队合作。
使用常识
这是最重要的建议。 使用常识，它可以引导。 在我看来，这种建议适用于所有生活状况。 如果您正在做某事，请考虑这是否符合常识的简单规则？
假设...
这是关于文化的。 我去过几个大型开源社区。 我不知道这是否是俄罗斯人心态的一部分，但通常可以将一个可以被视为老板的人同时视为一个偶然掉进去的人。 相信他希望你做的不好，默认情况下对他的专业水平存有疑虑。 因此，在任何工作中至少要假设一秒钟是非常重要的：
- 审稿人（撰稿人，您的老板或同事）不是您的敌人 。 他不想你变坏。 这是一个简单的假设，但往往做不到。 我建议他做同样的事情。
- 给您写评论的人也是一位好工程师。 您当然很好，已经具备了这样的功能。 但是世界上还有许多其他优秀的工程师。 向您发送评论的人也适用于他们。
- 这个人还希望您的任务能够完成。
当他要东西时，他有某种动机。 他这样做是有原因的。 特别是如果此人不是项目的第一天。 当然有一些原因。 您可以问这个原因：为什么您需要这样做？ 为什么这里需要向后兼容？ 如果您冷静，理性地询问简单的问题并听取答案，则可以取得更大的成就。
产品将带来什么价值？
审查不仅是现成的补丁，而且还包括项目改进，更正。 实际上，代码审查是在您讨论修订版本时开始的。 此时，问问自己：产品将为产品带来什么价值？
- 会是一个新功能吗？
- 这是现有的改进吗？
- 扩展现有功能？
- 会是代码重构吗？ 这没有错。 有些对重构至关重要，但这是必要的。 您需要知道自己正在执行此操作，而不是新功能或其他功能。
- 它是否加快了流程，提高了绩效？
- 这是一个错误修复程序吗？
还有其他选择。 无论如何，开始开发某些东西以解决问题时，您应该了解将为项目增加什么价值。
为什么修订（功能）是这样的？
有很多有用的问题要问。
为什么要制作功能？ 为什么需要此功能？ 这个问题的答案很重要。
工作在哪里开始？ 在我的实践中，碰巧我被要求重做某个应用程序。 有一个应用程序A，您需要制作一个应用程序B，该应用程序所做的改动几乎相同。 我开始做这项工作，结果发现A基本上不起作用。 实际上，它是在生产中使用人机界面的地方使用的-即有人坐着并不断重新启动程序，将空指针异常从字面上修复了。 工作在哪里开始？ 在这种情况下，它将在修复程序A中使其稳定地工作，然后在编写程序B中。
全面完成的工作在哪里？ 完成的工作应该看起来如何理想？ 从一开始就要制定公式很重要。
当前阶段的终点在哪里？ 很明显，您不能马上吃掉一头大象，最好将工作分解为多个阶段。 重要的是要了解当前阶段的结束位置。 通常，项目膨胀只是由于项目范围变得无限大而没有结束。
为什么在这样的阶段精确分解功能？ 这是关于MVP的所有内容。 请也考虑一下。
现在有关公共API
关于公共API属性的文章很多。 在实施前请先阅读它。 作为一个很好的例子，我可以引用Java中的Spring JQuery框架。 也有负面的例子。 那些使用Java进行多年编程的人，从Public API EJB 2.1的角度来看，可能还记得很糟糕。 那里的功能可能不错，但是如果Public API不好，则没人能说服用户使用该产品。
公共API不仅是第三方用户的工具。 这和内部组件的API，您自己可以在它们之间重用。 公共API的重要属性：
- 简单性。
- 证据。
- 正确的默认值。 值得考虑一下，例如，如果在测试环境中创建了500个线程（例如在生产环境中）。 反之亦然，在生产环境中默认情况下有3个线程，例如在测试环境中。
- 清除错误消息。 这是许多产品的祸害。 当某些东西落入系统内部时，不清楚做错了什么。 昨天工作了，今天是空指针异常。 错误消息中还不清楚您究竟是做什么的错误以及如何解决。
- 很难犯错。 这个分数有很多建议。 编译时检查总是比运行时检查等更好。
- 日志清晰且足够。 当您编写将被重用并部署到服务器某处的代码时，这一点尤其重要。
- 监控能力。 您需要了解日志和监视也是公共API的一部分。 解析错误时，用户将看到您在监视中吐出的指标的行为。
子系统变更
在进行代码审查时，重要的是要掌握要更改的大型产品的系统和子系统的完整列表。 在企业项目中，可能尚不清楚：它是数据库模式，控制器还是演示文稿，某种报告系统，上载，下载等。
使用盒装产品时，重要的是要问自己一个问题：更改如何影响系统中的现有流程？ 有向后兼容性吗？ 它会影响性能吗？ 如果影响的话，性能如何？ 这如何影响用户体验？
标准系统流程
每个业务系统都有标准流程：启动，安装，一些操作列表。 他们现在将如何流动？ 在检查代码之前，了解这一点很重要。 您必须阅读实现这些过程的代码。 对于Ignite，这是：
- 节点启动/停止（服务器/客户端，协调器/常规）-启动，停止节点，启动服务器或客户端节点，启动协调器或普通节点
- 节点加入-就新节点/协调器/服务器/客户端而言
- 集群激活（和停用）
- 更换协调人
- 创建/删除缓存
- 持久性/ BLT / MVCC
显然，这些过程的集合很大。 重要的是要了解这种过程的存在以及它们如何改变。
角落案例
在您的业务应用程序中，可能会发生灾难恢复，初始系统初始化，节点关闭，重新启动，更新应用程序等情况。 对于Ignite，我们有以下几种极端情况：
- 更换协调员；
- 节点掉落
- 网络问题-网络消息无法到达时；
- 损坏的文件。
我们必须检查并验证所有事物是否井井有条。
良好的代码功能
所以我们到了代码。 我建议您不要偷懒并寻求它：
并发
Java在编写并发代码时有其自身的特点。 如果您有业务系统，并且那里的并发性很低，则无需考虑这些功能。 但是，通常一些同步会通过数据库。 在类似Ignite的事情中，这有点复杂。 在这里，不仅代码的功能很重要，而且其属性也很重要：
- 了解您的并发模型有多难？
- 共享数据结构-如何保证其完整性？
- 锁-什么和为什么？
- 线程-使用哪些池？ 怎么了
- 保证变更可见性-提供了什么？
在修改并发代码之前，必须先问这些问题。 显然，该列表可以持续很长时间。
性能测试。 基准测试
如果您正在开发某种系统，它具有客户端，安装程序，那么它显然可以以某种性能工作。 在当今世界，无限地增加硬件能力是不可能的。 我们需要测试和性能监控。 进行代码审查时，重要的是要了解：
- 是否完全需要性能测试？ 也许这是某种不需要性能测试的改进？
- 如有必要，哪一个？ 有许多测量技术和方法等。
- 需要在哪里测量？
- 哪些基准是指示性的？ 节点数？ 铁？ 点燃配置？ 负载的性质？
合计
总体而言，代码审查是非常有益的做法。 我希望所有开发人员（包括企业产品）都已经在家中实现了它。 如果没有，请尽快实施。 我很乐意在评论中与您讨论代码审查实践。
讲座视频：可以在这里进行演示。