想成为优秀前端，你需要知道这些！（基本素养、代码规范、开发技巧）

前端开发工程师分了好多级别，所谓级别的差异，无非就是专业技能、思想素养、经验技巧这几个方面的差异，修炼成大神的路上，这三门功夫缺一不可。

「基础能力决定了你的下限，思想素养决定了你的上限，而经验技巧则影响着你整个程序猿生涯的体验。」

具体来说：

专业技能

专业技能就是你对主攻技术栈的掌握情况，如前端的一系列技术，JavaScript、HTML、CSS、Node、Vue等等，掌握这些基本技术，能够确保你可以应对一些日常开发工作。公司交给你一个任务，不考虑效率、质量、维护、协作等，你现在是可以把代码搞出来上线运行的，在一些要求不是很高只关注产品表现的公司，你是完全可以胜任的，东西做出来就行，没人关注你是咋做出来的。

这几天刚在掘金看到了一个帖子，一个 5 年经验的老哥说自己就是一个刷题机器，为了面试而面试，八股文背的贼溜，当初在较暖的市场环境下顺利进入大厂，如今却很焦虑，因为自己只能做一些简单需求，遇到复杂问题时就会很慌，背的那些八股文在实际开发中就显得有些捉襟见肘，自己也没有了年轻时候的那股冲劲，不愿意花时间去学习了，得过且过，变成了一个无情的打工机器，因为部门业务比较边缘，所以才能一直在大厂苟着没被裁，但是感觉也快了，老哥文章最后说了一句：“不知道有没有跟我一样的程序员，凭借不错的运气，市场比较暖进的大厂，然后能力很一般，在大厂得过且过”。

我想说，肯定有而且不在少数，往往这种情况入职一两个月就能看出来个大概了，老哥能待好几年确实挺幸运的了，但是谁又能保证自己都能像这位老哥一样幸运呢，尤其在今年这样的市场环境下，当公司发现你效率低、不能自己主动解决问题到处问、与同事沟通协作不顺畅、不学习新东西、编码风格一年两年都没有任何变化，难以阅读和维护、上线后bug反复。。。这种情况即使你能把八股文背出花来又能怎么样，换句话说你基础再牢固，会的再多又能怎么样？技术只是一块敲门砖，进来之后能不能守得住才是真正考验一个人能力的点（没有对被裁员的小伙伴有任何特殊意思，毕竟今年这种形势）。

老哥实际工作中所做的都只是日复一日的搬砖工作，没有对所做工作的个人积累总结和思考，放到现在大概率面试都过不去了。

❝或许正在看文章的你目前就是处于一种得过且过的状态中，我想说的是，一定不要在这个舒适圈中日复一日，仅满足于胜任当前这个工作，甚至你都达不到胜任而只是能够做出来而已，不客气的说，你只是没遇到牛人，没遇到牛的团队，没有人指出你的问题和缺点，并不代表你很优秀了（事实是你肯定存在一些问题，啥问题后面唠）。你的所有敷衍糊弄和安于现状随着时间的慢慢推移都会一点点地反噬自己的职业生涯，真到了一定年龄之后再后悔就只能一声叹息了（除非你志不在此，有更好的路子）。一直停留在原地必然会被淘汰，无论是刚进入职场，还是已经工作一两年的。如果你是刚进入职场，那么看完这片文章希望能让你少走些弯路，带给你一个让自己「快速提升」的抓手，如果你已经抱着只完成工作就行的态度上了一两年的班了，那么希望你立即做出改变，不要再日复一日的搬砖了。 ❞
❝本篇文章只针对以上两部分人群，已经是大牛哒如果您有更深见解，欢迎指导。 ❞

想在程序猿的道路上有所发展，想得到公司或团队认可的小伙伴，请你一定耐心看完这篇文章，相信你一定会有一些收获。

转变态度后你能得到啥？

