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