@doyel 可以试下饿了么等平台的跑腿之类的。

一直在用。但是稳定版「 Remove Python 2 support 」， 糟糕，看来要换工具了，头疼。

以下回复仅代表个人，不代表雇主：

> 都备案过了为什么还要再备案一遍

接入备案和备案不一样，详见通知邮件中的「常见问题」

> 一下连着发了 12 条一样的邮件

邮件系统出故障了，向部分海外邮箱群发邮件时会重复发送，初步怀疑是连接邮件服务商的网络连通性问题引起的重试（似乎 mailgun 没有自带去重功能）

> 简洁的像假的

因为底层 IaaS 商并不提供相关 API （坑），备案和接入备案最终还是得人工把开发者提交的资料再手动提交到底层 IaaS 商的备案系统，所以就没有做一个比较完善的备案系统，而是简单做了一个表单，供提交备案所需的资料。

> 还提交不了任何内容

具体碰到什么报错么？注意开发版只能在接入备案分类下提交工单，如果选错了分类就会报错无权限提交。

> LeanCloud 社区也没有任何帖子要求更新备案

感谢反馈。刚刚在社区发了一个帖子 https://forum.leancloud.cn/t/topic/24998

> 不知道现在规定有没有改
> 按以前的规定是这样的：你在 A 接入备案了，到 B 去使用 CDN 、对象存储这类服务不用再接入备案，但你要在 B 使用计算类服务比如服务器、云函数你就还得在 B 再办一次接入备案

现在的规定还是这样，CDN 和对象存储（这里的对象存储对应的是 LeanCloud 的文件服务，所以在 LeanCloud 绑定的文件服务自定义域名不需要办理接入备案，LeanCloud 的结构化数据存储不算对象存储）

这不是福利活动，是刷赞活动啊

> 大家用了多久习惯了双拼，并且双拼在大家的感知中对速度的提升有多大（当然我知道存在理论上的速度优势），以及在输入感觉上是否确实比全拼会更好，权当抒发感觉或吐吐槽

很久以前转了双拼所以已经记不得了，好像是一个月左右。
双拼可以节省按键次数，省手指。

@512357301 发邮件只是给别人提前改的机会，虽然别人其实也不一定清楚，但总比连改的机会都没有好。最好的还是保持兼容，但另一方面保持兼容也意味着增加了一笔技术债。

> 遇到一个问题，需要导入指定长度的英文单词

要写 woodle 外挂？ github 上不少。

＞　如果不拆包直接传递元组本身的引用,就会报错

就是语言为了实现上的简单性，没有做这个转换而已。
我不记得有没有语言会做这个转换的，只能强行举个无关的 `*` 号的例子。golang 里面 (*(*x).y).z 可以简写成 x.y.z （指针自动解引用）。 `sum(my_tuple)` 理论上也可以自动转成 `sum(*my_tuple)`，只是 Python 没有做而已。

@pursuer 可以匹配呀，就看语言设计的取舍了，愿不愿意做复杂的解析逻辑。

@rabbbit 真正的不加接口是设计良好，该有的接口都有，足够正交，易于组合（让别人可以自己折腾）。虚假的不加接口，就是凑了一堆接口就结束了，反正又不是不能用（折腾别人）。

订单状态也拆开应该就是 @markgor 在 117 楼说的订单状态是会变的，而订单信息基本是不变的。

后端拆细没问题（如果后面的服务确实是分开的话），前端写起来麻烦，但是好处是后端出故障的时候前端不会全挂。订单状态变动比较频繁，出问题的可能性最高，单独一个接口，那么它挂了，用户只是看不到订单状态或者看到的是可能过时的订单状态，其他功能都不影响。

另外，如果网站要保证离线可用（包括用户的流量非常贵，要尽可能省流量），前端是要自己缓存信息的。那么这种情况下，订单状态的缓存策略和订单信息和缓存策略应该是不一样的，这种情况下，后端接口分开，前端反而好处理。

@RichardYyf 不习惯烟味换工位很正常，不用顾虑太多。其实很多时候换工位才是最好的解决办法。