「薪资、职级提升」。
「自信」：如果公司发现你的代码质量、你处理问题的思路、分析业务的方法、需求的维护性和可迭代性、开发迭代的效率等等都有明显的提升却依旧无动于衷，那你也有充分的自信去争取与自己匹配的待遇和适合自己的工作环境。
「更好的开发体验」：相信我，写一串能运行起来的代码没啥特别的，情绪上也不会有啥波动，但是当你用「更合理更优雅更高性能更健壮」的方式去实现一个业务时，你会得到至少双倍的愉悦感成就感，将写机械又平淡无味的代码变成一种乐趣何乐而不为呢？
你的性格以及生活习惯影响着你的工作态度，例如你生活上对待一些事的态度就是差不多就行，得过且过，那你写出来的代码大概率也是这风格，而反过来，「良好的编程思维也会一定程度地反作用于你的生活」，例如：在做业务时我们往往要考虑各种非正常情况下的兜底策略，如网络不好时该怎么展示，用户反复点击一处时怎么处理等，作用到我的生活中就是，我会在做一件事之前会尽可能考虑各种异常情况，如果不按自己预期发展会怎么样，提前做好备用方案。这里不举更多例子了，欢迎评论区交流，总之，代码写的好（这个好包含很多方面，下面详说）至少证明你的思维方式是有章可循的，同样的思维你用在生活中一定也是有好处的。
「效率提升」：于公司，你有更多时间处理其他需求或优化业务，更快更好地达成绩效目标，为公司业务成长贡献更多的力量。于自己，你有更多时间去学习，去散散步去健身放松一下，少加点班，保持身体的健康，持续创造价值，掌控自己的生活节奏。

那我们该怎么样去全方面的提升自己，上面说了三点，专业技能、思想素养、经验技巧，专业技能是最基本的，你应该通过各种方式去学习，这是能立即看到成效的，其实没啥难度，只要你肯花时间，经验技巧亦然，随着工作时间的越来越久你所积累的经验技巧自然而然就会越来越丰富，自己的积累和总结再加上对他人经验的copy merge，能帮助你更快成长。

那么最难的是什么？就是思想素养，你光花时间还不行，还得花「心思」，我始终觉得思想素养比技术以及经验更重要的多，技术谁都能有，经验谁都能有，一个好的前端职业素养不是谁都具备的。

思想素养往往就是你和大佬之间差距最大的地方，那么在提高思想素养方面我们可以做哪些努力呢？

思想素养

一、形成良好的编码习惯

「变量和方法命名见名知意，使用小驼峰命名，避免使用下划线」

bad

代码语言：javascript复制

let a1 = 1;  // 坚决杜绝使用让人看了也不知道是啥的字母数字组合
const user_last_login_time = {}; // 不要使用下划线命名变量
list(){}; // 只写一个list

good

代码语言：javascript复制

const userLastLoginTime = {}; // 小驼峰可读性更高
getUserList(){}; // 方法名最好使用动词 名词的组合

「方法名定义推荐加上动词前缀」

加载数据使用 load 前缀，例如：loadUserData
获取数据或值使用 get 前缀，例如： getUserAvatar() ❝load与get的关系是load前缀的方法可以包含多个get前缀的方法，get不可以包含load前缀的方法，可以理解为要加载的数据由一或多个get前缀的方法来获取 ❞ loadUserData(){ this.getUserLocation(); this.getUserInfo(); ... }
设置数据或值使用 set/update 前缀，例如： updateUserAvatar()
格式化数据使用 format 前缀，例如： formatUserList()
判断某种条件使用 judge 前缀，例如: judgeCanShowModal(); judgeIsVipUser();judgeHasRecord(); ❝有的同学直接使用isVipUser()这种命名方式，也可以，但是我更倾向于函数是一个动作，用 const isVipUser = true 可以表示一个值，表示一个判断动作的话还是加上前缀比较好。 ❞
监听事件或数据变化使用 on 前缀，例如 onFilterChanged(); onSubmitSuccess();
点击事件使用 click/tap 前缀，例如 clickUserAvatar(); ❝移动端开发建议使用tap，PC端建议使用click ❞
跳转新页面使用 navTo 前缀，例如 navToDetailPage();

「常量使用全大写，使用下划线连接单词」

代码语言：javascript复制

const PAGE_SIZE = 10;

「命名风格全局要统一，有章可循，别这个文件这样，另一个文件又那样了」

不是非要一定按照上面的前缀来命名，只要你做到让人一眼看上去就知道这个方法是干嘛的，而且要有规律可循，你可以按自己的喜好来命名。举个例子：你知道你的某个同事喜欢用 judge 前缀来命名具有判断相关逻辑的方法，那你看他代码时一看到 judge 开头的，不用看内容只看名你就大概知道是干嘛的了，节省下来的时间干别的不香么。

