关于前端:转如何避免同事踩到自己的坑

组件化开发最佳实际

转自微信公众号：超级全栈架构师

当初前端的组件化开发基本上曾经成为支流了，既然曾经是组件化开发了，那么天然就要恪守一些组件化开发的最佳实际。

每个组件文件代码总行数不要超过 400 行

至于为什么是 400 行，这个数字是我当初在某篇技术文章上看到的，至于是哪个我遗记，然而不知为何印象很粗浅，始终记着，并且依据我多年具备的教训来看，这个数字还是蛮精确的，个别要么不会超过这个数，或者在这个数字左右彷徨，要么就是比这个数字大很多的。

这些都很好了解，既然是组件化开发，那么如果一个组件文件体积太大，存在几十个办法、几十个 data 数据 (如果用的是vue 框架)，那就阐明这个组件大概率蕴含的性能点太多，是能够被持续细化出多个繁多性能的子组件的。

太多的办法与 data 数据，对于开发者来说根本就是一种折磨，别的不说，单是给这些办法起名字以及查找都是一件麻烦事，至于日后的保护，那更是噩梦个别的存在，哪怕是当初亲手写下这些代码的程序猿，过一段时间再让他来保护这些代码，他十有八九都要如履薄冰，只管确认了好多遍，但还是会放心本人批改某个数据或者某个办法，会不会对以前某个较为荫蔽的逻辑造成什么不可预知的毁坏，于是一遍又一遍地在几十个办法与数据间测试、查看。

我已经看到过蕴含七十多个 data 的组件

这种状况还算是好的，碰到不负责任的程序猿，可能间接就嫌麻烦，轻易在一大堆代码中找个中央写下本人的新代码，查看都不查看就立马提测上线了，因为反正以前上了那么多需要，不小心搞乱了其中某个需要的逻辑，谁特么晓得？

这还仅仅是往旧代码中加新代码罢了，如果是下线之前过期的流动代码，或者删除无用的逻辑，那就更让人掉头发了，几十个办法、几十个数据缠在一起，谁晓得哪些办法与办法、办法与数据、数据与数据间有着怎么的分割？删掉了这段看起来应该是无用的代码，会不会导致其余有用代码出什么故障？算了算了，不删了，反正后端接口曾经关掉，这段代码也显示不进去，就临时放在下面吧。殊不知，这所谓的临时，就是海枯石烂的永远。

爷爷爷爷，这段代码真的是你写的吗？

于是，页面上无用代码越来越多，旧代码与新代码交相辉映，文件体积迅速增大，随着工夫的推移，原本轻装上阵的陈腐代码库，逐步背上了一个又一个历史包袱，而后被前面接手的人大骂，这写的到底是个什么货色？

世上本没有历史包袱，丢包袱的人多了，也就有了历史包袱。

每个函数不要超过 100 行

这是接下面的，想想也能明确，一个组件最好不超过 400 行，只是一个办法就超过了 100 行，那还怎么写？当然，这里的数字 100 依据我的教训，也是蛮精确的，超过这个行数，好好想下，这个办法是不是蕴含了太多逻辑，遵循函数性能繁多准则，不要让一个办法函数蕴含过多的逻辑性能，是用于拉取数据，那就让它只拉取数据，是用来整合字段的那就让它只整合字段，别干其余的事件。

如许性感的臀部啊，许可我，别用它来拉 shi 好吗？

这样一来，办法函数不仅性能明确，保护起来不用畏手畏脚，同时也可能减少办法的复用性，例如，A 办法中蕴含了拉取页面根本数据的性能，起初需要迭代，另外一个起初增加的 B 办法也须要拉取页面根底的性能，刚想复用之前 A 办法，发现 A 办法中除了拉取数据的代码，还有判断是否显示弹窗、批改数据字段、埋点等多个用 if...else... 连起来的代码，于是写 B 办法的人为了防止麻烦，或者发现根本无法复用，只好又把拉取数据的性能重写了一遍。

