Hello，各位铁铁，今天聊一聊怎么去约束代码的统一性。
当你着手的项目随着协同人员的越来越多，始终会面临着一个问题，那就是代码的统一性，俗话说，千人千面，放在代码里，也是百家争鸣，毕竟每个人都有自己的思想，也有着自己书写代码的风格，如何让一个项目，朝着一个统一的风格前去，这个是很难的，难的不是规范的制定，而是规范的落实。
为什么要进行统一？谈到这个问题，想必各位铁铁，是最有发言权的，虽然说不统一，也能够让项目正常的运行，正常的上线，但随着而来的问题也会不断的暴露出来，比如，代码冗余，冗余到一个项目可能会有N个网络请求，N个同样功能的工具类，N个同样代码的方法等等，再比如说代码规范，以多个命名方式的存在，可能是下划线，也可能是驼峰，以及出现多个技术选型的问题，你用A技术，他用B技术，等等类似的问题，造成项目的体积越来越大，后续接手人员越来越难以入手，长此以往，项目的稳定性将大大的折扣。
代码的统一性，在项目的启动之初，就应该有一套属于的自己的技术架构以及技术选型，必须有一个主导人员的参与，前期可以大家一起商讨落实的方案，比如，技术选型，代码规范等等，所有的前期制定完之后，形成文档，这个是很重要的，不仅仅是针对当下的开发人员，更是为日后其他人更好的接手，形成一个有效的参考。代码的统一性，虽然一定程度上约束了开发人员的拓展思维，但在项目的稳定，可持续发展上，有着一定的作用，毕竟作为开发人员的我们，项目的稳定与否，直接关系自己的生存与否，铁铁们，这绝对不是危言耸听，想想看，一个随时崩溃的项目，你觉得你的处境会如何？
约束代码的统一性，无论从零开始的项目，还是已经开发中的项目，都是有必要进行实施的，简单罗列下几点。
一、架构的统一，技术选型的统一，各基础库的统一
架构，技术选型，基础库，基本上形成了一个项目的基石，在开发之初，就应该有足够的时间进行整理开发，俗话说，磨刀不误砍柴工，这些基础的前提，很有必要来细心的整理。一个项目一个架构，这个必须是前提，如果说，出现了多个架构，那么这个项目维护的成本将增加几倍，后续接入的人也耗时耗力。技术选型的统一，像网络请求，数据存储，图片加载等，一个项目保持一种模式存在即可，多种方式，势必造成代码上的冗余，后续人员的接入成本的增加。基础库的统一，比如项目中常用的工具类，Dialog，Banner等等，进行统一的抽取，统一的使用，避免出现多种情况的存在，和技术选型基本是一致的。
所有的进行统一之后，务必有一份文档存在，架构，各个技术点的使用，基础库的调用等等，尽量涵盖周全，毕竟大部分情况下这不是一个人单独开发，而是多个人协同开发，以及后续也会有人参与进来，相对于这一套架构，技术选型，基础库等，肯定有不明白，不清晰的地方，如果有一份周全的文档，那么熟悉起来就比较快了，而且可以快速的进入到开发状态，大大的提高开发效率。
下图是去年我根据现有的架构，技术选型，基础库等，书写的一份文档。
二、规范的制定
有了基础的架构，技术选型，基础库之后，也形成了一定的文档，那么进入到开发中，规范是一定要重视的，比如代码的规范，git分支管理以及提交的规范，三方依赖的规范等等，务必要坚定的执行，无规矩不成方圆，只有规范的落地，才能保证项目的统一，代码的整洁，项目的稳定与健壮。
同样的，根据以上的这些，也必须有文档的产出，口头宣讲很难达成记忆，只有文档的依据，才能不断的加深印象，文档也尽量，细致周全，涵盖面要广，规范的制定中，肯定会有遗漏，后期维护中可以不断的进行健全。
三、review机制的落实
开头就说过，规范制定特别容易，但是执行起来巨困难，毕竟协同开发的人员很多，每个人都有自己的思想，开发过程中，难免会出现很多不同的声音，各种错综复杂的代码场景，所以，必须要建立一套review机制，以每次提交还是以日单位，看自己实际情况，来不间断的针对代码进行review，发现一处，指正一处，只有这样，才能长此以往的让代码保持统一性，按照既定的规则去运行。
review这个是很有必要的，现有的规范下，你永远发现不了别人是如何骚操作的，简单举个例子，例如下图，是我之前review查出的某个问题，这些问题真的匪夷所思，铁铁们，你能察觉什么问题吗？
其实说到底，怎么去约束代码的统一性，一句话，重在执行与检查。