「严格控制文件行数，最好保持在500行以下」

该拆分的拆分，文件行数过多，可维护性和可读性都很差，别说什么业务本身就很复杂，拆不出来只能说你代码组织能力差。

拆分维度根据你的需求不同而不同，但是大体的思路可以是common通用方法、utils工具方法、gateway请求方法，presenter数据处理、models数据模型（TS）等，还可以根据你的业务逻辑来拆分，总之维度很多，重点是要拆的清晰，一定要避免拆的多而杂，那样还不如不拆。

「严格控制代码重复率，不要图方便一味复制粘贴」

代码重复率是一个团队代码质量评测一个很重要的指标，显而易见重复代码会占用更多空间，并且会增加维护的困难度，修改你复用的重复代码时很容易漏掉，要耗费额外精力去验证，所以尽量拆出你的复用逻辑，别偷懒，别给自己留坑。

「迭代时做好重构优化代码的准备」

不要为了一时轻松，写迭代需求时就一直在原代码基础上加加加，或者不敢动以前的代码，怕改出问题，如果迭代的新功能有更好的组织形式，多花一点时间去重构优化绝对是值得的，这将长久利于你后续的功能迭代效率，也会丰富你组织代码的经验，再有类似需求时你就可以预先使用更优的代码组织形式，后续产品想要迭代时你将游刃有余。

以上建立在是自己的代码，你对自己的代码有足够的了解的情况下，再根据实际情况衡量收益，对后续迭代收益大的话，重构是有必要的。如果起初就没有设计好，导致维护的时候不能按理想的方式来，以后迭代都要受不合理代码的制约而一次次妥协的话，那难受的还是自己。

当然，这个看个人，你不难受的话那你就可以不重构，但是不能保证看的人不难受，你有自己的认知程度，但不代表你的认知是对的，是好的，对自己的水平要有个充分且客观的认识，而且永远不要认为你负责一个业务这个业务的需求就永远都只给你做，首先公司是不希望一个业务只有一个人了解的，这个懂吧，没有你业务就崩掉这种事绝对不会允许发生，更别提你请个假啥的，所以你的代码总有机会被别人接触，别人对你技术水平的判断就会在这时开始形成。

❝曾经我就是写迭代需求时偷懒不想动以前的代码，最初的代码没有设计好，后续迭代一直加加加，每一次迭代都越写越难受了，自己都觉得不想维护了，那别人呢？有一天导师在我的代码基础上迭代，代码的所有缺陷暴露无遗，找我进行了将近一个小时的“指导”：首先你的代码最初就不该这么设计，你没考虑过将来迭代吗，你这一环套一环叫我怎么改，我得把你的整个代码都捋一遍吗？那我还干不干活了。。。 ❞

所以，发现不合理的时候「及时重构优化」，注意关键词，及时！别等到堆成屎山了之后再给自己找借口说什么重构成本大，风险大，我们管不了别人咋写，但是可以时刻对自己的代码负责。

❝其实，如果你及时优化做的好的话，根本都不会至于到重构的地步。 ❞

总之，及时优化代码，必要时也不要惧怕重构。

「写注释，随手写注释，刻在骨子里，像条件反射一样！」

不多说，你自己去看看不爱写注释的那位同事的代码，感受一下，你就明白为啥注释这么重要了，或者简单点，你就看你自己没写注释的代码，一个月前两个月前的，你还能完全捋清楚当时的思路不？

方法最好都写注释，变量名等如果你觉得实习生都可以轻松看懂的部分可以不写。

「方法、类、组件遵循职责单一原则」

内部所做的事情要与名字契合，不要额外写无关的逻辑

代码语言：javascript复制

  // 判断是否新用户
  judgeIsNewUser(user) {
    const isNewUser = true;
    sendMessage(isNewUser); // 该方法的职责仅仅是判断是否新用户，这里调用了发送消息方法，做了额外的事，
    return isNewUser;
  }

