引言

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

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

具体来说：

专业技能

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

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

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

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

或许正在看文章的你目前就是处于一种得过且过的状态中，我想说的是，一定不要在这个舒适圈中日复一日，仅满足于胜任当前这个工作，甚至你都达不到胜任而只是能够做出来而已，不客气的说，你只是没遇到牛人，没遇到牛的团队，没有人指出你的问题和缺点，并不代表你很优秀了（事实是你肯定存在一些问题，啥问题后面唠）。你的所有敷衍糊弄和安于现状随着时间的慢慢推移都会一点点地反噬自己的职业生涯，真到了一定年龄之后再后悔就只能一声叹息了（除非你志不在此，有更好的路子）。

一直停留在原地必然会被淘汰，无论是刚进入职场，还是已经工作一两年的。

如果你是刚进入职场，那么看完这片文章希望能让你少走些弯路，带给你一个让自己「快速提升」的抓手，如果你已经抱着只完成工作就行的态度上了一两年的班了，那么希望你立即做出改变，不要再日复一日的搬砖了。

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

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

转变态度后你能得到啥？

• 「薪资、职级提升」。

• 「自信」：如果公司发现你的代码质量、你处理问题的思路、分析业务的方法、需求的维护性和可迭代性、开发迭代的效率等等都有明显的提升却依旧无动于衷，那你也有充分的自信去争取与自己匹配的待遇和适合自己的工作环境。

• 「更好的开发体验」：相信我，写一串能运行起来的代码没啥特别的，情绪上也不会有啥波动，但是当你用「更合理更优雅更高性能更健壮」的方式去实现一个业务时，你会得到至少双倍的愉悦感成就感，将写机械又平淡无味的代码变成一种乐趣何乐而不为呢？

• 你的性格以及生活习惯影响着你的工作态度，例如你生活上对待一些事的态度就是差不多就行，得过且过，那你写出来的代码大概率也是这风格，而反过来，「良好的编程思维也会一定程度地反作用于你的生活」，例如：在做业务时我们往往要考虑各种非正常情况下的兜底策略，如网络不好时该怎么展示，用户反复点击一处时怎么处理等，作用到我的生活中就是，我会在做一件事之前会尽可能考虑各种异常情况，如果不按自己预期发展会怎么样，提前做好备用方案。这里不举更多例子了，欢迎评论区交流，总之，代码写的好（这个好包含很多方面，下面详说）至少证明你的思维方式是有章可循的，同样的思维你用在生活中一定也是有好处的。

• 「效率提升」：于公司，你有更多时间处理其他需求或优化业务，更快更好地达成绩效目标，为公司业务成长贡献更多的力量。于自己，你有更多时间去学习，去散散步去健身放松一下，少加点班，保持身体的健康，持续创造价值，掌控自己的生活节奏。

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

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

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

思想素养

一、形成良好的编码习惯

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

      bad

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

  good

  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();

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

  const PAGE_SIZE = 10;
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 你的方法和组件数据依赖的变量，会不会受别人改动而被影响，如果别人也在用这个变量不小心改了是不是你的就崩了

• 反之如果别人想用你的组件，那就得改这个变量，改了就可能搞坏别的，他也不知道这个变量还有哪个鬼在用，那干脆不用组件了，自己写吧

• 再比如，你通过某种奇怪的方式将别人的某个文件或组件里的变量拿来用，那他不会保证哪天不把这些代码删掉或改掉，然后你线上挂掉了，你可怪不到人家头上，即使你用的是自己其他需求里的变量，万一产品哪天说那个功能下线了，你咋搞？

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

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

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

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

  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')可读性更好，相比于那一点点微乎其微的性能提升，显然可读性更重要。

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

  // 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结构分块且有序地编写样式」

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

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

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

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

  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，轻松搞定。

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

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

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

• 「使用eslint，stylelint检查代码」

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

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

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

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

• 「强烈推荐使用TS」

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

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

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

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

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

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

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

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