当然，这只是一个准则，理论需要中，如果某两个性能逻辑就是紧密联系不可分割的，你也能够写在一个办法中，总之，在参考这个准则的前提下，灵便变通。

定义方法与数据要物以类聚

指具备类似能力或者独特作用于某个性能的办法和数据，最好定义在凑近的地位，不便查找，某个性能受到那些办法和数据所管制，某个数据体蕴含哪些字段全都高深莫测，无论是当前要批改还是删除，都能做到胸有成竹，不会脱漏。

像我这么 diao 的还有 107 个

例如，生命周期办法写在一起，并且依照执行的程序，不与自定义办法混插；自定义办法也要依照各自的性能进行归类书写，例如申请接口的办法写到一起，切换页面弹窗的办法写到一起，页面上与业务无关的工具办法要放到一起，用户信息的数据都定义在凑近的地位，如果你用的是 vue，那么与模板渲染无关的变量，不要放到 data 中，既晋升了渲染性能，也易于辨别变量的性能。

  // 工具办法都放到一起
  // 金额 分 转 元
  fen2yuan(fenNum) {return fenNum / 100}
  // 批改链接协定
  changeUrl(url) {return url.replace('http', 'https')
  }

  // 用户信息的数据都定义在凑近的地位
  // 当然，你甚至能够把上面这些数据，都定义在一个大的对象中
  let avatar = 'https://avarat.com/a.png'
  let userName = '小明'
  let age = 19

顺带一提，CSS的书写最好也依照这种规定，CSS书写程序的判断根据是 css 代码影响的方面，例如，影响元素地位的属性left top，影响元素长相的color background，字体font-size font-weight，这些有同类性能的最好都写在一起。

另外，我习惯于把能引起页面回流的放在能引起页面的重绘属性的后面，对元素影响水平越高的属性越放在最后面，至于什么叫影响水平我也说不清楚，上面是我个别写 css 的属性的程序，大家能够自行领悟一下。

  <!-- position 放在最后面 -->
  position: relative;
  <!-- 而后是参照 position 进行定位的属性 -->
  top: 100px;
  left: 10px;
  <!-- 而后是宽高 -->
  width: 100px;
  height: 100px;
  line-height: 20px;
  <!-- 而后是 margin padding -->
  margin: 10px;
  padding: 20px 30px;
  <!-- font -->
  font-size: 20px;
  font-weight: 700;
  <!-- border -->
  border: 1px solid red;
  border-radius: 4px;
  <!-- background -->
  background-color: pink;
  <!-- z-index -->
  z-index: 10;

一开始我也不习惯这种略带有解放的写法，然而工夫长了就习惯了，这些属性的书写程序，齐全不必思考就迅速顺次写下，甚至有时候看到他人写的乌七八糟不合乎本人习惯的写法，还会棘手改一改。

这样做的益处是易于查找和保护，想改 width，那就必定是在这个元素css 属性序列的最后面，想改 background，那必定就从前面扫，也防止了在元素属性过多的状况下，可能导致的某个属性呈现屡次的状况，我已经不止一次在代码库中看到某个属性，例如background 写了两次的事件，一个 background 写在属性序列的上半局部，而后可能因为这个元素的属性太多, 起初保护的人没有看到那个backgound，或者太乱了也不想看，于是就间接在属性序列的最初面又写了一个。

抛开上述的益处不说，最起码这种有条理、有程序的书写秩序，对于某些星座的人来说，看着也赏心悦目，无形之中也能让本人与里面那些妖艳贱货区别开来

努力学习却不装逼，那将毫无意义

必要而精确的正文

须要长期保护的我的项目，必要而精确的正文必不可少（但不是让你写小说）

一行代码写下去，或者你三天之内还能晓得本人当初为什么这么写，外面的变量代表什么意思，有什么作用，然而一个月后呢，半年后呢，一年后呢？就算你记得，其他人呢？

我不晓得这段代码的作用是什么，然而把它删掉程序就不失常了