缺点之一就是有别处想获取是否是新用户时调用该方法，也会调用sendMessage方法，那你说我可以传个参数加个判断，兄弟，咱别把代码写成x好么，你这一层套一层的何必呢，别人看你代码的时候顺着你给的线索捋？说好的只是判断新用户，咋又顺带干了别的活呢，那还能信任你的命名了么，再看你其他代码的时候是不是就心怀顾忌了。

❝同理，类和组件也是一样，说干啥就干啥，不要偷着做别的事。 ❞

「方法、组件需要的数据不要耦合依赖全局数据或一些并不是为你的需求准备的其他外部变量」

所以，别给自己找麻烦，老老实实的给函数传参，给组件传参吧，记住，「牵一发而动全身的代码，这样的代码毫无疑问就是x」。

❝当然不会轻易被改变的全局变量不在这点所包含的范围内，例如手机号、性别等。 ❞

你的方法和组件数据依赖的变量，会不会受别人改动而被影响，如果别人也在用这个变量不小心改了是不是你的就崩了
反之如果别人想用你的组件，那就得改这个变量，改了就可能搞坏别的，他也不知道这个变量还有哪个鬼在用，那干脆不用组件了，自己写吧
再比如，你通过某种奇怪的方式将别人的某个文件或组件里的变量拿来用，那他不会保证哪天不把这些代码删掉或改掉，然后你线上挂掉了，你可怪不到人家头上，即使你用的是自己其他需求里的变量，万一产品哪天说那个功能下线了，你咋搞？

「最好不要使用全局对象挂载变量」

全局对象上直接挂载变量使用起来固然方便，你一个人负责一个项目时完全可以这么做，但是当一个「团队共同开发一个项目时，没有人知道全局对象上到底都有什么，但是谁都可以在全局对象上添加和修改属性很容易相互覆盖」，那不就乱套了，我们曾经试过大家一起维护一个全局对象文档，谁用了谁就加上去，但是这样成本太高了，且不能保证百分百准确，所以禁止使用全局对象挂载变量是个更好的选择。

那怎么共享变量呢，使用“状态管理工具”，无论是用vuex还是仅仅是一个更简单的js模块来存储数据。

「不要使用变量拼接会经常被全局搜索的字符串」

代码语言：javascript复制

const str = 'default';
const defaultAvatar = `https://www.aa.com/imgs/${str}-avatar.png`;

这样如果你想搜索哪里用到了default-avatar.png这个图片是搜不到的，类似的还有跳转路径，埋点标识等，要格外注意。

「使用ES6 语法，简化代码，提高效率」

JavaScript语言本身也有一些令人不满意的地方，如变量提升，回调地狱等，ES6 主要是为了解决ES5的先天不足，每一次标准的诞生都意味着语言的完善，功能的加强，2015年就发布了ES6，如果你还在用老语法开发，那就真的脱节了。

「不要盲目追求使用新语法和一些奇淫技巧」

上面虽然说了，推荐使用ES6 语法，但是要补充一句，不是让你全盘使用新特性，「对于ES新特性大家要做到全面地了解，有选择地应用」。

有些新特性并不是很好用，或者用处不是很大，用了之后反而增加他人阅读成本和编译成本，选择常用实用的特性就可以，可以参考下推荐使用的新特性，仅供参考哈。
根据自己所处的公司和团队环境做相应的「取舍」，大家对新特性的了解程度不一样，随意地使用较新的特性可能会让团队成员看不懂，如果要使用一定加好注释。 // 使用ES2022的特性Top-level await 异步加载模块，不了解的人肯定一脸懵逼，所以要用的话加好注释 const language = params.get('lang'); const messasges = await import(`./messages-${language}.mjs`); // ES2022的新特性Top-level await，参考(https://github.com/tc39/proposal-top-level-await)。队友学习能力强的话就写简单点：// ES2022 Top-level await
某些奇淫技巧也是一样，看团队可以接受的程度，如果你想秀操作最好使用时加好注释，有的团队会更注重代码可读性，会明确规定不让使用一些花里胡哨的写法，比如： const num = ~~'1'; 用~~把字符串转换成数字，使用Number('1')可读性更好，相比于那一点点微乎其微的性能提升，显然可读性更重要。

「列表渲染和条件渲染写在标签的第一个属性」

代码语言：javascript复制

