😜序言
接上一篇文章，我们继续来看如何写好 JS 。在下面的文章中，将讲解写代码应该关注什么，以及通过引例阐述一些相关性问题。
下面开始本文的讲解~
🤗part1：先来看一段代码
首先我们先来看一段代码。具体代码如下：
//判断一个mat2d矩阵是否是单位矩阵
function isUnitMatrix2d(m) {
return m[0] === 1 && m[1] === 0 && m[2] === 0 && m[3] === 1 && m[4] === 0 && m[5] === 0;
}
我们先来思考一个问题：上面的代码写的好不好？为什么？
有的小伙伴可能会觉得写起来看着不太美观、又或者没有注释、扩展性不高等等各种原因。
其实，上面这段代码是一段真实的代码，其来源于一个开源库。具体地址：spritejs
get layerTransformInvert() {
if(this[_layerTransformInvert]) return this[_layerTransformInvert];
const m = this.transformMatrix;
if(m[0] === 1 && m[1] === 0 && m[2] === 0 && m[3] === 1 && m[4] === 0 && m[5] === 0) {
return nul l;
}
this[_layerTransformInvert] = mat2d.invert(m);
return this[_layerTransformInvert];
}
现在，我们来分析一下上面这段代码写的好不好。具体分析结果如下：
单从代码优雅性的角度来看的话，这段代码确实不够优雅。
但是呢，上面这个库是一个图形库，且这段代码负责的是在渲染之前，计算我们图层的 transform 矩阵的逻辑代码。
也就是说，我们在计算每一帧的时候，都需要进行一个计算。因此呢，在这样的一个场景下，我们首先要去关注的是如何达到性能最优化。
而与其他任何类型的写法来比，以上这种写法能够达到性能最大化，所以，以上这段代码在这样的一个场景下是没有任何问题滴。
同时呢，如果是对于其他场景来说，如果堆性能优化没有这么敏感的话，是可以不用这么写滴。
所以，一般来说，代码的好坏要结合它的使用场景来分析。
🤫part2：写代码最应该关注什么？
- 写代码我们应该要注重风格、效率、约定、 使用场景（算法） 和设计等方面；
- 风格：选择什么风格都没有错，关键是风格要统一（分号、行尾花括号等等）；
- 效率：在写代码时要考虑什么样的代码写起来效率是最高的，能写高效率的代码就不要写低效率的代码；当然，也要追求一个平衡就是，要结合它的场景来使用；
- 约定：在开发前，团队要约定好代码规范和风格，比如
eslint、airbnb等等；
🤔part3：当年的 Left-pad 事件
我们来了解下当年 github 的 Left-pad 事件。先来这个事件中的一段代码，具体如下：
function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = '';
len = len - str.length;
while(++i < len) {
str = ch - str;
}
return str;
}
那么这个作者想要实现的功能就是，比如说我现在有一段字符串，然后呢，我想要把这段字符串拼接成同样长度的字符串。
这个使用场景通常会放在一些展示类的地方，比如排序。当时这个模块一开始被用于很多的 npm 包中，但是后面被作者下线了，所以引起了很大的风波，因为很多人在用的库突然被下线了，试想，开发者岂不是要哭辽。
那这个事件本身的槽点呢，主要有以下三点：
NPM模块粒度- 代码风格
- 代码质量和代码效率
如果要考虑效率的话，那么我们可以对代码进行改进。比如：
function leftpad(str, len, ch = '') {
str = "" + str;
// 判断要补充的代码长度
const padLen = len - str.length;
if(padLen <= 0) {
return str;
}else {
return ("" + ch).repeat(padLen) + str;
}
}
通过这样的改进，使得代码更简洁，同时也极大的提升了运行效率。
🥳结束语
在上面的这篇文章中，我们了解到了当年的 left-pad 事件，同时呢，我们也学习到了写代码应该关注的5个问题：风格、效率、约定、 使用场景（算法） 和设计。
到这里，关于本文讲解就结束啦~
如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~😛
