得益于React的帮助，在近半年也是恶补了一些原生JavaScript的一些知识点，学习的同时也慢慢的思考当前项目中的一些合理性，复盘后总结了一些项目上必须优化的一个点，希望和大家进行共勉，也是本次在面基时和
苏yun小姐姐探讨后的一篇收获文，如果对大家有帮助，不妨点个赞支持一下作者吧。什么样的代码算是整洁很长一段时间，大部分前端都在抱怨一个事情前人栽树，后人就真的凉了的一个事实，意思就是一个项目中的代码，除了开发者本人，其他人接手会有一定的难度。因此，如果开发的人员离职了，那么这一份代码就难逃重构的命运了，长久下去，那么项目很容易形成一个高危项目，哪天新来的同事加了一个需求后，突然就出现一些奇奇怪怪的BUG。
所以，你的代码可能看起来是这样的，
那么，怎么样才算是清晰整洁的代码呢？从字面意思上来看，在代码中整洁清晰呢?当我们进行大部分的开发规范的时候，比如Eslint，我们貌似只能做到当前如下图，整个寝室(团队)大体上的一个规划完整度，但事实上，每个人写的代码真就如代码风格一般，真就整洁清晰了？
事实证明，并不是的。Eslint给予的强约束只能让代码表面看起来不是那么缭乱，这部分和代码清晰没有任何关系，因此清晰代码大多数是由开发者产生，在不停的编码发现问题-解决问题-总结问题。
那么下面进入主题，分享一些基本的小思路。
函数注释和TypeScript为什么单独将注释排在第一梯队？
我个人认为好的代码注释一定是清晰的，它就如同商品的简介，你可以在第一眼知道它当前的一些信息，如作用，传入的参数，返回了什么。
你知道当前这个常量所指向什么，你知道声明这个变量是用来干什么的。推荐在年，如果你们的团队正在使用TypeScript，别抱怨麻烦，它对自己的代码质量提升是非常直观的。
没有注释的代码，在codereview大概率是会被刮目相看的一件事情
变量常量TS=
JSDOC=
函数(方法)TS=
JSDOC=
以上使用了变量和函数方法的示例来进行一些基本的演示。JsDOC是在团队并没有使用TypeScript时的备选方案。
你真的知道函数方法吗在写业务的时，小伙伴们很少