部分人看到这个题目时，直接的反应是QA关心代码质量干嘛，能看懂代码吗？怎么给dev feedback？
如果还有人持这样的观点后，那么我只能说too young too simple。
首先我们得谈谈什么是代码质量？
创建优秀的代码涉及到正确性、可维护性甚至优美性。
正确性，最起码你的代码实现的业务逻辑是正确的。
可维护性，公司中其他的小伙伴能看看懂你的代码逻辑，便于修改代码。
优美性，符合各种代码规范，其他人看到代码后惊为天人。
但是要做到以上几点绝非易事，首先你得有高超的编程能力，其次你对前端或后端的代码规范有深刻的理解，但是能有这样能力的人又有多少呢？
那么项目的质量与客户的需求才是项目生存下去的关键。
所以怎么才能改进项目代码的质量？我们先看看业界巨头公司都是如何做的？
microsoft怎么做？
microsoft
开发过程中改进代码质量
google 又是怎么做？
google
· 代码审查。在你提交任何代码改动之前，你得找去代码“主人”签字确认。为了实现，评审者（被鼓励去）建议大修代码，而不是让它成为根本没有经过思考的“图章”代码。
· 按语言可读性要求坚持代码风格指南（请参阅这里）。除了让我们代码有统一的外观（所以我们能快速识别方法、变了等），我们的风格指南禁止了一些复杂、混乱、易出错的 C++ 特性（比如：class 类型的静态和全局变量）。
· 整个团队都致力改进我们代码库的质量，维护我们的核心库，不断做出更好的工具。
· 一个活跃的“code health”课题组。
· 发布软件时，不对外部期限承担责任。一般而言，这让我们可以正确做事，而非为了期限内完成任务把乱七八糟的代码拼凑起来。
· “Fix it.” 例如，一个工程师或许说，“我认为我们真应该别再用过时的 Cruft Map 类（class）了。我打算在 1 月 20 日组织一次 Fix it。” 当 1 月 20 日来临时，大家应当暂停其正常运作，把他们代码中的 Cruft Maps 都换掉。在 1 月 21 日，Google 就永远和 Cruft Map 说拜拜了！不过最近，核心库团队已经很优秀了，貌似没有啥东西可再值得类似的 fix it 了。
· 测试文化。单元测试覆盖率可能接近 100%，我们有持续构建/整合/测试，还有知名的 “Testing on the Toilet” (请参见Google Testing Blog)
