前端工作中新的感悟

代码规范一直是困扰我很久很久的事情了，对于之前的前端工作要完成相当大的业务代码，对其规范没有过多的要求自己，对于div中class的命名也是千奇百怪 像 conent-box conent-left conent-right 等这类命名方式；对于函数的命名也是很是随意，也不能说没有语义化；只是没有规范而已。

对于我司先有的前端工程上来说，一切变量 函数都是要有语义化。也是我最近比较头疼的问题； 每次完成功能后主管会对于我代码进行code view，像 CreateMaterialType 修改命名为MaterialTypeOfCreate
CreateMaterialType 本身就是我写的typescript一个接口 但是命名却用了函数的do 动词类型；

函数命名

函数命名应该始终以 do + Something，例如切换选项卡function toggleTab(){}
函数都是要以动词开头的

这是些通用的动词，常用的就是get获取列表数据啊什么的， isShow 这些就是去做bol去命名的；

judgeEditOrAddSummary 函数意思就是要运用在摘要库的新增与修改方法的判断上，我之前就直接写了个updateSummary更新摘要的意思，也有动词update 直接提交推送，完了还是有问题。主管说你用update还是只指出了编辑没有说明新增；所以说要用判断judge（至于为什么用judge而不是judgment呢，因为judge是动词喽，函数开头要用do+somthing） 编辑或添加（editoradd编辑或添加） 因为这个单词我真的是百思不得奇解啊； 周五下班主管在对我代码进行code view时候发生的； 当告诉我使用xxxxx时，我听懂是什么了，死活就是不会拼写；想查下什么意思都不清楚；很是无奈 对于上面我做的解释就会很清楚的说明这个函数的准确用意了。 像我这么糙的一个人 唉 确实要做些文章日记去做些记录；

or啊of什么 这样的组合实在是因为小学中学大学英语是真的渣渣了；

所以我主管也有推荐我的学习之路，dev.to这些英语文档去尝试翻译，对于英文文档中要表达的意思要比中文讲解更加直观。 对于我今后的前端工作会有极大的帮助；

还有就是一个弱智的git问题，我真的有时候会死在这个上面，

最近在网上有个真实发生的案例比较火，说的是一个新入职的员工，不会用 git 拉代码，第二天被开除。由此，可见 git 对我们工作的重要性，无论是前端后端，都是离不开 git 的。

对于现阶段都是可视化工具了，平常用到的也就是 Sourcetree

相信大多数的前端工作者都有用过这个可视化git工具，之前工作的时候也有遇到过很多自己搞不定的问题，像代码的拉去啊 还有代码推送啊 在自己的分支上忘记拉取dev分支上的代码导致提交时，commit会有很多未知的问题，等等

代码的合并冲突问题，如何去解决冲突 相信大家都是会运用的很好；而我却很容易犯错

git的日常操作

之前公司都是在dev上去开发的，每当我们去做功能的时候都会去创建一个git flow的工作流 对于新增功能 修改bug 修改样式都会在git flow里去新建一个功能，然后去合并到dev开发分支中去。

现在公司增加了一个code view的环节，我会新增一个自己的分支 zxx-dev 这样的分支去写我的代码，当我完成功能要提交的时候，并没有去看dev分支有没有新的代码时，就会出现我提交的代码多了很多的commits。需要撤回我的git commit操作

git commit之后，想撤销commit

git reset --soft HEAD^

这样就成功的撤销了你的commit

注意，仅仅是撤回commit操作，您写的代码仍然保留。

说一下个人理解：
HEAD^的意思是上一个版本，也可以写成HEAD~1

如果你进行了2次commit，想都撤回，可以使用HEAD~2

--soft
不删除工作空间改动代码，撤销commit，不撤销git add . 等于说就是只是撤销了提交git的记录，不用删除你所写本地代码；

--hard
删除工作空间改动代码，撤销commit，撤销git add .

注意完成这个操作后，就恢复到了上一次的commit状态。 等于说是回滚代码是一样的，修改成你开发前的代码了

工作中我就是出现了这个问题，因为没有拉取团队同伴的代码导致的，commit错误； 所以我就百度查了下 怎么撤回我在sourcetree 中的提交;我先是用到了 git reset –soft HEAD^ 只是回退到了我前一次的提交了，因为我是分模块的 提交了两次git commit 所以就蒙了

那就操作了 git reset –hard HEAD^ 直接删掉了。。。。 懵逼了我 代码没了 叫来了主管帮我看下问题发现了这个问题 问我知道什么是 soft 什么是 hard 不；

我只能不说话 沉默 因为平常我也没有用过 就一顿乱操作导致了这样的问题；这是个很尴尬的问题

对于我司现在的git提交也是有相应的命名规范的

相当的严谨

feat(xxxx功能): 新增xxx

括号里写模块名称 英文的冒号+空格+描述

常用的也就是 feat 新功能 style 样式的修改 chore 在code view后进行的修改 fix 测试中出现的bug修改

注释

我之前的理解注释 一直都是

js css 的注释为 //

html 的注释为 <!-- -->

我一直对注释个都是叫 标注啊 注解啊什么的 正确的叫法就是注释

FIXME

开发中可能会遇到一些需求，你需要在短时间实现，但是这样设计的代码可能会存在问题时，可以在代码中写一些 FIXME，例如：

//FIXME: 后期回跟接口协调接口数据修改

TODO

开发中可能会写出一些可读性不好或者可维护性不好的代码时，可以在代码中写一些 TODO，例如：

// TODO: 这里先用迭代实现，时间复杂度不是最优，后期思考是否可以优化

function createMenuList() {}

TODO: 属于自己的问题，只是没有想到有更好的办法或方式 等等党

`/**

• @description 素材详情
• @param id 素材ID

*/`

对于

这样在api接口文件中，就能清晰的展示出传递的接口，还有注释的内容

这也是我在新公司对注解的规范化认知；

代码优化

map的简写方式：

  cloneTitleFields.belongGroup.value = data.map(item => {
    return { value: item.id, label: item.name };
  });
复制代码

本身箭头函数就是 => 自带return

  cloneTitleFields.belongGroup.value = data.map(item => ({
    value: item.id,
    label: item.name
  }))
复制代码