1、3招，增强别人眼中你的代码能力

3招，增强别人眼中你的代码能力

阅读引导：

1、本文适合初级程序员，需要提升自己的代码水平的人阅读。

2、代码体现了个人的思维逻辑，是程序员的门面，是你的领导、同事、下属对你的最重要印象。

3、为自己工作，为自己的系统工作，做自己的老板，形成正循环：打磨当前工作的核心关键能力——>高效能工作——>更多时间打磨自己的系统——>更高效能工作——>打磨下个层次工作的核心关键能力……

4、核心竞争力，是指你拥有的（独特的）知识经验组合，经过你思维逻辑的组织梳理，在实践中产生无可替代的价值。打造自己的TMS系统（T：专业技术；M：沟通管理、S：行业解决方案），利用复利效应，让系统为自己工作。

"顾客就是上帝"这句话几乎成了大家耳熟能详的金科玉律，但是对于程序员来说，你的上帝是谁？

华为任正非早就有非常清楚的阐述，他在《致新员工书》中说：“服务的涵义是很广的，总的是为用户服务，但具体来讲，下一道工序就是用户，就是您的“上帝””。

对于程序员来讲，我们写的代码，是给人看的，仅仅从代码层面来说，我们的上帝是谁？

首先当然是自己。

你写的代码，在时隔半年后，还能快速翻看就回忆起来所有细节么？

还是说，只是为了完成任务而堆积性开发的代码，半年后再拿出来，自己也不知道具体细节了？

其次是领导、同事。

你的代码给别人留下了什么印象？

逻辑清晰，结构良好，此人开发水平很牛，做工作游刃有余？

还是乱糟糟的一堆垃圾，让人无从下手？

第三是后续接手方。

不出意外的话，你写的代码会很快交接给别人维护，你猜接手人看到你写的代码，会怎么说？

心里会不会骂你？

对于程序员来说，你的代码，就是你的脸面，为了让你的脸好看一些，初步可以从下面三个小手段入手，快速初步解决代码脸面问题。

1 自顶向下拆分功能逻辑

面向接口编程，是代码开发过程中的基本原则，但是，有许多人是把接口理解成了狭隘的语法层面的“接口”。

这里的“接口”，其实可以用另外一个词语表述：抽象。

而语法层面上的接口、抽象类等，不过都是抽象的某一种实现而已。

里面的水很深，这里不展开讲，本文仅仅关注在一个类的开发层面，如何面向接口编程？

或者对于这个问题换一种表述：已知有一个类要提供某个服务，第一步要做什么？

主方法逻辑拆分多个方法，应用单一职责原则，一个方法只做一件事

很多新人，迫不及待的创建了Class之后，马上在主方法里面开始堆叠代码，压根没有进行思考，造成的后果就是：一个类里面一个或者几个大方法，每个方法里面几百行……

思考或者说充分的思考，在类的开发过程中，是指不仅仅是知道要做什么，更要充分拆分功能，对代码有方法层级的逻辑组织。

参考斯坦福公开课《编程方法学》。

举个简单例子，假设有一个付款功能需要你实现，应该按照怎么个步骤来开发？

1. 首先，使用注释，划分主方法中的处理步骤

   public Class Service {
       public void pay(Pay pay) {
           1、业务越权等校验，例如操作人是否有对付款账号的操作权限等
           2、付款
           3、账务通知         
       }
   }
   

2. 其次，将操作步骤转换为方法名

   public Class Service {
       public void pay(Pay pay) {
           //1、业务越权等校验，例如操作人是否有对付款账号的操作权限等
           accessVerify();
           
           //2、付款
           pay();        
           
           //3、通知         
           notify();
       }
   }
   

3. 细化每个方法需要的参数

   public Class Service {
       public void pay(Pay pay) {
           //1、业务越权等校验，例如操作人是否有对付款账号的操作权限等
           accessVerify(int account, int tellerId);
           
           //2、付款
          boolean success = pay(BigDecimal amount, int payAccount, int recieveAccount);        
           
           //3、通知第三方付款结果         
           notify(success);
       }
   }
   

