如何写出高质量、易维护的代码？本文围绕工具、方法与开发者本身素质，深入讨论了高质量代码产出的最佳实践。

　

　　当您思考代码质量时，是怎么看的？

　　是一致性吗？通过代码规范和格式化程序对代码实施一套标准和最佳实践？如何确保代码在构建过程中自动化运行测试？怎么样做pull拉请求与代码审查，如何保护Master分支免受直接提交，以及如何让同事审查您的代码？

　　这些是我们都能想到的一些事情，自动化流程与手动检查，达到智能和高效。然而，这些虽然都有用，但它们只能解决一半的问题。

　　我们不能自动化一切

　　诚然，自动化对维护代码质量至关重要。使用自动化测试对语法进行静态分析应该是强制性的。但是我们可以编写所有自动化流程的代码，而不会对实际质量做任何保证。

　　代码是否遵循既定设计模式？ 它使用现有的模块，还是重复的代码？ 一切都是合理的命名的吗？ 代码是否在代码库的正确位置？ 这个改变是否会带来更广泛的，无意的影响？这个代码能够解决实际问题，能够正常工作吗？

　　自动化的流程不能为你回答这些问题。 如果您没能回答代码的这些问题，那么可能不输出高质量的代码。 这就是为什么我们要对代码有评价。

　　一个好的代码审查应该比代码更多

　　当然，代码审查应该是关于代码的，但它也应该涉及上面提出的问题，以及最终的软件产品。

　　很多开发者将代码评论敷衍了事，仅对修改提交的代码进行基本检查，只能对明显的错误发表评论（或者只是选择一个或两个，看起来很忙的样子）。

　　五分钟完成工作，这看起来不错 。

　　但是，不能解决需求的代码不是高质量代码。 在设备或浏览器中产生控制台错误或其它可见错误的代码更不是高质量代码。 这些东西不能在敷衍的代码审查中被查出来。除非实际运行，否则无法充分审查代码。

　　我认为，一个好的代码审查至少应该涉及到以下几点：

　　1、把分支拉到本地环境

　　2、建立项目（本地测试全部通过）

　　3、审查代码在目标浏览器或设备中是否运行无错

　　4、检查完成的工作是否符合产品需求

　　5、如果这些步骤中存在任一一种问题，代码被拒绝，不允许通过。不需向责任者收200块钱，更不要合并到Master主分支。

　　审查人也应该使用代码审查作为一个提问机会。如果您不明白代码，那么不应该批准这个拉请求。 不要认为作者知道的比你更多，如果没有价值，请立即说明。

　　代码审查人员对作者的代码质量负有同等的责任，这是保持质量的关键。

　　全面的代码审查对帮助确保产品质量有很大的帮助。 在打开拉取请求之前，您可以采取一些小事情一步步提高代码的质量，并减少审查所需的工作量。

　　仔细检查您自己的工作是否完整

　　其实我有一个烦人的习惯。 当完成一个任务的最后一行代码时，我的精神告诉我检查任务也同时完成了。

　　如果我想听到头脑中那种不耐烦的声音时，我会立即提出我的需求。 但是，该代码可能包含以下内容：

　　1、错误理解需求。

　　2、缺少测试用例。

　　3、存在多余的，未使用的或临时代码。

　　4、没有足够的代码注释。

　　5、某些浏览器/设备中的存在可视化错误。

　　如果你的代码中有上述情况发生，那么此代码就是不完整的。 如果这些东西中的任何一个最终到达主分支，那么就降低了项目整体的质量。

　　这里的要点是：代码质量始于代码作者。 我们不仅依靠自动化任务，还要进行代码审查，质量保证或用户验收测试来发现更多错误。

　　双重检查工作的完整性是迈向代码质量的重要一步。看起来简单的一步，也是最容易忽视的一步。

　　当你确定代码已经开发完成时，我们只能打开一个拉取请求。

　　运行本地分支做自我审查

　　其实我对有多少问题是会感到惊讶。我们可以把它当做提炼一个解决方案的机会 ，我可以在自己的代码中找到更有价值的知识。 当退后一步，冷静观察变化时，我才会看到问题和机会。

　　我们可以在审查小组成员审阅工作之前自我审阅工作并添加自己的反馈。比如可以利用这个机会在pullrequest上留下评论，将发现的问题或一些说明性的事情。

　　花时间确保您的工作完成，纠正明显的错误，或评估解决方案，将提高您的代码质量，这同时减少了代码审查所需的工作量。

　　当然，这也可以为自己少一些尴尬，我知道这对我来说是。

　　确保代码质量是每个开发者的内在要求

　　很多开发者会认为这种方法增加了开发时间。 你是对的，它的确如此，但这不是一件坏事。

　　效率是重要的，但懒散和不负责是有害的。 不负责任导致代码臃肿，产生不一致的代码库。 懒散造成技术债的积压。我们不能被动地维护代码质量。后面需要大量时间和精力来去还债。

　　在某些公司，围绕代码质量改变文化可能很难。 项目经理和产品经理通常不关心代码质量，他们希望快点上线，担忧额外的代码审核拉长项目周期，甚至软件质量过程会充耳不闻。但是，保持代码高质量不能被认为是可有可无的，它是每个开发任务的固有要求。

　　

　　作为开发者，如果我们不改变对代码质量的看法，指望其他任何人都是没用。

　　我在这儿谈到的事情都是特别突破性的，但不是硬性规定性。 并非每个团队，工作场所或项目都是一样的，上面的一些不一定全部适用。

　　我相信，开发者对代码质量的看法与实际采取的行为之间总是存在差距。 如果您也发现了，那么希望您能从本文中拿走一些东西。如果您采取了不同的方法来解决此问题，我很乐意在文底评论中看到您的建议。

　　感谢您的阅读。