当我们沉迷于业务代码的时候，如果只追求一个人写的爽，那么你一旦从这家公司走掉，将给后人带来填不完的坑。好在不管哪个团队都不想出现这样的问题，所以每个团队内部都有自己的代码规范，要么是其他成熟的大公司比如Google，Facebook等建立起来的规范，直接拿来用，成为自己的规范。或者是根据成熟的规范并且结合本团队内的编码习惯产出一套属于自己的规范，这是我们要遵循的规范之一。有了团队给我们制定的规范我们也不能就此放任自己，自己也应该有一套比较好的代码习惯，虽然你很羡慕弹钢琴的，指头抬起放下之间就能凑响如此美妙的乐曲，其实写代码也是一样的。代码的风格亦如曲谱的风格。

代码整洁的原则

团队内的规范只是规定了代码书写方面的规则，让团队内多个人写的代码如同一个人写的一样。
而写出优美的代码则是需要一定的设计思想在里面，让我们的代码真正达到 易复用、易拓展、易维护、易阅读，这也应该是在代码层面的追求。可以通过以下方式：

认真研究设计模式，思考每一种设计思想是为了解决什么问题，为什么能够解决这种问题，如果自己想的话是否能够提炼出一种模式。
阅读相关书籍，比如代码整洁之道，重构等经典书籍，学习如何组织代码
多阅读大神写的代码，多逛逛github，看看大神是如何码代码的
可以去各大论坛参与讨论，技术越牛的人会很开心与你分享这些东西

处理业务逻辑的经验

小至函数层面，大到组件。

分析业务逻辑，根据逻辑将每一步骤划分成最小粒度，然后封装成最小函数，若需要复用，通过配参的形式复用函数，需要考虑周到，对于后续需求可扩展。比如：点击按钮弹窗需求，可以划分为：模态窗的创建步骤（可能其他地方也需要创建模态窗的功能），点击确定的数据校验步骤，发送请求步骤，这些步骤其他地方都可能会用到，所以按照最小粒度划分一个需求点，可以达到可复用，可扩展，易维护的目的。

通常容易遗忘却很重要的地方

后端返回的值需要做判空处理(信任处理)
并不局限是后端返回的值，也包括你的函数中的入参变量等，都需要做判空（或类型判断，以免不是该类型变量，用了该类型的方法导致出错）处理。
传到后端的数据需要做校验和处理的情况（函数职责划分，校验和数值处理区分）
先拿用户输入的数据做判断，再需要发送给后端的时候再做处理（这里的处理是指将数据格式按照约定的方式传给后端，因为我们有时候用的组件拿到的值并不是我们最后要传给后端的值）
这里在将数据转为后端需要的格式，可以用适配器模式
业务中多处业务功能相似的情况
这种情况不要将所有的功能用一个函数来代替，这样做的坏处是不利于维护，如果有新需求就很难插入新的代码。按照代码整洁之道的思想，一个功能对应一个函数，将可复用的提取出来，按照代码片段的提取原则，当前模块的代码片段提取到当前模块的公共函数中，所有模块公有的函数，提取到外层公共函数中，组件和css的提取方式一样。直接引用，或者作为一个插件的方式引用。
在工作中应有意识的将设计模式思想引用到代码中
有意识拆分业务逻辑
①如果页面大的话，将页面拆分为小的模块。
②函数遵循单一职责原则，函数中不要混杂多个抽象层级，将同一级别的步骤放到同一函数中。
1）重构代码块时，分析不同函数中的功能，按照要做的事情是否属于一个性质的原则提取出来。
2）data对象挂载变量的时候，可以按照模块来划分
3）数值多用枚举来代替
4）减少函数的参数，传入对象
5）多写纯函数
6）多用设计模式

如何判断一个函数中有多个抽象层级？最直观的是该函数包含了多个代码块

未完待续…