写出好代码的底层逻辑

程序员安身立命的手艺就是写代码，可多少人知道如何才能写出好的代码呢？这几年也做过很多次的代码 CR，可好代码的标准在哪里呢？我们在做 CR 的时候，其实只是停留在代码的表面，主要是跟规范相关的点：命名、代码行数、代码写法、注释如何，这些其实都是可以用 ESLint 做规范去解决的，也很容易形成习惯。如果在这个基础上，每个人都做得不错的情况下，那到底什么是决定了代码的好坏呢？

在想这个问题之前，我们得想想，我们每天在做的编程这件事到底是什么？

什么是编程？

到底什么是编程，知乎上这样的一个问题，编程的本质是什么？

很多人都给了自己的回答，但我发现很多回答，要么长篇大论各种编程范式，要么说得特别抽象，比如下面的回答，毫无指导意义。

其实，很多人对于事物本质的理解，似乎都有道理，但是我们希望这个答案可以指导我们编程的行为，知道如何写出好代码，如果我们从这个角度来看，那这个问题的答案就需要非常地具体，可执行。

这么多解释里，陈皓老师的解释最为具体，当然他也是引用的国外大佬的研究结论，但分析得相当好。

简单的两个公式表达得比较透彻。

程序 = 算法 + 数据结构

算法 = 逻辑 + 控制

程序 = 算法 + 数据结构

我们在写程序的时候，本质都是在写算法和数据结构，而我发现，大家更多在写代码的时候关注的是算法，而非数据结构（数组、链表、栈、队列、树、图等），这有可能是大家写不好代码的第一个原因。就像 Linux 之父 Linus Torvalds 所说的，「糟糕的程序员关心代码。好的程序员关心数据结构和它们之间的关系」。

我们在刷算法题的时候，常常会发现，一个合适的数据结构可以极大地提升算法的效率，比如：

在 leetcode 上有一个 hard 的题目叫做：基本计算器

这个题如果大家做过的话，其实有很多种解法，其中如果不用数据结构就会很复杂，如果用了栈这种数据结构，思路就会比较清晰，尤其是使用双栈这种数据结构。

因此，如果想成为一个会写代码的程序员，首先记住一点，「数据比代码更重要，代码的唯一目的是转换数据」。

有太多入行前端的同学，并不是计算机专业的，或者没有学过《数据结构》这门课，培训机构的教学也是以实战为主，一上来就开始写代码，长久的习惯导致代码的优化只停留在规范和格式上。

算法 = 控制 + 逻辑

除掉数据之外，代码就只剩下了算法，也就是我们日常写的流程代码，这部分依然可以拆分为控制和逻辑。这里要分清楚二者的关系：

控制 control 

在任何语言中，都有对应的语法操作，比如 if、for、map、reduce 等，这些都是控制语句。还有其他程序执行的方式，并行还是串行，同步还是异步，以及调度不同执行路径或模块，数据之间的存储关系，模块的组织方式，是函数还是类，多线程、异步、服务发现、部署、弹性伸缩等，这些和业务逻辑没有关系的部分都是控制。

逻辑 logic

逻辑一般指业务逻辑，我们把真实的需求抽象成代码以后的部分，比如：我们在做用户登录页面的时候，点击登录按钮以后，去判断下账号和密码是否符合一定的规则，这就是业务逻辑。

业务逻辑就是问题的定义，对于排序问题来讲，逻辑就是“什么叫做有序，什么叫大于，什么叫小于，什么叫相等”？控制就是如何合理地安排时间和空间资源去实现逻辑。

两者的关系

• Logic 解决问题，它决定了程序的本质复杂度，它是代码优化的下限。
• Control 只影响效率，控制是代码优化的重点，需要尽量地降低复杂度。
• Logic 和 Control 没有关系 
• Logic 和 Control 如果分开，代码更容易改进和维护。

底层逻辑：有效地分离 Logic、Control 和 Data 是写出好程序的关键所在

无论微观层面的代码，还是宏观层面的架构，无论是三种编程范式还是微服务架构，它们都在解决一个问题：分离控制和逻辑。

第一步：选好适合的数据结构。

第二步：做好业务逻辑的抽象（流程+模型）。

第三步：设计代码的控制过程（编程范式+设计模式）。

例子

function check_form_x() {
    var name = $('#name').val();
    if (null == name || name.length <= 3) {
        return { status : 1, message: 'Invalid name' };
    }
 
    var password = $('#password').val();
    if (null == password || password.length <= 8) {
        return { status : 2, message: 'Invalid password' };
    }
 
    var repeat_password = $('#repeat_password').val();
    if (repeat_password != password.length) {
        return { status : 3, message: 'Password and repeat password mismatch' };
    }
 
    var email = $('#email').val();
    if (check_email_format(email)) {
        return { status : 4, message: 'Invalid email' };
    }
 
    ...
 
    return { status : 0, message: 'OK' };
 
}

分离后：

// logic
var meta_create_user = {
    form_id : 'create_user',
    fields : [
        { id : 'name', type : 'text', min_length : 3 },
        { id : 'password', type : 'password', min_length : 8 },
        { id : 'repeat-password', type : 'password', min_length : 8 },
        { id : 'email', type : 'email' }
    ]
};
// control
var r = check_form(meta_create_user);

上面的例子，使用的是表驱动的方法，就是用一个 JSON 的数据结构来描述业务需求，再加一个控制函数，这样就可以很好的做到了数据、逻辑和控制之间的分离，同时还具备了很好的扩展性。

必备知识

代码解耦的方法有很多，要想写出好代码，需要掌握一些基础的理论知识。下面我列出了需要学习的一些必备知识。

• 数据结构：可以通过学习专业的数据结构教材，或者刷算法题来精进。

• 业务逻辑的抽象：多画业务逻辑图，流程图，明确完成一个逻辑必备的步骤，和可复用的模型。

• 控制设计：

• 编程范式

• 命令式

  • 声明式
  • 函数式
  • 面向对象

• 设计原则 SOLID

• 单一职责原则（Single responsibility principle，SRP）

  • 开放封闭原则（Open–closed principle，OCP）
  • Liskov 替换原则（Liskov substitution principle，LSP）
  • 接口隔离原则（Interface segregation principle，ISP）
  • 依赖倒置原则（Dependency inversion principle，DIP）

• 设计模式：有很多种设计模式，但是真正在前端常用的并不多，大家可以结合例子，系统性地学习。

  • 创建型模式：工厂、单例、创造者模式、原型模式。
  • 结构型模式：适配器模式、装饰器模式、代理模式、外观模式、桥接模式。
  • 行为型模式：观察者模式、策略模式、命令模式、迭代器模式、状态模式、责任链模式。

总结

上面所描述的写好代码的底层逻辑，同时给代码 CR 提供了一个比较好的方向，在做 codereview 的时候，可以多问问什么是逻辑，什么是控制，是否可以用数据结构来描述业务，什么样的数据结构是最适合的。

在设计代码的时候，也可以问一下自己上面的几个问题。把解耦慢慢变成自己的一个习惯，长此以往代码会具有更好的扩展性，可读性和稳定性。

文章转载于：