1. 「善于发现产品设计当中存在的缺陷问题，提出合理质疑，给出合理建议」

   不要拿过来需求就开始做，我们是开发人员的同时也是自己的产品的用户，要提出合理的质疑和建议，不见得产品经理会采纳，他可能会有自己的看法，但是重要的是这个沟通的过程是你向别人学习和锻炼自己的很好机会，也能避免你费了半天牛劲最后做出来没有啥效果的东西，对公司对业务也是对自己负责。

   「从用户角度看可以提出哪些问题」

   「从开发的角度可以提出哪些问题」

   即使需求评审中我们已经提出问题并协助产品敲定了需求，但在实际开发中还会遇到一些之前没有考虑到的问题，这时候有疑问要及时找产品沟通，不要想当然，不要自己做主，上线后产品再来扯皮得不偿失。

• 已有类似能力协商是否可以复用，如组件

• 或者目前没有可复用的能力，准备设计成可复用的方案，告知产品同学之后提类似需求的时候尽量往已有方案上靠

  产品一般不会为难你，类似的需求非得换个样式，换个逻辑，尤其像小程序开发这种对应用包大小有严格限制的情况，尽可能复用会是大家的共识。

• 询问是否有迭代计划，设计技术方案时将迭代计划考虑在内，将方案设计的更健壮通用

  例如：产品要做一个发券的需求，提出的需求是只发一张券，那你就要问他后续会不会发多张券，他如果说不会，永远只发一张券，那你也别信，过来人告诉你，只要「你直觉上认为某些需求场景是可以扩展的」，那它80%在将来的某一天产品会笑着跟你说咱们要扩展下这个功能，虽然咱啪啪打他脸，但是需求还是得做不是，所以你就直接按发多张券设计，甚至你再扩展下，支持把券分类，可以发多张不同种类券，当然，时间肯定也要多花一些，沟通好，排期上适当加一些工时问题不大的。

• 询问哪些内容或数据会频繁变更，把它加入配置平台可线上获取，以避免频繁发版，使需求更灵活，做成配置后可交由产品自己维护数据变更，解放一部分精力

  配置平台指的是，由单独的一套前后端来维护所有配置项，配置项包含某些功能的上下线开关、banners图片、灰度城市列表等，使用配置平台是为了避免频繁发版，保证需求的灵活性，其实就是你们项目的后台管理系统。还拿发券举例，产品当时告诉咱后续不发多张券，结果现在不但要发多张券，还要不同场景发不同的券包，百密终有一疏啊（此处自己脑补一个表情包），不过问题不大，我们基础打得好，改动可控，就是苦了后端同学。此次迭代我们与后端同学商量直接做成不同活动，一个活动对应一个券包，那不同场景发不同的券包就变成了不同场景使用不同的活动码，此时问题来了，问一下产品每个场景对应的活动码会不会换，产品说：别问，问就是会！所以，我们需要让活动码动态获取，产品可自己配置，他随时想换就换。

• 抛出异常情况：如「兼容性，不同机型不同平台效果会有差异」、「开发语言或框架能力不支持」，「网络错误时的展现」等，并给出兜底兼容方案

• 结合技术方案:

• 投入与回报比：这个根据情况考量，预计的投入和回报相差悬殊时，我们有必要提出合理质疑，现在的经济形势以及降本增效的大背景下，任何公司和团队都不愿意把时间浪费在意义不大的事上。

• 讨论上线节奏：产品要做一个很大的需求，全部开发完预估工时大概一两个月，周期较长对大家都不好，尽可能地将需求进行拆分，分批上线，加快节奏，及时观察效果，及时调整需求，追求小步快跑。

• 用户体验、交互问题：功能藏得过深，操作路径过长，按钮不明显，文案提示有歧义等等等

• 是否有足够的吸引力：是否是伪需求，不是用户痛点或用户根本不关注

「设计技术方案时代入对业务实现的连续性、扩展性、通用性、灵活性思考」

上面实际上已经举例说明过了，再总结一下思路：

