漫谈代码规范对开发组织的重要性.docxVIP

漫谈代码规范对开发组织的重要性 2021-08-08 某项目程序员A由于xxx缘由，写了一行烂代码（如图1一行烂代码），项目千辛万苦熬到交接。B接手项目，添加功能，修改代码；然后C连续维护……?直到某一天X接手这个项目，项目已经很难维护了，成本飙升，甚至有些新的功能已经无法加入，为此不得不重构项目，投入大量人力回归测试，如“图2 擂鼓击花，看谁倒霉”。 一个没有代码规范的项目，就算不换人，过些时间作者本人也不肯定记得当时程序的意义，尤其如图1示例中的变量n1、ct、cd谁晓得存储的是什么内容呢？更何况现实情况是软件项目换人率很高，如软件中心接受自有人员加外员的混合模式开发，换人是必定。代码规范落实不好，项目维护一两年就会变成灾难，成本飙升、效率下降、没人情愿接手。因而软件组织很注重代码规范（组织也会有其它规范建设），但为什么代码规范落地过程中并不如意呢？我调查一些项目，以及一些软件开发人员，次要有下面一些缘由，导致代码规范落实不到位： 1. ??????代码规范比较单调难以记忆，个人都是按本人理解做。尤其是对变量、方法等命名上，有人宠爱用下划线、有人宠爱用大小写区分、至于缩写就更是因人而异。一次，数据库中重要的备份表被删除，缘由是这个维护项目组宠爱用人名缩写做备份后缀。某新人来了以后，给“营口局”做备份用了“YKJ”后缀，这个后缀恰好是另一个同事名字缩写，那个同事分析完数据，就自然给删除了。 2.???????通过培训可以加强组员对代码规范的生疏，只是中心自有人员不足，外员流淌较大，规范培训效果大打折扣。而且程序员在成长过程中，渐渐会构成本人的编程习惯，这种习惯很难通过一两次培训就转变。 3.???????有些程序员不情愿转变本人的习惯，短期内也不是问题，由于每个人都能完成本人的工作。尤其一些技术较好的“大牛”，会很好的完成本人的工作。很多时候会认为本人的习惯更“优秀”而不情愿转变。对于一个组织，假如有岗位变动，那么这个“大牛”的工作往往需要几个人才能接下来。 4. ??????迫于工期压力，放宽标准。有时的确是项目进度要求太紧，这时自然不自然的就会从质量上找时间，而代码规范属于内部质量范畴，一般客户感知不到。至于将来维护麻烦，那也不肯定落到本人头上。 5. ??????有的人觉得本人可以完成高难度的算法，就认为本人力量很强，追求共性。殊不知简单的算法的确可以体现你个人的规律力量，但是绝不代表你的开发水平，用大炮打蚊子，就算打中，又能怎样？宰敌一千，自损八百，比之羽扇纶巾，强虏灰飞烟灭，差距就不是一点半点了。 6. ??????规范不好落实，投入、产出实在不成比例。往往花了大量的力气培训、考试、抽查，但是问题照旧不断。在权衡代码规范与工期之后选择了放宽标准。 7. ??????假如原项目比较烂，在软件后续维护过程中，很少有人因程序不符合代码规范维护程序，后续的更改基本都是将计就计，不断打补丁。这个项目也沿着烂代码之路不断循环如图3，最终走向死亡，项目的一坨烂代码带坏了一群人。 一个产品对于一个组织，就是这个组织的生存根本，组织对待产品就像农夫对待庄稼一样，要从头担任到尾，没有农夫情愿看到本人的庄稼死掉，也没有组织情愿本人的产品死掉。因而，很多组织都有本人的代码规范，并且花大力气培训本人的员工，努力保持人员稳定。可是人员流淌难免，如何落实代码规范？如何保持项目持续进展？ 我认为除了培训、考试、抽查等传统方法外，还应当添加自动化的代码规范协助落实工具，代码规范检查工具，这样才能在提高效率的同时降低成本。代码规范落实工具分四个阶段介入开发过程：首先通过传统方式培训人员，讲解代码规范的作用，通常业内认为代码规范有如下作用： 1.???????规范的代码可以促进团队合作 假如没有统一的代码规范，每个人的代码风格悬殊。即便是分工格外明晰的，等到要整合代码的时候也有够头疼的了。大多数情况下，并非程序中有简单的算法或是简单的规律，而是去读别人的代码实在是一件苦痛的事情。统一的风格使得代码可读性大大提高了，人们看到任何一段代码都会觉得特别生疏。明显的，规范的代码在团队的合作开发中是格外无益而且必要的。 2.???????规范的代码可以降低程序后续维护成本 随着我们项目阅历的累积，会越来越注重后期维护的成本。而开发过程中的代码质量直接影响着维护的成本。在第一点中提到，规范的代码提高了程序的可读性，可读性高的代码维护成本必定会大大降低。?但是，维护工作不只仅是读懂原有代码，而是需要在原有代码基础上修改。 3.???????规范的代码可以削减BUG处理 大多代码是绘制人机交互界面、描述业务流程。在规范的开发中，BUG不但可以有效削减，查找BUG也变得轻而易举。?规范不是对开发的制约，而的确是有助于提高开发效率的。 4.???????规范