4. 使用IDE自带的代码辅助功能，自动生成方法结构

5. 最后填充实现方法细节

这个例子非常简单，但是很清楚的表明了类开发的思路，那就是自顶向下的设计拆分功能模块，然后再去填充细节。

在开发时，千万不要一拿到需求就去动手。

三思而后行。

程序员应该是设计师，不是真的“搬砖民工”，主要工作是脑力劳动，而不是编码体力劳动。

甚至可以断言，如果工作中因为编码工作而劳心劳力，那就说明两个问题：你的编码技能掌握不牢固，或者，大概率是你没有深入思考设计就匆匆动手。

2 命名：做了什么，而不是怎么做

如果类的主方法，已经进行了模块化拆分，细分到了方法。那么就可以达到：只读主方法，通过里面的方法名，就知道这个类做了些什么。

再下一步，就是对语言基础元素的命名，这些元素的命名，决定了代码的可读性。

命名，只有一个目标：自表达，就是说，看它的名字就能**“见名知意”**。

类名，巧用前缀、后缀，形成统一规范

类的命名，建议大家去参考《阿里巴巴Java开发手册》，或者各自公司项目团队的规范。

方法名，描述做了什么（what），而不是如何做的（how）

方法作为某个功能组块的最小组织结构，命名非常重要。

需要强调的一点就是，方法名，一定是描述了这个功能做了什么，而不是如何做的。

一些新手的代码中，经常有类似如下的命名：

dealWithCode1And2(……)

这种词语，尤其是“deal”，可以理解为处理，含义太模糊了，类似的还有do、execute等等。

过一段时间，根本不知道做了什么。没有任何的业务含义或者功能描述含义。

这个方法的本意，是做状态处理，根据状态做检查。

那么，这个方法命名还有一个问题，就是之后扩展了状态字典之后，方法名就更不适用了。

如果改名为如下，就能较好的体现做了什么。

checkPayStatus(……)

方法的命名，有一个简单的规则：具体动词+业务名词 or 功能名词

变量名，就近原则，名词

如果有了面向对象开发经验的人，有了对模块化、封装特性的了解之后，再去看类似C语言的代码，就会非常的不爽。

例如，很多新手在类开头，先声明一大堆的变量，后面再去使用。

变量命名有一个就近原则，就是说，一个变量只有使用的时候才去声明。

这样方便对一段代码进行模块化组织，或许后续就会抽成独立的方法。

关于其它的变量命名规范，可以去看文末推荐的一些书籍，里面有更具体的说明。

建议做命名主题阅读。

注释，是在方法、变量命名自表达之后，仍然无法充分的体现相关信息情况下，才去维护。

这里另外提一下注释。

除非有非常强的管控措施，注释经过多年的积累之后，很少有精确的。

后来人还是需要看代码。

所以，注释，还是作为能自表达的名称的补充手段。

记录一些特殊的业务处理规则等事项。

3 代码静态扫描

经过前面两个小手段，你的代码已经可堪一看。

但是，实际工作中，每个类提供的服务、方法，都是比较复杂的。

很有可能，对于一些方法、变量的处理有一些疏忽。

对此，可以使用静态代码扫描工具，继承到IDE中，对你的代码进行扫描。

通过静态代码扫描，可以消灭代码中非常粗显的失误，基础的错误。

目前比较出名的静态代码扫描工具有FindBugs、Alibaba Java Code Guidelines等插件。

4 更多

实际上，类的开发，只是非常初级的一方面。这3招，能让代码逻辑清晰，反向促进你梳理自己的思维逻辑。

为了养成良好的代码风格，建议初级程序员去看一下斯坦福公开课教程，例如《抽象编程》、《编程范式》、《编程方法学》等。

再就是《Java编程思想》以及《重构》、《代码之美》《Clean Code》等方面书籍。

更多文章，请关注公众号：架构突围