抽烟可能不是一个太好的例子，因为现在大环境是禁烟，然后香烟本身是有害健康的。

换个例子就更清楚，比如键盘，可能有人特别喜欢青轴，有人听到很响的键盘声特别烦躁，不换工位的话：1) 键盘声是白噪音，别人没嫌吵，你多听听就习惯了，实在不行戴耳机（可是我就是不能习惯，一直戴耳机也不舒服啊） 2) 喜欢青轴回家去用，办公室里别人都用薄膜，你就不能换薄膜么（可是青轴打字爽啊） 3) 换茶轴或红轴（打字不如青轴爽，不过还凑合；还是有点吵啊，不过可以忍受）。所以不换工位就做不到让双方都满意。如果可以换工位，用青轴的和其他用青轴、以及对键盘声不敏感的人坐一起，对键盘声敏感的人和用薄膜键盘的坐一起，那就皆大欢喜。

> 成员也可能交叉在多个项目里没有时间来做这个事情

所以不一定是积极性的问题，积极性不够就倾向于少做事，但没有自测就强行交付下一环节最终并不能省事（工作再不积极，核心链路不通的情况下也还是要改代码修 bug ，到头来并不能节省自己的工作量，可能还增加了和其他人来回沟通的工作量）。其实也有可能是工期估计不准，毕竟预估开发时间不太容易，交叉多个项目那预估的难度就更大，导致因为时间不足并没有按计划的时间点做到能够交付的程度，然后仓促交付给下一环节。如果是这个原因的话，一开始排期的时候需要明确交付的标准，避免低估需要的时间，另外有条件的话多留余量应对预估误差。

> 提了一些问题然而 A/B 两位同学也都视若罔闻

「视若罔闻」有可能是对方手头在忙别的事，想等回头再看但后来忘了。可以过段时间再 ping 一下。实在不行还可以线下沟通或者电话沟通（如果是远程工作的话）。

> 我刚加入这个团队也不好直接说什么，最后测出来一大堆客户端 bug ，QA 也有一些不好的反馈。
> 甚至担心因为主动约他们沟通上面提的问题会让他们觉得我有“领导他们”的误会

所以不说的话，问题并没有自动消失啊。
感觉这个团队的氛围还是不够扁平啊，这些担心背后的预设似乎是改进和优化流程是资格老的人、领导别人的人的事情。
每个人都可以提议改进和优化流程，并在利益相关者充分沟通、达成共识的情况下推动改进和优化的实施，毕竟流程和每个人的工作息息相关，好的流程也能避免很多问题，对产品和做事的人都是有益的（毕竟就算不影响绩效，三天两头搞出问题也容易怀疑人生，不利于心理健康）。

----

上面是正经回答，下面歪楼放飞自我一下，发表下个人的暴论。

我其实非常赞同 16 楼的观点：

> 钱多 结贴

理想情况下，积极性无关紧要。强调积极性，是因为缺钱。

坐飞机的时候感觉有些空服人员工作并不积极。但是，飞机起飞降落的时候，每个舱门（包括紧急逃生门）都有一个空服负责检查，需要通过内部电话报告每个门状态都是正常的。众多类似这样的流程保证了飞行的安全性。想象一下，如果缩减成本，一个空服负责检查所有舱门，甚至个别舱门有点故障，需要额外的非常规的检查步骤，甚至每次还可能出现不一样的情况，要根据具体情况自行判断，那就非常依赖空服的积极性，如果工作不积极，那可能是会出大事情的。

客户端 UI 的自动化测试成本比较高，所以很多公司为了省钱都不会去做。如果有客户端 UI 的自动化测试，根本不会出现 QA 拿到「核心链路不通」的 Demo 这样的事情，在自动化测试阶段就挂掉了。

话说回来，这公司还不是特别缺钱，至少有 QA ，QA 在测试环节挡住了不能用的版本发布出去。而更缺钱的公司，那是连 QA 也没有，有的产品从头从尾就是一个人在负责，那就必须非常强调积极性了，不积极不行啊。但是这种积极性只是没有办法的办法，而且人总是难免犯错的，积极只能降低犯错的概率。

刚试了下，可以导出，应该是修好了