代码写好后怎么才能让别人,代码写得再好有什么用
现阶段写了很多代码，但大多数代码的质量不高。 一方面没有编程经验，在编写代码时没有充分考虑，另一方面，需求的变化也可能会改变代码。 虽然这些都会影响代码的质量，但是代码的质量会影响到产品的性能和好坏，接下来笔者将分享一些优秀的代码标准。
优秀的代码，就像一个写作技巧高超的人写的书，主旨贯穿全文，通俗易懂，章节划分明确，要想写出好的代码，需要满足以下标准：
1 .明确性------代码可以不言自明。
2 .可读性------使其他开发人员能够理解。
3 .简洁性------减少不必要的冗余。
4 .效率------加快代码执行速度。
5 .可维护性------易于修改升级。
本文详细阐述了优秀代码的五个标准和实例的运用，作为自己学习的总结，希望对大家有所帮助。
代码标准1 明确性
明确性质。质量较好的代码，逻辑性相对比较的清晰，bug难以隐藏。知道你写的每个代码是做什么用的。 有目的地编写程序，使整个程序具有逻辑性，在命名某些方法和属性时，尽量给出易懂的铃名。 方法名称采用动名词组合，从而提高可读性。
2 可读性
可读性，不仅要考虑到你，还要在让其他开发、测试和运维人员能够对所写的代码一目了然，尽可能的减少或不写注释。动手之前考虑，不要写自己不能理解的代码。 那只会加速系统的腐败。 作为程序员，你需要思考和理解自己写的代码，组织代码以提高简洁性。 好的代码本身就是最好的说明文件。
3 简洁性
代码中的类和方法的长度必须相对较短。简短的代码活的更长久，没有哪个程序员不喜欢短代码。 另外，产品的问题也比较少。
Grady Booch说：简洁的代码简单直接； 简洁的代码读起来像写得很好的散文； 简洁的代码并不掩饰设计者的意图，它有少量抽象清晰的控制线； 你会发现代码的简单性有多重要。
4 效率性
效率从一开始就要考虑程序的性能，不要期待开发结束后会有一些迅速的调整。在满足正确性、明确性、可读性等质量因素的前提下，设法提高程序的效率，程序运行时要加快代码执行速度，应以提高程序全局效率为主，提高局部效率为辅。
5 维护性
维护性是指在系统发生故障后，对修正、变更、改善进行故障排除时的难度。维护性实际上也是对系统性能的一种不可缺少的评价体系。你写的代码维护性相对较高，你和别人修改起来比较容易，而不是牵一发而动全身。
实例分析沈阳数畅联软件技术有限公司要求在编写代码时，都可以自行注释代码。 也就是说，在代码中没有明文注释说明，通过统一代码的命名规范保障（如：方法名称动名词共同组合）代码的可读性。代码的逻辑复杂，需要注释说明的情况下，要求以文档的形式进行记录。 以下介绍基础的代码规格。
1 拆分规范
工程拆分
正常的开发项目可能会被分割成两个以上的项目。 其中，caslogin项目包含在portal_wcm中。
为什么我们要创造和开发新的项目呢？ 答案很明确。 这样我们就不用担心影响主工序的代码，也不用担心影响别人的代码。 虽然可以对自己负责的模块进行有效的控制和管理，但是一个项目可以分为多个模块。 模块一般按功能划分子集，便于并行开发、单元测试和代码管理。 也就是说，划分模块是为了便于管理和维护，以mdm为例。
在mdm项目中，功能分为八个模块。 从图中可以看出，按功能划分模块可以提供以下好处：
1 .功能模块相对完全独立，逻辑性清晰，可读性强。
2 .多人合作开发分工更加明确，开发速度快，同时软件质量高。
3 .提高模块公共接口，可以有效利用可以复用的代码。
4 .可维护性强，修改一处代码避免牵扯很多模块，方便控制。
代码拆分
在一些方法中，方法主体可能太长。 一般来说，用高效的方法，方法主体不会太长。 太长的方法主体分两种方法调用其提取。 此外，如果禁止修饰符在private中公开，则不仅可以分隔业务逻辑，还可以使代码更容易阅读和美化。 在下面的示例中，如果不划分方法主体，代码将变得庞大，难以阅读。
很清晰明了的阅读：
2 命名规范
>>>>包名规范
命名在一个项目工程中也影响着代码的好坏，无论是包名、类名、方法名、变量名,命名的时候都应该考虑周全，实际开发过程中，我们的工程通常都会进行分包，其中一个功能模块可能是一个或多个包组成的，这也就要求我们对包进行划分同时还要规范命名，其中工程的项目的包名应以com.agileai.XXX来命名，其中项目名称和包名均为小写，例如：
>>>>类名规范
一个模块中包含了数据包和系统包，而在包中又包含很多类，类中有很多方法，方法中包含着变量，所有命名均符合驼峰命名法，下面列举出正确的类名命名方式：
图中我们可以看出，所有类的命名格式都应该是名词+动词或者名词，这是类名的命名方式，写好优质代码首先还是从最基础的命名开始。
>>>>方法名规范
任意打开一个类中查看方法名称其命名方式均为动词+名词或者是动词形式，方法名称具有明确的业务语义。
>>>>变量名规范
在日常编写过程中，无论是公共变量也好，方法中定义的变量也好，其命名均为名词，从上图中可以看出命名的好坏也影响着代码的质量。
3 格式规范
在重构时修改一些写死的全局变量，只供应一个方法使用，而避免其它方法不能调用的情况。下面为对接口的提升调用，接口提升后被其它包调用从而实现service的复用：
图中我们可以看出接口文件被提升到cxmodule包中，一般来说接口提升后都需要修改相关文件的导包路径。
>>>>DP代码规范
常见的循环中也会经常看到以下问题代码：
该循环会在循环体中不断的新建对象，正确的写法应该是：
这样写的好处能够优化内存，使内存中只有一个object在引用，有效节约了内存的使用率，从上可以看出，在我们平时编写代码时，一定要仔细，有时候看似不起眼的操作，却能起到很大的优化效果。还有常见的传参问题，我们在Handler中扩展的方法业务性相对来说比较强，所以在传参的时候需要传入明确的参数，而不是采用param来传值，错误示范：
正确示范：
其中查询方法的入参必须写清楚参数名称，命名也很重要，一般来说get查单条，find查多条，这些基础的知识点都是我们需要掌握的，规范的代码能够方便后续维护。
>>>>ESB代码规范
1 在ESB工程项目中，会根据系统或是业务功能分为多个工程，其名称都具有业务语义，例如：
2 在工程中中有很多流程，其流程名称也应该清晰明了具有业务语义，例如ERP系统的岗位同步流程：
3 Timer流程的使用应该是Timer流程定时调用Http流程，而不是Timer流程直接调用，具体方法流程：
错误实例：
正确实例：
4 创建流程时，每个流程节点都要简述其用途，全局变量的命名也要规范：
>>>> Portal配置规范
1 在新增功能菜单时，需要根据业务语义来填写编码，其中以“-”做为分隔：
2 模板一般根据所属导航的功能分组来创建，其命名需要明确以及满足驼峰命名法：
心得总结
软件是交付给用户体验的产品，而代码则是对软件正确且详细的描述，所以代码质量关系到产品的质量。因此，保证代码质量所投入的精力是值得的也是必要的。在现阶段的我们很少能够保障代码质量，那只能在后期对代码进行检查和重构，其实最好的习惯就是我们在编程时一边写代码一边优化，当然代码质量需要满足以上几项标准，如果只是单纯地为了实现功能而去编码，并未考虑代码质量的好坏，这样是很危险的；代码是一环扣一环的，从逻辑→可读→简洁→效率→维护，这些标准都决定了代码的好坏。
从看到学再到写，在提升自己代码能力的同时，还要注意代码的质量优化，一个好的程序，是由好的代码模块组合而成的，而在我们写程序的时候就应该多加考虑和设计，这样不仅是对代码负责也是对自己负责，写好优质代码是一个程序员应尽的责任。