写出好代码的底层逻辑
程序员安身立命的手艺就是写代码,可多少人知道如何才能写出好的代码呢?这几年也做过很多次的代码 CR,可好代码的标准在哪里呢?我们在做 CR 的时候,其实只是停留在代码的表面,主要是跟规范相关的点:命名、代码行数、代码写法、注释如何,这些其实都是可以用 ESLint 做规范去解决的,也很容易形成习惯。如果在这个基础上,每个人都做得不错的情况下,那到底什么是决定了代码的好坏呢?
在想这个问题之前,我们得想想,我们每天在做的编程这件事到底是什么?
什么是编程?
到底什么是编程,知乎上这样的一个问题,编程的本质是什么?
www.zhihu.com/question/20…
很多人都给了自己的回答,但我发现很多回答,要么长篇大论各种编程范式,要么说得特别抽象,比如下面的回答,毫无指导意义。
其实,很多人对于事物本质的理解,似乎都有道理,但是我们希望这个答案可以指导我们编程的行为,知道如何写出好代码,如果我们从这个角度来看,那这个问题的答案就需要非常地具体,可执行。
这么多解释里,陈皓老师的解释最为具体,当然他也是引用的国外大佬的研究结论,但分析得相当好。
简单的两个公式表达得比较透彻。
程序 = 算法 + 数据结构
算法 = 逻辑 + 控制
程序 = 算法 + 数据结构
我们在写程序的时候,本质都是在写算法和数据结构,而我发现,大家更多在写代码的时候关注的是算法,而非数据结构(数组、链表、栈、队列、树、图等),这有可能是大家写不好代码的第一个原因。就像 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 的时候,可以多问问什么是逻辑,什么是控制,是否可以用数据结构来描述业务,什么样的数据结构是最适合的。
在设计代码的时候,也可以问一下自己上面的几个问题。把解耦慢慢变成自己的一个习惯,长此以往代码会具有更好的扩展性,可读性和稳定性。
文章转载于:https://juejin.cn/post/7348463942404980777