• 连续性：

  即需求的持续可迭代性，「可维护性」，尤其是活动类需求，可能一运营就是以年为单位，期间会不断进行迭代，你要思考怎么写代码更「易于维护」，即使别人在你代码基础上进行迭代也能很轻松，而且要遵循「低耦合」原则，与其他需求之间「减少相互依赖」，另外「组织好代码，做好模块拆分」，代码会在迭代的过程中越来越多，觉得维护困难的时候再拆就晚了。

• 扩展性：

  思考如何才能在之后迭代时「不重构代码」，很轻松地便能将新逻辑插入进去或者连改都不用改就能够支持新逻辑，扩展性就是你在本次需求里「预留或写出了产品可能会在将来迭代的逻辑」，即使将来不迭代，写的健壮一点总归是好的。

  写出将来的逻辑比较好理解，类似产品说发一张券你就写成可以发多张券，那如何预留呢？一个好办法就是你就当产品将来一定会迭代，你组织代码的时候就把这块逻辑考虑进来，只不过将来的逻辑先不写，留个坑位，需要的时候直接在这个预留好的位置插入你的逻辑就行，这样会对已有代码产生的影响很小，在迭代时你的精力可以更专注在新功能上，减少你会改坏以前逻辑的可能。

• 通用性：

  思考怎么能让类似的需求都能够「复用」，以组件、公共类或者其他形式。

• 灵活性：

  减少发版次数，通过「配置」灵活控制线上功能。

  「TIPS」：评论区有掘友对灵活性有其他的理解，可能是因为我们业务场景不同，这里再详细说一下：

  灵活性其实更针对需要审核发布应用版本的场景，例如微信小程序等，这类版本发布时间是不确定的，要依赖平台的审核机制，尤其当应用比较大比较复杂时，光产品同学就10来个，他说我要紧急改个需求帮我发一版，另一个也说我也改一下，之前写的文案不太合适了，发版换一下...这么搞下去，每个人都说自己的需求很紧急，要求发版，那开发同学就需要花费大量的精力修改，验证，提交审核，提审了，又不知道啥时候能通过，产品一个劲催开发也没用，开发也控制不了平台审核流程，所以基于以上痛点，慢慢衍生出在评审时或开发时帮产品想到把什么可以做成配置的，可以在线上就进行改动，不需要依赖发版，让他们自己就可以随时灵活配置，基于灵活性的思考就是这样诞生的。
  时间久了产品和开发之间自然而然就会产生默契了，他也会顺着这个思路去想问题，有时会自己主动提出来，什么什么要做成可配置的，只有产品自己最清楚需求中的哪些点是需要频繁变化的，把这些规划清晰后，这极其有利于各方效率的提升。
  综上，灵活性其实是为了弥补发版时机不受自己掌控的缺陷而出现的，而好多小伙伴可能接触的业务不需要审核发版，发版时机可以开发人员完全拿捏，那其实对灵活性的需求就不那么大，因为本身就很灵活了，但是这个思路也还是有借鉴的价值的，例如，有些需要频繁变化的需求或小功能交给产品自己来维护（在配置平台上自己配置），减少产品把更新需求提给研发，研发再更改代码，然后发布这之间产生的沟通和开发成本，有时可能只是改个文案，改个id什么的也要走一遍发布流程。
  所以，灵活性大概就是这个意思，只是需要大家针对自己的应用场景做一些不同的思考。

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

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

• 文本过长溢出：如用户昵称过长，用户位置过长等任何有可能超长的情况都要考虑，是使用...还是缩小字体

  在填入真实变量值之前，先打一堆超长字符占位看看效果，可有效避免此情况

• 给用户足够的反馈：是加载中啊，还是加载失败啊，还是已删除啊，必要的情况都要给用户反馈

• 不要展示给用户白屏：加载内容时添加骨架屏，加载失败也给一张图或是别的形式

• 优化体验问题：卡顿，性能不好、数据加载慢，用户等待时间长、不够健壮，弱网环境下容易出异常等等这类问题，无论是做缓存还是并发请求还是其他办法尽可能去解决，「这种问题最能体现开发人员的水平」，你写出一个死卡死慢的页面，代码都不用看就知道你水平不高

