Oliver Liu

不要在 Promise 类方法中定义 async 函数。 不要把代码写在 Promise 方法外 不要嵌套Promise, 使用 await 不要配合回调方法使用 await 不要在循环中使用await 在Promise链条上添加错误处理 不要Reject非Error类型参数 例如： Promise.reject("非法的参数，请检查") 通常我们外部使用Promise时，会认为catch捕获到的一定是一个继承于Error类的实例化对象。因为 在使用声明式的Promise的构造函数内如果出现未捕获的错误，它就是原生的错误类型，但是JS中并没有要求 我们手动的Reject参数一定要传Error实例，为了简化外部使用，这也属于一个潜规则，很多 Eslint的规则中，都会包含一个Reject只能传 ... Read more

格式 由于团队协作中各个开发者的编辑器，显示器不一样等等问题，导致在书写JS这种对空格和分号等字符不敏感的语言时格式上 偏离比较大，从而不适用各个成员的阅读习惯，这是一个浪费时间的问题。同时也不能避免一些糟糕的让人眼花缭乱的代码， 虽然一部分是使用形式上导致的，但有一部分取决于代码本身的书写格式。 所以，对于代码格式，解决的最重要的事情就是团队中的每一个人都有同一种阅读习惯，为阅读他人代码节省时间，提高效率， 甚至，从精神上可以让开发者们爱上他们的代码，因为好看的东西总会被珍惜，丑陋的东西只会任人抛弃，越踩越烂。 规则 规则是对代码质量的浅层校验，通过它可以限制一些基本的使用方式，去避免发生一些低级错误。其次也可以统一项目代码规范。 解决方案 prettier [Prettier](https://pret ... Read more

Waiting for writing. ... Read more

因为lerna在管理多个模块和项目时(发布版本，更新版本，集成工具)操作简单。不用自己手动管理互相依赖的版本问题。 提前思考： 独立的功能一定要拆分成独立的repo吗？ 最近做直播还听说后端同事在管理每个模块时，他们都是一个模块一个仓库管理，我说为什么时，他回答说，可以防止别人胡乱提交... 除了一些内部的sdk或者带有自更新的应用，我们是不是很少关注项目的版本？有没有特殊的场景？ 如果我现在有五六个项目，每个项目都有固定版本的相互依赖，比如经常见的 common, core，这些都是对通用和核心模块的解耦，我们简称基础模块。除了他们之外，还可能有一些偏业务的模块和关联性强的项目，这其中的项目和模块都引用了基础模块。 看起来只是分了几个文件夹相互引用嘛，但我们还是会面临一个工程问题，那就是，这些包是捆绑和固定式的更新，每次提交代码我都必须保证我们不得不关注这 ... Read more

内部属性在我们了解对象原型及环境变量时都有遇到过，可是毕竟看不到摸不着，很难更加深入的了解它的工作流程和作用,最近在chrome当中查看对象结构时，看到了释放出来的一些内部属性，这些以前大概都是概念，那么既然能看到，就让我们来探索一下吧~ [[Scopes]] 此属性储存在函数对象中，我记得从chrome 62开始我就发现这个属性了，具体哪个版本大家可以google,现在我们把它给打印出来看一下. clipboard.png clipboard.png 这是一个不访问外部变量的函数，所以Scopes中只储存了Gl ... Read more