今天在项目讨论中有个话题是如何提升代码质量，简单介绍一下我的观点：

1） 代码风格应该易读易懂，从这个角度来说，过于复杂的LINQ，过长的函数，复杂的判断条件，超长的三元表达式都违背了这个原则，如果代码作者在review时需要很长时间去解释某个函数，应该需要通过注释/需求文档来补充，这段解释应该形成文字。

2）  使用工具而不是靠人品保证某些基本的规则，有没有把project setting的代码分析选项打开？有没有使用最高的标准，类似下面这种简单的警告有没有顺手fix的习惯，加入代码有没有要求人review的习惯，fix defect是否添加了足够的测试用例，有没有试图在本地跑一跑Sonar检查。如果用时间紧项目复杂作为理由，这些的确都算说得过去，但也都可以挤出时间来做，不需要非得什么特定时间。（对于进入产品环境的项目，有另外的要求）

3）  任何时间，代码质量和任务进度都需要权衡，测试时间越多，自动测试用例越多，那当然是越好，但我们作为GDC，其实任务完成量也很重要。我们需要找到一个比较好的平衡点，不在测试上和UnitTest过多投入，也不是过分追求进度忽视质量，这也是我建议大家尽量多写自动UnitTest的原因，随着项目进行，这种投入产出会变得越来越值得，尤其是针对我们这种开发时间比较长的项目，否则我们只能增加手动测试时间，反而得不偿失。