如果让你保护一段你早就不记得是谁写的，也不晓得到底代表什么意思代码，你要做的第一件事必定就是先看代码，弄明确到底什么意思，而后能力进行后续保护，而对于某些较为简单的逻辑代码，例如网站首页，外面嵌入了数十个弹窗，这数十个弹窗别离对应数十个性能点，让你批改其中某个 A 弹窗的弹出逻辑，并且还要与另外某个 B 弹窗进行优先级配合，光是弄明确 A、B 弹窗的逻辑你都要花费不少工夫吧？

而如果在这段代码下面就有一行对这行代码的精确正文，就算你稍后还是须要读一遍代码，也必定比没有代码时，你了解的更快更精确。

一段代码节约一点工夫，那么十段呢？一个文件的代码呢？整个代码库的代码量呢？

所以千万不要感觉正文可有可无，另外，你写的代码是给人读的，而且是技术人员，所以要用人能听懂的语句进行形容，如果你的形容能力不足以让你在一行内形容分明，那么就再加一行，总之肯定形容分明，只知其一; 不知其二的正文还不如不写，当初基本上都接自动化打包编译工具（例如 webpack），正文这些货色最初在我的项目公布阶段都会主动删掉，也不会占用代码体积。

变量和办法的命名最好有肯定的法则

同样是为了更好的浏览体验，也是为了防止过渡正文，最好的正文就是让代码本人“说出”本人的作用，即命名要有规律性。

例如，用于存储数组的变量以 List 作为名字后缀，用于某种信息的对象变量以 Info 作为名字后缀，用于判断某种逻辑的变量以 is 最为前缀，这样一眼看上去就晓得变量的大抵性能，避免出现让 object 类型的对象调用 map 的蠢事。

  const namesList = ['xiaoming', 'xiaohong']
  const userInfo = {
    name: 'John',
    age: 20,
    gender: 'male'
  }
  const isEven = 10 % 2 === 0

办法的命名同上，另外，为了更容易体现出办法的性能点，办法的名称最好不要太“宽泛”，例如拉取数据的办法，最好不要命名为相似 getData 这种，因为如果这个组件中还存在其余的拉取数据办法，就容易让人蛊惑，不会那么一下子就晓得这个 getData 到底是针对哪个数据接口的，应该进一步准确到相应的接口，例如命名为getUserData。

对于如何给变量以及办法命名这件事，存在很多粗疏的解决方案，能写两篇文章进去，就不一一开展了。

通用的性能要封装成组件

通用的组件，最好确定好性能点后，封装成对立的通用组件，通用组件肯定要笼罩大部分的通用性能点，否则还不如不要。

大一点的，例如弹窗，可能包含题目、敞开按钮、内容、遮罩层这些构造，小一点的，例如页面的遮罩层，主体包含一层遮罩款式, 那在封装这个组件的时候，就要把这些构造思考进去。

我已经看到过某个组件中，蕴含了多个弹窗，然而没有封装通用的弹窗组件，于是雷同的元素以及款式被写了好几遍，印象最粗浅的是遮罩层元素也呈现了好几遍，每个弹窗都专门写一个遮罩层款式，写过的人都晓得，单是这一个遮罩层的款式都有好几行了，何苦来哉。

DRY 准则

Don't repeat yourself

这一条能够与上条联合应用，无论你是写什么代码，需要是长期还是短期的，作为一个有素质的程序猿，你最好都要恪守这条规定