• 所有改动都要验证，不要盲目自信，上线后出bug得不偿失

• 对自己即将合入的代码做到心中有数，仅合入但不上线的时候要做好开关控制，不要影响线上已有逻辑

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

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

什么是技术债？

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

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

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

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

1. 「突破」你的固有习惯，多去探索学习别人的最佳实践，

   例如你习惯了webpack和babel的搭配，用的炉火纯青，你沾沾自喜的时候别人已经在用webpack+esbuild-loader或swc-loader，碾压你的打包构建速度，当然，需要更高兼容性的应用还是需要babel来打包，那将来呢，当市场占比0.0001%的浏览器都支持es6的时候，别说babel恐怕webpack都可以被完美替代了，再说长远点，解释型语言开发的工具最终可能都会被编译型语言工具替代，因为天下武功，唯快不破。

   所以，不要故步自封，技术永远都在发展，人也要发展。

2. 持续「学习」，学习能力才是核心竞争力

• 每天抽一两个小时出来看看一些技术性文章，日积月累

• 学习能力也对应着你能够独立解决问题的能力

  大家都很忙，不要总想着啥都问别人。

• 关注前沿动态，保持自己不out

• 不会没关系，多查多搜，网上大神多的是，搜索时建议加上“最佳实践”，效率翻倍

  前端是块砖，哪里需要哪里搬，我曾经工作过的一个项目刚入职没几天就让我用GO写服务端代码，虽然一窍不通，但也自己摸索着写了出来，所以不要觉得“我不会，我不写”，这么好的学习机会何乐而不为呢？虽然你是新手，但是你写出来的东西并不一定就很差，因为你查到的那些代码也是经过验证的相对较好的实践，至于其中原理和细节可以慢慢去抠，不懂没事，会用也是一个重要的能力。

  但是你如果遇到那种更偏向于考察八股文的公司当我没说。

持续「创新」，没轮子就造轮子

这里说的造轮子不是让大家写一个如Vue框架之类的，如果你真的有这种能力能够造福程序猿当然好。

我们可以做的是提高自己或团队的技术影响力，当业界的工具不能满足公司业务的需求时，我们完全可以写一套适合自己的业务的小而精的框架、组件库、脚手架等，甚至还可以将成果开源出去，发布为npm包，创新的方式不局限于这些思路，只要能提高生产效率，我们都可以尝试。

另外，你还可以自己写polyfill（polyfill指的是用于实现浏览器不支持原生功能的代码），思考一下，在没有 Promise的 allSettled、any、race 这些方法之前，你是否想过自己实现一个呢？从现在起尝试开始用创新的思维，你会发现自己的潜力。

六、多记录、总结

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

• 总结bug和反馈

  将以往发生的bug记录下来，复盘故障，写好原因和解决方法。
  没事就拿出来看看，如果同样的问题发生多次，那自己要好好反思。
  如果你愿意的话可以在团队内分享，大家共同警惕类似问题。

• 总结需求评审时的漏下的点

  这些点可能是你后续又单独找产品沟通的，把它记录下来，以后再评审时避免再次漏掉，提高沟通效率。

• 总结工作方法，思路

  我现在给大家分享的内容，就是我平常总结的内容，只不过写法比较乱，想起来啥就随手写点啥，今后会更系统一些。

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

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

经验技巧

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

总结

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

这篇文章花费了我很多的精力，全文尽量避免“好好学习，天天向上”之类假大空的话，把步骤，把方法，把思路都给你列出来，让你尽可能地容易去实践，真心希望大家能够有所收获，祝大家升职加薪走向人生巅峰~

原文地址：https://blog.csdn.net/xgangzai/article/details/133326779

原文作者：傲娇的koala

最后

还没有使用过我们刷题网站（https://fe.ecool.fun/）或者刷题小程序的同学，如果近期准备或者正在找工作，千万不要错过，我们的题库主打无广告和更新快哦~。

老规矩，也给我们团队的辅导服务打个广告。