Hello，各位铁铁，明天聊一聊怎么去束缚代码的统一性。
当你着手的我的项目随着协同人员的越来越多，始终会面临着一个问题，那就是代码的统一性，俗话说，千人千面，放在代码里，也是百家争鸣，毕竟每个人都有本人的思维，也有着本人书写代码的格调，如何让一个我的项目，朝着一个对立的格调前去，这个是很难的，难的不是标准的制订，而是标准的落实。
为什么要进行对立？谈到这个问题，想必各位铁铁，是最有发言权的，尽管说不对立，也可能让我的项目失常的运行，失常的上线，但随着而来的问题也会一直的裸露进去，比方，代码冗余，冗余到一个我的项目可能会有 N 个网络申请，N 个同样性能的工具类，N 个同样代码的办法等等，再比如说代码标准，以多个命名形式的存在，可能是下划线，也可能是驼峰，以及呈现多个技术选型的问题，你用 A 技术，他用 B 技术，等等相似的问题，造成我的项目的体积越来越大，后续接手人员越来越难以动手，长此以往，我的项目的稳定性将大大的折扣。
代码的统一性，在我的项目的启动之初，就应该有一套属于的本人的技术架构以及技术选型，必须有一个主导人员的参加，后期能够大家一起切磋落实的计划，比方，技术选型，代码标准等等，所有的后期制订完之后，造成文档，这个是很重要的，不仅仅是针对当下的开发人员，更是为日后其他人更好的接手，造成一个无效的参考。代码的统一性，尽管肯定水平上束缚了开发人员的拓展思维，但在我的项目的稳固，可继续倒退上，有着肯定的作用，毕竟作为开发人员的咱们，我的项目的稳固与否，间接关系本人的生存与否，铁铁们，这相对不是危言耸听，想想看，一个随时解体的我的项目，你感觉你的处境会如何？
束缚代码的统一性，无论从零开始的我的项目，还是曾经开发中的我的项目，都是有必要进行施行的，简略列举下几点。
一、架构的对立，技术选型的对立，各根底库的对立
架构，技术选型，根底库，基本上造成了一个我的项目的基石，在开发之初，就应该有足够的工夫进行整顿开发，俗话说，磨刀不误砍柴工，这些根底的前提，很有必要来仔细的整顿。一个我的项目一个架构，这个必须是前提，如果说，呈现了多个架构，那么这个我的项目保护的老本将减少几倍，后续接入的人也耗时耗力。技术选型的对立，像网络申请，数据存储，图片加载等，一个我的项目放弃一种模式存在即可，多种形式，势必造成代码上的冗余，后续人员的接入老本的减少。根底库的对立，比方我的项目中罕用的工具类，Dialog，Banner 等等，进行对立的抽取，对立的应用，避免出现多种状况的存在，和技术选型根本是统一的。
所有的进行对立之后，务必有一份文档存在，架构，各个技术点的应用，根底库的调用等等，尽量涵盖周全，毕竟大部分状况下这不是一个人独自开发，而是多集体协同开发，以及后续也会有人参加进来，绝对于这一套架构，技术选型，根底库等，必定有不明确，不清晰的中央，如果有一份周全的文档，那么熟悉起来就比拟快了，而且能够疾速的进入到开发状态，大大的进步开发效率。
下图是去年我依据现有的架构，技术选型，根底库等，书写的一份文档。
二、标准的制订
有了根底的架构，技术选型，根底库之后，也造成了肯定的文档，那么进入到开发中，标准是肯定要器重的，比方代码的标准，git 分支治理以及提交的标准，三方依赖的标准等等，务必要动摇的执行，无规矩不成方圆，只有标准的落地，能力保障我的项目的对立，代码的整洁，我的项目的稳固与强壮。
同样的，依据以上的这些，也必须有文档的产出，口头宣讲很难达成记忆，只有文档的根据，能力一直的加深印象，文档也尽量，粗疏周全，涵盖面要广，标准的制订中，必定会有脱漏，前期保护中能够一直的进行健全。
三、review 机制的落实
结尾就说过，标准制订特地容易，然而执行起来巨艰难，毕竟协同开发的人员很多，每个人都有本人的思维，开发过程中，难免会呈现很多不同的声音，各种盘根错节的代码场景，所以，必须要建设一套 review 机制，以每次提交还是以日单位，看本人理论状况，来不间断的针对代码进行 review，发现一处，斧正一处，只有这样，能力长此以往的让代码放弃统一性，依照既定的规定去运行。
review 这个是很有必要的，现有的标准下，你永远发现不了他人是如何骚操作的，简略举个例子，例如下图，是我之前 review 查出的某个问题，这些问题真的匪夷所思，铁铁们，你能觉察什么问题吗？
其实说到底，怎么去束缚代码的统一性，一句话，重在执行与查看。