这里不成系统，但是每个小点都值得细细思考
静态代码检查
前段时间，阿里发表了自己的 java 代码规范，大家各种赞。其实N 多年前，Google 就把自己使用的 Java，C++，Python 的代码规范发布了出来，并有相应的工具可以按照规范对代码进行扫描、检查是否相应的规范。
静态代码检查的难点是在于梳理出一个适合自己公司的规范，且有相应的工具按照梳理出来的规范进行扫描，针对违反规范的地方要及时纠正，并且将这一切持之以恒坚持下去。事前预防的成本远远低于事后补救的成本，越早做越好。
代码注释
这对这一点上一篇也已经讲了很多。注释是用来解释一段代码的意图，而不是解释代码的行为。代码的行为可以通过阅读代码来了解，但是这段代码的目的却超出了代码行为所能表达的，所以需要通过注释来告诉阅读代码的人。
注释写到什么程度，这个没统一的标准。现在很多版本管理工具都可以与问题跟踪系统集成。当提交代码的时候关联一个问题跟踪系统的 ID，就可以和问题跟踪系统集成到一起。通过 ID 关联的 bug/issue/requirement 就可以到问题跟踪系统里查看为什么要做这样的修改，这段修改是为了什么；同样直接通过 bug/issue/requirement 关联的代码文件，就可以了解到，这个 bug/issue/requirement 涉及到的代码是什么，改动范围等。
但不要强制研发每次提交代码的时候都要写大段大段、必须符合某种复杂规范的注释，尤其是那种必须要符合某种格式、要填写的内容有很多的。这种要求真的是反人类的。配置管理员如果要加这种限制，先要把存储自己代码或者文档的库加上，自己先试用一段时间后，回过头来看看自己写了哪些注释、自己是否觉得有必要再说。八股文式要求的注释相当影响研发效率。
单元测试
虽然未必做到 TDD，但是重点模块或者复杂逻辑做到覆盖还是必须的。因为我们任何一个人都不想看到改动一点点代码，结果系统就崩了，每次上线都担惊受怕、胆战心惊。
记得每次改动代码的时候，要提交相应的单元测试。测试代码要和相应的业务代码一起提交。和有的小伙伴交流的时候，居然听说研发人员写业务代码，测试人员帮写单元测试。这样的做法深深雷的我里焦外嫩。现在都讲究 dogfooding，简单说就是自己做的饭自己先要吃，自己的代码自己负责。研发写的代码却要让测试人员来补单元测试，这种做法也真是没谁了。
开源软件 or 商业软件
有钱购买商业软件绝对是明智之选，尤其是涉及很专业的行业软件或者购买商业软件可节省下来的资源可以给你带来更大利润的时候。但是国内人力成本低，所以很多公司愿意顾一些廉价劳动力来重复发明轮子。有实力的公司还可以真么搞，至少自己搞好了还可以卖出去，自己赚钱；没实力的公司还是要把资源聚焦到你能挣钱的主营业务上去。
业界标准 or 艺术行为
选择行业标准大多数情况下都是对的。因为这样：
- 风险低。因为很多人都已经使用了，省去了大量方案验证的时间
- 容器和其他系统集成
- 很多坑别人已经踩过并且填上了。自己容易获取支持和帮助。
我十分不理解偌大的一个公司连账号都无法打通。登录内网主页一个账号，登录内部通讯软件一个账号，财务报销一个，请假一个，定会议室一个。。。。关键是。。。关键是还要求每个月换一次密码。。。想起来都头疼。
代码审查
所有人都要树立一个理念：提交代码不是一件很随意的事情。
提交一行带有 bug 的代码带来的损失要比严控质量花去的资源多的多。在自己的工作空间可以随意折腾，但是一旦提交到系统，就要经过严格的自测、同行审查、系统扫描与自动验证。可以拒绝不符合公司的代码签入或者合并到关键分支。
开源许可
虽然国内很多企业对开源许可都嗤之以鼻，但是如果真的想做大，还是要认真对待这一问题。使用开源代码之前，请先看一下代码开源所使用的开源许可。小问题可能引出大毛病。也许公司小的时候没人揪你辫子，公司大了就不一定了。
枪版软件
软件分正版与盗版。作为软件公司的员工，我还是推荐大家购买正版软件。如果无力承担，可以选择一些类似的开源软件。虽然某些细节可能不如商业软件好，但主要功能一般都在的。A公司破解 B 公司的软件；B 公司逆向 A 公司的软件。都是同行，何必互相伤害呢？
小结
静态代码检查、代码注释、单元测试、开源软件、业界标准、代码审查、开源许可、枪版软件。。。很多版本管理中涉及到的点都简单的提及了一下，抛砖引玉了。
网友评论