这是之前在上家公司使用的git规范，大家可以借鉴下。

之前使用的分支开发规范，大家可以借鉴下。

目前 Async/Await 语法不论是在Node.js 端还是在浏览器端（依赖Babel）都支持的非常好。在和一些同学沟通中或者面试人中，也能听出他们对 Async/Await 有一定的了解，按理说他们写出来的代码应该都是或者大部分都用 Async/Await 替代 Promise 。但是，在后续的 Code Review 中，还是大量使用 Promise ，不停的 then then ... 充斥着嵌套地狱。Node.js 中，相对好点，大部分同学都在使用 Async/Await 这种方式 。

Nestjs 内置了一个 cros 跨域中间件，但只能针对 origin 动态配置，且功能有限，其余都是静态配置，可操作性不强，比如，需要针对 「Access-Control-Allow-Headers」 根据请求页面的 request-headers 动态追加时，就不能满足了。

数组排序是我们不会花长时间考虑的事情之一，直到它停止为我们工作。最近我就使用 javascript 的数组，对一组数据进行排序，但排序结果完全错乱。我花了好长时间才确定哪里出现了问题。 所以，想和大家分享发生了什么以及为什么它的结果如此奇怪。

做移动端开发，最担心出现的情况是线下测试没问题，线上也没问题，但是偶尔有用户反馈在某机型上打不开页面，手里有没有真机，在云测试平台又不能 Inspect ，用户又等着反馈，简直就要疯掉。

优秀的代码能够描述清楚我们干了什么事，但要知道我们和以后接手的下任们了解到的业务信息是有偏差的。人家在读代码的可能会提出为什么在这样，为什么不那样？ 这个时候注释的补充就很有必要了，考虑到后来者可能的困惑，提前用注释交代清楚为什么这么干的背景，目的，好处，才是负责任的表现 代码注释的反对者和坚持者只是站在了不同角度看问题，我想两者是不矛盾的，该优化代码就优化代码，该注释就注释。

后台服务场景复杂，微服务的广泛使用，调用量不断增大，调用关系越来越复杂，强弱依赖的问题也导致故障的发生频次和影响更加难以控制。上线发布作为日常高频动作，参与人员多，出错概率大，据统计80%的线上故障均和线上变更有关，规范的上线发布规范可以避免低级错误，减少故障发生。

18年在去哪儿网使用 Node.js 项目经验和心得