接手前端新项目？这里有些注意点你可能需要留意一下

前段时间加入公司内一个新开业务线的前端组，由于是新开的业务线，做的也是小程序这一块，所以几乎没有任何历史包袱，组内成员都是项目代码第一手产出者

我加入的时机较晚，没有经历过最开始的初创阶段，不太清楚一开始的状况，不过听说是蛮折磨人的，需要踩坑无数，经常需要加班(虽然互联网行业加班本来就是常态，不过现在熬过初始阶段就好多了)，这让我即庆幸又遗憾，庆幸的是我不用加班那么晚了，遗憾的是，没有参与到一条崭新开业务线最开始的建立阶段，不知道以后还有没有这个机会了

不过，我加入的时机也不是太晚，项目依旧存在很多需要填补的地方，经过这段时间对代码的阅读，以及平时在做需求过程中所遇到的问题，从前端方面，暂时总结出了一些关于项目架构或构建可维护代码方面的小小经验。

组件化开发最佳实践

现在前端的组件化开发基本上已经成为主流了，既然已经是组件化开发了，那么自然就要遵守一些组件化开发的最佳实践

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

至于为什么是 400行，这个数字是我当初在某篇技术文章上看到的，至于是哪个我忘记，但是不知为何印象很深刻，一直记着，并且根据我多年具备的经验来看，这个数字还是蛮准确的，一般要么不会超过这个数，或者在这个数字左右徘徊，要么就是比这个数字大很多的

这些都很好理解，既然是组件化开发，那么如果一个组件文件体积太大，存在几十个方法、几十个 data数据(如果用的是 vue框架)，那就说明这个组件大概率包含的功能点太多，是可以被继续细化出多个单一功能的子组件的

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

我曾经看到过包含七十多个 data的组件

这种情况还算是好的，碰到不负责任的程序猿，可能直接就嫌麻烦，随便在一大堆代码中找个地方写下自己的新代码，检查都不检查就立马提测上线了，因为反正以前上了那么多需求，不小心搞乱了其中某个需求的逻辑，谁特么知道？

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

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

于是，页面上无用代码越来越多，旧代码与新代码交相辉映，文件体积迅速增大，随着时间的推移，本来轻装上阵的新鲜代码库，逐渐背上了一个又一个历史包袱，然后被后面接手的人大骂，这写的到底是个什么东西？

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

每个函数不要超过 100行

这是接上面的，想想也能明白，一个组件最好不超过 400行，只是一个方法就超过了 100行，那还怎么写？
当然，这里的数字 100根据我的经验，也是蛮准确的，超过这个行数，好好想下，这个方法是不是包含了太多逻辑，遵循函数功能单一原则，不要让一个方法函数包含过多的逻辑功能，是用于拉取数据，那就让它只拉取数据，是用来整合字段的那就让它只整合字段，别干其他的事情

多么性感的臀部啊，答应我，别用它来拉shi好吗？

这样一来，方法函数不仅功能明确，维护起来不必畏手畏脚，同时也能够增加方法的复用性，例如，A方法中包含了拉取页面基本数据的功能，后来需求迭代，另外一个后来添加的 B方法也需要拉取页面基础的功能，刚想复用之前 A方法，发现 A方法中除了拉取数据的代码，还有判断是否显示弹窗、修改数据字段、埋点等多个用 if...else...连起来的代码，于是写 B方法的人为了避免麻烦，或者发现根本无法复用，只好又把拉取数据的功能重写了一遍

当然，这只是一个原则，实际需求中，如果某两个功能逻辑就是紧密联系不可分割的，你也可以写在一个方法中，总之，在参考这个原则的前提下，灵活变通

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

指具备相似能力或者共同作用于某个功能的方法和数据，最好定义在靠近的位置，方便查找，某个功能受到那些方法和数据所控制，某个数据体包含哪些字段全都一目了然，无论是以后要修改还是删除，都能做到胸有成竹，不会遗漏

像我这么 diao的还有 107个

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

// 工具方法都放到一起
// 金额 分 转 元
fen2yuan(fenNum) {