这里的 DRY，不仅是指齐全截然不同的代码字母，还在于同样的逻辑，这里举个例子，表单验证是很常见的场景，个别的验证办法都是不假思索的数个乃至是数十个if 语句顺次排列，整整齐齐声势惊人，但问题是几个 if 语句连在一起或者不太显著，难以触碰到你的 G 点，然而十几个乃至是几十个if 语句堆在一起，你难道还能不感觉顺当吗？

  if (age > 19) {// ...}
  if (name.indexOf('zhao')) {// ...}
  if (gender === 1) {// ...}
  if (weight > 75) {// ...}
  // 无穷无尽
  // ...

只有我复制粘贴得足够快，bug 就追不上我

对于表单验证这个货色，有篇文章写得很好，大家能够参考一下

独自的业务代码之间、业务代码与非业务代码之间进行必要的隔离

业务代码，以 if...else 目不暇接为次要标记之一，多个需要的业务代码混合在一起那就意味着数倍目不暇接的 if...else，如果再在这些if...else 中躲猫猫般交叉进非业务代码，那么祝贺你，现在你失去的这份代码，其实有个流传于江湖已久的响当当名号：意大利面条式代码。

隔离独自的业务代码，可能间接缩小头发掉落数，能间接升高 bug 呈现率，这很好了解。

个别的我的项目都是长期迭代而来，一个页面上可能沉积了数十个需要的性能点，每个性能点都对应几大段的办法和数据，并且这些需要还可能从诞生到当初被批改了数次，搞不好有的业务间还存在相互依赖与重叠

如果把这些业务蕴含的办法和数据全都放在一起，那酸爽……诶，这个办法是属于 A 需要的吗？如果是那为什么这外面还蕴含了 B 需要的数据？怎么这里还调用了 C 需要的办法？C 需要的这个办法批改的这个数据是 C 需要的吗？看起来不太像啊？算了算了，应该是，先这样写吧，等测试提 bug 了再说……

上班晚不是因为你需要多，而是你本人写得代码给你找的事多

与地位无关的元素汇集书写
如果页面上元素少的话，或者没有区别，然而当页面上存在大量元素，例如网站首页、商品详情页这些比拟重要的页面，就很容易感觉进去了

像 modal 弹窗、toast等辅助性元素，页面上可能存在好多个，这种元素个别与地位无关，款式设置的都是 position: asbolute 或者position: fixed;，无论放在哪个地位基本上都ok，那么倡议找好一个固定的地位汇集寄存这些元素，例如页面的顶部或者底部，并写好正文，不便寻找与批改，也不便统计，任意穿插在各种 DOM 间，保护起来都是一件麻烦事。

  <!-- 老手好礼的疏导弹窗 -->
  <ModalA />
  <!-- 领奖弹窗 -->
  <ModalB />
  <!-- 新人提醒 -->
  <ToastA />
  <!-- 资质不够提醒 -->
  <ToastB />
  <!-- 危险用户提醒 -->
  <ToastC />

删掉不必要的代码

包含有效代码、正文的代码、不必要的调试代码

做过流动页的应该都晓得，这种流动经营页寿命个别都很短，然而所要付出的精力却不少，流动下线后代码可能就间接有效了，大部分状况下这些生效的流动代码不会对页面无效逻辑产生什么影响，所以赶着进入下一个需要的程序猿们，本着多一事不如少一事的准则，很可能就任由有效代码始终存在于页面，直到地老天荒，这种事件最起码从我的经验来看，很常见

有的需要在开发阶段频繁变动，辛辛苦苦写的逻辑还没来得及被上传到线上服务器就夭折了，恼羞成怒的程序猿不甘心掉落的头发连一点成绩都没有留下，于是机智地按下了 Ctrl + / 快捷键，空想着这段被封印的代码总有重见天日的那天，殊不知，又是直到地老天荒，这种事件最起码从我的经验来看，很常见

尽管某些自动化打包编译工具反对删除相似于 console.log、debugger 之类的调试代码，但问题是在 dev 阶段这些代码都是存在的，每个人在每个需要中都退出 5 个 console.log，那么只须要十个人次，管制台上就能够呈现50 行console.log，特地是这些 console.log 基本上都是秉持着哪里有地位就写在哪里的准则，就算是想删也须要消耗大量工夫，苦逼的程序猿什么都没干，先在控制台看到几十行他人写的 console.log，而后在一堆console.log 中找到本人须要的那个，并在需要实现时，顺便又在原先几十个 console.log 的根底上，又奉献了本人的一份力量，这种事件最起码从我的经验来看，很常见。

编辑器每多显示一行有效代码、控制台每多输入一行 console.log，都将消耗肯定的电量，寰球几千万的程序员，千里之行; 始于足下，足以减轻寰球温室效应，减速两级冰川消融，可怜的北极熊宝宝和企鹅宝宝找不到爸爸妈妈，世间有真情世间有真爱，请动摇地按下backspace 或delete吧。

良好的沟通，防止有效的产出

永远不要置信 PM 说的这个需要必定不会再变了的话

PM 扭转需要咱们无奈劝阻，然而咱们能够明确现有的需要，不写有效的代码，从而进一步防止了大段正文，保住了更多的头发，不要等到快上线的时候，才发现自己如同弄错了某段逻辑，或者少写了某段逻辑，最可恨的是白写了某段逻辑。

代码容错 这个世界上不存在没有 Bug 的代码，只有你写的不是 demo，那么肯定要做好代码容错解决，因为你永远不晓得接口给你返回的是 | 还是 丨(亲身经历，此梗参见有哪些让你目瞪口呆的 bug？)

还有一些可能不叫谬误，例如页面数据的初始化，在获取到数据之前，页面上可能会渲染出 undefined 这种鬼货色，为了更好的用户体验，最好还是给个体验更好的初始值吧

恪守制订好的标准

多人合作标准很重要，无论是 jshint 还是 eslint 大行其道就是明证

对于一个我的项目来说，标准可能包含从 es 版本、缩进类型到页面构造、组件拆分等，你既能够间接照抄成熟的标准，也能够自定义标准，但无论是什么样的标准，只有制订下来，那就要恪守，不要因集体起因，与团队同床异梦。

有种效应叫破窗效应，这个我的项目中呈现了不一样的格调，起初进入的人第一印象就是标准也不是那么谨严，偶然突破一下也是能够的，而后又有起初的人看到，第一印象就是……于是不同的格调越积越多，标准也就无从谈起了，从一开始就稳不住，难道还想着半路忽然硬一下？

你能够不喜爱我的项目当初的页面构造划分形式，也能够认为路由的划分形式很 SB，但既然你在当初制订这个标准时没有拥护没有提出异议(无论是遗记了还是被忽视还是没有机会提，总之当初你没拥护)，那么当初就要恪守，或者你也能够尝试着扭转这个标准，但请做好善后事宜，例如确保在新标准制订后，我的项目中之前存在的老标准要被全副批改过去，坚定保障代码格调统一化，至于是谁来做这种吃力不讨好的事件，你懂得。

本人挑的 shi，跪着也要吃完

定期的代码 review

旁观者清，本人个别很难发现自己的谬误，否则的话也不会那么容易触犯了，无论是代码的标准还是逻辑的偏差，有些谬误如果其他人不及时指出来，咱们可能永远无奈意识到，定期的代码 review 就可能很好地解决这个问题。

不过，代码虽好，也没必要 review 得太频繁了，不然只会变成一种累赘，大家都这么忙，谁没事帮你天天 review 代码。

必要的踩坑与教训文档

这个 很重要，无论你用的是什么框架，写的是小程序还是webview，必定都存在着各种各样的坑，如果老旧代码有历史包袱不想搞的话，那么新启我的项目就要好好看待了，文档改写的就要写，不要怕麻烦，不过等到新人退出，或者罗唆是移交别人的时候，你就晓得什么叫 敲码一时爽，交接火葬场了。

小结

已经看到过某个帖子，粗心是 题主认为大部分前端做的事件，其实无论是五年教训还是外包或者实习生都能做，凭什么五年教训人拿得工资就高？

我过后也是闲得蛋疼，答复：这个问题不仅仅是在前端，后端、客户端等各种畛域都会给你这种错觉，我以前也是这么认为的，起初某天当我看到一个雷同的 bug，组长看了一眼就精确定位并棘手解决，而实习生抓耳挠腮了大半天，不仅没能明确到底是怎么回事，甚至还多引入了几个 bug 后，我就晓得人家那么多钱不是白拿的。

当然，大部分工作教训高拿钱多的人并不是仅仅是靠改 bug 快这一个起因，另外也不排除有些人原本就天才异禀，只工作了一年但能力抵得上他人工作三年的，而有些人工作三年只有一年的能力。