是用 git blame 还是得 git log 我不记得了。

这种问题我司也出现过。就是解决冲突的时候用自己代码无脑覆盖的缘故，和 review 无关。

解决办法是：

1. 把前端几千行代码的 js 拆开，以降低冲突几率。
2. 给前端童鞋宣讲如何处理冲突
3. 跟据 git blame 抓住无脑覆盖的提交者，杀了祭天

@fxxkgw 不怪你
https://cl.ly/3abdea5a373c/Image%2525202019-03-23%252520at%25252011.29.38.png

“ cloudformation 层拆开” 改为“ cloudfront 层拆开”

3. 可以在同一个数据层上部署多套 app 层实现，以便做非常轻量级的临时环境或属于每个开发者的个人环境

@xiaket 合理拆分是必要的。基础资源层（网络、安全组等）、数据层（ DB、存储数据的 S3 ）、app 层（ lambda/api depoyment/存 web 资源的 s3 ）、cloudformation 层拆开，并且使用不同的 iam user/role 部署。
两个好处：
1. 既然业务开发和基础架构是不同的人负责，那么业务就无权直接修改 DB 或基础架构层。
2. 仅部署 app 层可以在数分钟甚至数秒内完成。那么你们就没有对静态检查的强烈依赖了。

方法 2 超级简单，难道不是最优解？

还有一个办法，使用临时文件夹，完成操作后移动到目标位置。只不过临时文件夹总是放在 c 盘，如果这个文件内容非常大，且目标文件夹在 D 盘，就不是一个好办法了。

生产环境用 Serverless，非常酷啊。

第一个问题，能否通过部署脚本，每次先创建 changeset 在应用该 changeset 解决？

对于问题 2，这个很有意思。默认每次发布 lambda 时，是更新 lambda 的$LATEST 版本。api 默认引用 latest 版本，也就是说 restapi 引用的函数代码是动态的。而 deployment 是对 restapi 的快照，是静态的。
虽然没有试过，但我估计使用 AWS::Lambda::Version 限定一个 lambda 的特定引用，再在 api 中引用这个 version 而不是 lambda 本身可能可以解决问题。

对于问题 3，期待用纯离线方式验证 Cloudformation 模板可能要求太高了。不过 serverless 的好处是，部署本身不产生费用。如果你们能做每次部署一套临时环境并跑自动化测试，成功后再删除临时环境并合并到开发环境，是不是能够解决该问题？

快走

不信任国内的招聘网站。近几年在维护 Linkedin。

做什么用呢？控制肉鸡？

这楼里中了的同学有公司报销的么？

@CallMeReznov 上 HDR 显示器

借道问下能用 github 仓库存放蓝光电影吗。

@shimingzhoudf 不过简单来说，如果你的水表使用 http request 发送数据，那你直接吧数据存 redis 里，业务再去 redis 拿就行了嘛。

@shimingzhoudf 研究一下各种 iot 框架吧。

@loading 被门夹了的核桃还能补脑吗？

“ Steal from Apple Store ”