// Vue
<div v-if="show" id="" class=""></div>
<div v-else id="" class=""></div>
// 小程序
<view wx:if="{{show}}" id="" class=""></view>
<view wx:else id="" class=""></view>
<view wx:for="{{list}}" wx:key="index" id="" class="" data-index="{{index}}" bindtap="clickBtn" ></view>

这样写可以增加可读性，可以更快速直观地看出来元素之间的关系，以及是否渲染，如何渲染，这些信息比其他属性更主要。其他框架同理。

❝至于是否换行，几个属性换行以及其他属性的优先级看自己或团队习惯。例如我喜欢把绑定的事件放在最后面，那我看自己的代码或别人看我的代码的时候，如果要看这个元素的绑定事件就直接定位到开始标签的最后面就ok了，尤其属性很多的时候，效果更明显，当然你也可以直接搜索。原则上还是那句话，有章可循，不要杂乱无章就好。 ❞

「重要的是思想！有了这样的思想之后，那样式文件是不是也可以做到 有章可循，是不是同样也能提升效率，提高可读性？」，如果你一时觉得没必要也可以忽略掉这点，但是这个思想还是值得慢慢去在项目中体会的，相信你会感受到它带来的好处。

「样式文件中根据dom结构分块且有序地编写样式」

代码语言：javascript复制

/* header头部样式 */
.header {
  ...
}
.header .logo {
  ...
}
.header .search-bar {
  ...
}

/* list样式 */
.list {
  ...
}

.list .item {
  ...
}

所有跟头部相关的样式都写在一起，所有跟list相关的样式也写在一起，「样式定义顺序尽可能与你的模板中元素顺序一致」，便于定位和修改。如果使用less等css预处理器就更好了：

代码语言：javascript复制

/* header头部样式 */
.header {
 ...

 .logo {
 ...
 }

 .search-bar {
   ...
 }
}

/* list样式 */
.list {
 ...

 .item {
   ...
 }
}

如果你习惯用BEM命名的话也是一样，分块且有序。甚至如果你想的话，css属性的顺序也可以遵循一套规则，使用stylelint插件stylelint-config-recess-order可以自动调整你的属性顺序。

代码语言：javascript复制

  position: relative; // position优先
  width: 710rpx;  // 然后元素宽高
  padding: 0 40rpx; // 然后边距
  padding-top: 30rpx;
  padding-bottom: 34rpx;
  margin-top: 18rpx;
  margin-bottom: 16rpx;
  background: #fff; // 然后字体背景阴影等
  border-radius: 40rpx;
  box-shadow: 0px 0px 38rpx 0px rgba(0,51,105,.0500);

规整、清晰，你看到这样的代码不觉得心情都很好么。

「能使用CSS实现的尽量不要用JS」

假设有个需求，只在列表中的第一项展示标签，你第一反应是不是就是在JS中或者在模板中if判断，试试用伪类:first-child，轻松搞定。

代码语言：javascript复制

.list .item .label {
   display: none;
}

.list .item:first-child .label {
   display: block;
}

还有使用 flex 的 order 属性控制元素顺序，可以省去很多JS代码。还有一些简单的图形如倒三角使用CSS写就行，没必要切图，图片多了也会影响整体性能。

总之思路就是，用CSS减少不必要的JS逻辑、图片、动图等。

「使用eslint，stylelint检查代码」

换行啊，空格啊，语法啊等等规范繁多，你不需要一个个去记，写完了人工进行检查，那效率可太低了，使用插件帮你搞定。

eslint，stylelint在你的代码不符合规范时会提示错误或警告，提高你的代码质量，也能一定程度避免一些语法错误，推荐使用vscode配合以上插件可根据你的规则自动修复代码。

尤其新手，一定要用，别怕麻烦，从最初接触代码就主动培养良好习惯，比你后期进入规范严格的公司被强制要求的时候再花精力改进要好得多（现在大多数公司都有强制的规范，不符合规范你代码都提不上来）。

可以使用现成的规范包或其他大厂规范，大家自己搜就可以，大同小异，不用纠结到底用哪种，公司有统一规范，就以公司为准，公司没有规范就选被业界普遍应用的规范，慢慢再根据自己的习惯优化（正经的技术团队不会没有规范要求的

产品代码规范技巧开发前端

0 人点赞