前言

书接上回近四个月的复盘总结从最近的工作中我学到了什么（近期工作学习记录与复盘），一周时间又过去了。

笔者打算坚持有收获就在日后践行并在此分享的好习惯，本周想要分享的是在code review（包括阅读他人代码与自己的代码被阅读）中时前辈们提供的灵感转化来的一些代码编写优化tips。

截至目前个人情况概览

~ o(￣▽￣)ブAloha，这里是superlit帆，很开心在两位经验丰富的行业前辈的引导+自主驱动下能学习到更多代码构思与编写层面的tips，在此希望笔耕不辍，坚持记录分享也坚持在日常中践行。

关键词：代码编写优化、计划落地优化、总结期许

代码编写优化

如何让自己的代码更清晰易读？

更好的代码布局

比起上手就干，更好的步骤为：

通读业务需求；
明晰业务逻辑与交互流程（可以通过画流程图、在纸上布局好页面模块并理清楚模块与）；
构思好大的框架（按页面布局按模块划分好不同的区域），尽量保持index文件代码布局看起来清爽干净（比如左右结构，那么index里可以分为左右两个大块，而这两个大块可以用各自的文件夹index引入，以此类推）。

这里举个🌰，业务需求为一个页面有左侧A上B下，右侧C上D下四个模块，如果对index没有布局概念的话，比较容易写出下述代码：

tsx 复制代码

index.tsx
function App() {
  // ...
  return <Fragment>
      <A/>
      <B/>
      <C/>
      <D/>
  </Fragment>
}

上述代码这样罗列其实是根本看不出ABCD在页面上的排列顺序的，让我们来根据上述步骤改造下，就有了

tsx 复制代码

index.tsx
function App() {
  // ...
  return <Fragment>
      <Left />
      <Right />
  </Fragment>
}

Left.tsx
function Left() {
    // ...
  return <Fragment>
      <A />
      <B />
  </Fragment>
}

Right.tsx
function Right() {
    // ...
  return <Fragment>
      <c />
      <d />
  </Fragment>
}

index.tsx文件被收纳好了的话，模块与模块间的布局和依赖关系就会变得更加清晰，当然了，Left、Right、A、B、C、D只是取名参考，这里可以替换成对应业务大模块名称会更为合适，然后按照阅读习惯去布局模块位置代码就会很清晰了。

好的取名规范

React tsx文件及文件夹驼峰式+开头大写；
不管是函数还是变量都需要注意语义化，给具体业务代码中的函数命名最好不要用指代不明的类似于a/b/c这样的命名方式，而是结合变量实际含义取名，常量可每个字母大写并且通过下划线连接，但是变量可以采用小写开头的驼峰式命名，这样就能一眼看出什么是什么。

运用好ts编写

ts有很多方法是可以简化编写的，比方利用Partial方法处理某个ts声明，就能使该声明里的每个字段都变成可选的状态，举个例子

ts 复制代码

interface A {
    a: number
    b: string
}
interface B {
    params : Partial(A)
}

这样的写法就能使B中params字段是可选A声明任意字段的写法；

更详细的描述，更方便的维护比起这样不写明出入参形式的声明函数变量

ts 复制代码

interface FunctionVariable {
    toUpperCase : Function
}

根据函数实际出入参，声明清楚onClick的出入参形式会更便于后期的维护

ts 复制代码

interface FunctionVariable {
    // 声明一个函数字段，该函数接收一个字符串参数并返回一个字符串
    toUpperCase: (input: string) => string;
}
 
// 使用这个接口来声明一个变量
let myFunctionVariable: FunctionVariable = {
    toUpperCase: (input) => input.toUpperCase()
};

如何让自己的代码更简洁高效

巧用js自带方法

比方说用列表a根据id去匹配列表b，最后得到基于b更新列表a中字段status，进而得到更新后的列表a这样的需求，如果不掺任何技巧的话会写成这样的双重for循环：

ts 复制代码

for (let aIndex = 0; aIndex < a.length; aIndex++) {
    for (let bIndex = 0; bIndex < b.length; bIndex++) {
        if(a[aIndex].id ===  b[bIndex].id) {
            a[aIndex].status = b[bIndex].status
        }
    }
}

但是我们注意到，这样的场景是可以通过Map和其自带的get方法一步到位的，于是我们可以将上述代码优化为：

ts 复制代码

// 使用 reduce 方法将b数组转换为 Map  
const bMap = b.reduce((acc, cur) => {  
acc.set(cur.id, cur);  
return acc;  
}, new Map());
const updatedA = a.map((item) => {
    const bItemByKey = b.get(item.id) || {};
    const status = bItemByKey.status;
    const updatedItem = { ...item, status }
    return updatedItem;
})

学以致用起来，知道Map、Set、WeakMap、WeakSet是什么之后，在日常工作中可以根据业务场景用起来，这里插播一个友链博客，不熟悉的朋友可以了解起来：【ES6系列】详解Set 和Map两种数据结构

如何让自己的代码更稳定拓展性更强

编写时做一步前先想十步

啊哈哈哈，看自己之前写的代码深有体会，上手就干写出来的东西往往是冗余的，杂乱的，后续维护成本比较高并且拓展性不强的。编写前先思考如何将我的index.tsx收纳的更干净简洁，如何利用配置化的编写方式让一套代码可以适用多个场景？都是值得去思考的。

组件库里最好不用Spice去控制间距

之前笔者会习惯利用antd自带的Spice去控制间距，但是前辈提醒如果这样写的话容易出现后期每个模块间距都不一样之后代码的大整改，拓展性其实是没有手写强的，这里记录一下提醒自己不图省事用Spice，因为确实会有那样的情况发生。

保持对代码的质疑------是不是还可以写得更好

code review的时候有前辈说了很关键的一句话，"你对你的代码如果没有质疑是不是可以更好的感受，那你十年如一日都会是同样的编码风格而没有长进，做任何事情都是一样的"

我当时听到这句话一整个醍醐灌顶，我到底是想日复一日的重复，还是百尺竿头更进一步的天天向上呢？！

有了这个意识之后才会下意识的对自己要求更高：我到底怎么写才会更好？我到底怎么做才会更好？

计划落地优化

怎么更好的制定

这里设定为以周为单位的排计划

按照业务量与个人能力提前构思好下周工作内容所需的理想状态时间；
在理想状态时间确定后多预留1-2天给突发情况（比如被临时派活、被安排解决别的项目等会打乱计划的事情），变化也应该是包含在计划里的，这样在复盘的时候你的每一个计划相对不排变化的时间来说都是能比较安稳的落地的

怎么更好的落实

计划不是列给别人看的，是列给自己看的，既然制定了就应该朝这个方向靠齐，这里我会红字标注好计划第一要素------践行，提醒自己计划存在的意义是践行而不是被打乱。

总结期许

有高人指点+多问自己为什么是什么怎么样更好是真的会进步神速，接下来就是知行合一在工作和日常中去坚持践行了。这里是前端周周见，很高兴这一周又有这么多收获，谢谢自己整理到这里，也谢谢这周给我提供灵感的前辈们~下周见！

一些代码编写、计划落地优化tips

代码编写优化

如何让自己的代码更清晰易读？

更好的代码布局

好的取名规范

运用好ts编写

如何让自己的代码更简洁高效

巧用js自带方法

如何让自己的代码更稳定拓展性更强

编写时做一步前先想十步

组件库里最好不用Spice去控制间距

保持对代码的质疑------是不是还可以写得更好

计划落地优化

怎么更好的制定

怎么更好的落实

总结期许