谈谈规范
在多年的开发经历中，我发现不重视编程规范是普遍存在的一个问题。很多开发人员对规范的态度都是很抵触的，认为规范的条条框框是枷锁，会降低开发效率。 不仅仅是普通员工，很多公司的管理人员对于规范的重视程度也是不够的，甚至就没有制定规范的想法。 为什么会出现这种现象呢，我想每个人都会有自己的角度，大多数原因可能是因为项目周期紧张，没有时间制定规范，或是单纯的认为规范会影响开发效率。 上面的原因是客观存在的，所以大家对于不制定规范也没有太大的心智负担。今天我想就这个现象谈谈我对规范的认识。 规范一般有两种，一种是项目规范一种是编程规范。 关于项目规范 我在刚开始入行的时候，公司虽然也没有自己的规范，但是带我的前辈，给了我一份谷歌的开发规范，让我学习，代码的书写格式是怎么样的，什么时候应该换行，应该怎么避免写嵌套 if… 这让我对代码规范有了一个最基本的认识。 代码需要书写的简洁，易读。代码规范有点像写文章时的字体工整程度，越遵守代码规范，字体就越工整。你可以想象就算同样的一篇文章，字体工整和字体潦草给阅读人的感受是完全不同的。 后来我在一家公司做管理，刚到公司时也没有自己的规范，每个人的代码风格，变量命名，项目组织的习惯各有不同，导致项目的风格多样，这给我们带来了一些问题。 维护成本高 当我们维护其他同事写的代码的话，需要从头开始阅读一遍代码，才能了解问题具体出在哪。如果我们有规范就不需要通读所有代码，仅需依据规范出问题代码的大体位置。 代码复用差 当我们有一些通用业务需要封装时，如果没有规范，就需要考虑所有的代码风格，甚至要做一些额外的兼容才能把组件封装完成，有了规范我们完全就可以避免这类问题。 项目对接慢 由于没有规范，每次公司来了新同事，我们并没有很完善的文档给到他。导致新同事上手项目比较困难，中间还要不断地去询问老同事，才能对代码有一个相对比较完善的理解。 这无疑增加了很多的摩擦成本，且团队越大，这种摩擦成本就会越高。就像我们都说中文，又各自有自己的方言，大家需要了解每个人的方言体系，才能更好的深入交流。 我们需要“普通话”这样一个统一的说话规范，来降低我们团队内部的摩擦成本。 建立规范 为了解决上述问题，我们结合自身团队的特点，参考了他人的规范制定出了我们自己规范的初版。 初版规范经过内部评审和修改后，我们形成了自己的规范文档。 后续我们在实践的过程中遇到了一些规范上的不足，也进一步对规范做了补充，使规范在原有的基础上不断的迭代和优化。 这样一套规范建立后，使我们每一步都是在之前的基础之上，而不是每一次都是从 0 开始。这让我们可以不断的阶梯向上。 如何让规范落地 规范的制定后就需要考虑规范落地问题，如何让团队更好的遵守规范。 首先需要让团队认识到规范对我们团队合作是有益的。做好心理建设，消除心理的抵制情绪。 把规范塑造成开发文档，让团队养成经常查阅的习惯，对规范有疑惑就去规范文档找答案。 利用工具降低规范的执行难度，像一些代码风格的问题可以通过 IDE 代码格式化解决，不用团队开发者额外注意。 使用静态代码分析工具检测代码是否符合规范，如果使用 CI/CD 可以把这一步集成到 CI/CD 中，让不符合规范的代码，无法提交到线上环境。 关于编程规范 编程规范包括：设计模式，设计原则，编程范式，最佳实践等等。这类规范一般是行业发展多年，一些经验丰富的前辈总结的一些开发工作的规范。 因为这类规范通常是前辈们在长期实践中总结出来的。遵守这类规范能让我们更容易开发出稳定的程序，少走弯路。 这类规范一般都具有普遍性，对语言没有任何的限制，因此一旦你熟练的掌握，你用任何语言开发的程序都会有更好的稳定性，更少 Bug 、更容易维护和扩展。 我发现有些同学会遇到一些奇奇怪怪的问题，或者一段时间后，程序出现了运行瓶颈。有不少是因为没有遵守某些编程规范引发的问题。 有时他们不遵守编程规范，并非不愿意，而是因为他们不了解某些规范。因此对于编程规范，要像探寻宝藏一般，时常去探索一下。不断地完善和补充自己对编程规范的理解。 总结 规范短期看可能会觉得有点浪费时间，影响开发效率，从长期看，却未必如此，那些减少的 Bug, 复用的代码，以及与同事之间协作效率的提升，足以弥补开发时的损耗。 牛顿说：我之所以比现别人看的远，是因为我站在巨人的肩上。 运用前人的智慧和经验，能让我们做事情更加的顺利。要站在前人的肩膀上，哪怕你觉得这个人不够高，也比自己站在平地上看的更远。