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

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

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

具体来说：

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

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

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

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

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

❝本篇文章只针对以上两部分人群，已经是大牛哒如果您有更深见解，欢迎指导。 ❞

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

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

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

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

一、形成良好的编码习惯

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

bad

good

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「使用eslint，stylelint检查代码」

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

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

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

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

「强烈推荐使用TS」

js是动态类型语言，代码在运行时才会报错，曾经有多少由此导致的错误折磨的你晕头转向，这只是一方面，更重要的是js语言极具灵活性，一个功能可以用很多种方式实现，代码质量参差不齐，再加上有的人不愿意写注释，那想接手上一个老哥的代码你不掉几根头发是休想搞明白，这里不举具体例子了，懂得都懂~

那用了TS之后能带来什么？学习Ts请查阅TypeScript入门教程，引用该文档中的一段话：

❝TypeScript 非常适用于大型项目——这是显而易见的，类型系统可以为大型项目带来更高的可维护性，以及更少的 bug。 ❞

❝在中小型项目中推行 TypeScript 的最大障碍就是认为使用 TypeScript 需要写额外的代码，降低开发效率。但事实上，由于有类型推论，大部分类型都不需要手动声明了。相反，TypeScript 增强了编辑器（IDE）的功能，包括代码补全、接口提示、跳转到定义、代码重构等，这在很大程度上提高了开发效率。而且 TypeScript 有近百个编译选项，如果你认为类型检查过于严格，那么可以通过修改编译选项来降低类型检查的标准。 ❞

TS可以让你的代码更安全，可读性可维护性更高、排查问题更容易。

至此代码规范方面先说这些，下面聊一下怎么更好地去做需求。

二、重新思考该如何做需求

每个程序员都是从做需求开始，为什么有的人成长的更快，成为团队的中坚人物，而有的人一直都只是在做需求，机械地完成产品所要的功能，只会做需求的人相对来说竞争力就更弱一些，更容易被别人替代，那我们到底要如何思考才能快速提升自己的境界？

三、 注重用户体验和产品质量

产品只负责提出业务需求，他通常不会考虑某些不在他需求内的现象，在遇到这些问题时要自己主动想着解决，否则当用户反馈回来时性质就变了，聚光灯直接投向你，你后悔当初没注意下面这些问题：

体验和质量就是一个程序员的脸面，保住脸面就俩字，“优”和“稳”，做到这俩字并不简单，我们慢慢体会。

四、 将你的技术债标记TODO，找时间偿还它

什么是技术债？

例如代码写的很啰嗦，本来10行就可以解决，你写了50行、还有可读性不高，晦涩难懂，还不注释、卡顿，性能不好、数据加载慢，用户等待时间长、不够健壮，弱网环境下容易出异常、代码结构组织不合理，维护困难等等等，这些都是你可能给自己留下的，不要认为写完了就可以不用管了，出来混总是要还的。

我们都不是圣人，谁也不能一次就写出绝对完美的代码，这跟我们经验的累积有关，有时产品要催着你匆忙上线一个需求也会导致你来不及处理而留下一些技术债，但是你要有意识找时间去解决它，「这些部分才是更能体现和锻炼你能力的地方，因为你在发现并改正自己的问题抓住这些机会可以让你快速成长，与他人拉开差距」。

五、突破固有习惯，探索发现更优解，持续学习和创新

有些同学可能长时间保持某种状态已经成为一种习惯，但是可能你的这些做法已经落后，或者并不是很好的解决方式，虽然这可能并不影响你的饭碗，但是你也很难有大的提升，长久来看终究会面临被淘汰的命运。

六、多记录、总结

不说假大空的话，依旧上干货，直接告诉你咋做，电脑上先安装个笔记软件。

至此，思想素养方面就先说这些，大家如果有补充欢迎评论区交流。

读到这里，大家多多少少都会有一些收获了，思想素养的重要性不言而喻，它决定了你的成长路线和成长速度并且直接与你的薪资挂钩，程序员和有思想的程序员他们的职业生涯一定会天差地别。一个人在日常工作中「自发主动」去做的事，才是这个人真正的「优秀特质」，开始有意识地去吸收、学习、总结、开拓、思考更多思想层面的，而不仅仅是聚焦于提高技术，可能会让你实现弯道超车。

本文一万多字，为避免篇幅过长，也为了不打断大家的思路，对经验技巧部分做了拆分已单独挪出到另一篇文章，这部分也都是干货满满，都是你日常开发中会用到的。小伙伴们可以先好好「吸收消化」一下本文内容，休息一下，做个，之后有空了可以直接找我的另一篇文章 优雅提效的高级js开发技巧 去看，

我们从专业技能、思想素养、经验技巧三个方面思考了小白和大牛的差距在哪里，在阅读的过程中不知道大家有没有将自己对号入座，看看你自己没做到哪些，又做到了哪些，要知道，并不是全都做到了就很完美，因为我也只是给大家提供一个思路，只是我自己的工作经验和见解，我也在不断地学习中，「不一定完全契合所有人，所以大家自己甄别吸收，找到适合自己的路子」。