@jamesxu 所以要有 review 呀，review 不等于改。

@user919lx 这前后有点矛盾，真的热爱到「一周工作 80 个小时也不嫌累」的，怎么会「下了班就随便玩玩，把时间浪费掉了」。特别是第二份工作和开发无关，白天不写代码，下班也不写，时间长了手不痒么？

「所以你没办法短时间内快速对接，这也是我之前为什么一直说后端让我们对接是给我们挖坑的原因」

嗯，你也可以说：Node.js 是前端的必修课，接口（ API Gateway ）应该由前端来写，方便调试，如果需要修改 API，也更方便。然后前端只需事先告诉后端需要实现什么微服务，然后定好微服务的接口（微服务因为功能单一，所以接口变动的可能性相对来说很小，而且调试方便——微服务没实现前，前端可以 mock 实现，等微服务实现了再替换）。这样前端和后端的开发基本上可以独立进行，按照各自的节奏同时开发，可以做到超快速对接。所以我觉得 API Gateway 让后端实现是给双方挖坑。

@orangeface 跨域设置好 http header 就可以，实在不行浏览器还可以通过装插件或者命令行参数来绕过。API 接口定了，前端按文档开发就是了，如果需要调试，后端你给它实现一个 mock api 就可以。

「 js 就跟 java 后台一样的，是后端的必修课」如果不能换外包的话，你可能真的需要学下 js，顺便再学下 css，然后全部自己写。（和这样的外包合作很可能反复扯皮，最后浪费的时间可能超过你学习和自己写前端的时间……

在我看来，这些例子里面只有 sum(a, [])这个足够 tricky

@wangxiaoaer 但是换 vue 也有成本的呀。而且换了后又碰到类似问题怎么办？再换别的？

@raysonx 但是有的人并不知道 app 取自 application 的前三个，所以不能拆开读，读成 A-P-P 也不影响沟通。其实还是因为生活中这个词用的少，很多人没听过。像 iPhone 这样的词，即使不会英语的人也会念成“爱疯”或者“苹果”，我从没听人念成 I-P-H-O-N-E。

穷得女装都买不起，哪有钱买西装啊？

规范写成文档，工作任务用 ticket 写清楚。

@snoopy1024 v 站本来就有设计、设计师、字体排印节点啊。

> 早 9 晚 6
> 20:00 以前能完成的工作尽量在正常工作时间内完成，加班到 20:00 以后开始计算加班

那不是说，其实你早 11 晚 8 也不会让公司多出钱？早 11 应该爬得起吧。

@agdhole 这就是三元啊，只不过和大多数语言的三元的顺序不大一样而已。

@liyoubin37 直觉上，has_data 的值应该是 True 和 False，而不是 0 或 1，这种写法是利用了 Python 的布尔值和整数值之间的隐式转换，我不喜欢。而且习惯上，has_data，正常的思路，是先写有数据的情况，再写没数据的情况，而这种写法还要颠倒一下，看起来很别扭。

这种写法更适合条件本来就是整数的情况（因为 python 里没有 switch ... case 语句）。

像 @monkeylyf 指出的，第二种写法不能让人一眼看出来，这两个变量的取值都取决于`has_data`，所以第二种写法不好，第一种好。

如果偏爱第二种的风格，那得这样写：

calculate_func, task_id = ("rollback", sql_data.get("task_id", "")) if has_data else ("calculate", sin_id)

其实我个人是喜欢第二种风格的，并不像 @xpresslink 说的“本质上是一样的”，第二种写法，可以确保你不会无意中遗漏 else 的情况——像 Haskell 和 OCaml 等一堆函数语言里，if then else 都是第二种写法。

但是 python 这个东西就和 lambda 一样，都是设计来让你写很短的东西的。设想一下，以后可能需求变动，不止一个条件判断，不止赋值两个变量，第一种写法可以很方便地加 elif，可以很方便地多加几行赋值语句。而第二种写法呢？当然，可以啦，条件判断嵌套，元组可以加元素，但是这么搞，可读性会很差。

所以鉴于 python 的设计限制，虽然我喜欢第二种写法，但我还是会用第一种写法。

@mrzx 有段时间 ofo 小程序充值金额只能选几个固定值，最低的是 100

@Fezl 摩拜也可以卸载，用微信小程序。以前摩拜 app 有手动输入车号的功能，小程序没有，可以应对部分二维码损毁的车。现在摩拜小程序支持蓝牙开锁了，app 没什么用了。