flyingghost

盲猜，大概是集成了多个应用，每个应用都带了一套自己的运行时框架。/doge

ForkLift 很多年。唯一苦恼的问题只在于怎么把 finder 从程序坞里清出去。

多租户，每进一个体验者分配单独的账号、单独的库、单独的容器、单独的环境等。具体在哪一层隔离看方便程度。

@zhaol #55
我不是说正常程序员应该不出 bug ，我也不是说团队里每个程序员都水平非常高。
但我想在软件工程里，开发测试产品都应该以逻辑严谨思维缜密作为目标，而开发在这一点上应该是最骄傲的才对。
做错了，就是做错了，就是水平不够。每个人有每个人的能力瓶颈，认识自我接受自我也是一种结论。但这不代表我鼓励因此对错误麻木。犯错，至少应该愧疚。

而且 bug 不仅仅和能力有关，还和性格有关（这个比较难改），还和工作方法有关（这个非常容易改进），还和思维方式有关（经过训练也可以改进）。工作方法和思维模式，我觉得也算软技能的一种。
团队里有粗线条的爱钻研的同学，写出 bug 连冒烟都过不了，气得测试叫呱呱。于是后来强调自测，强制给开发设底线，同时尽量让该同学做技术调研，少写业务代码。
有细腻的妹子，技术很一般，就 CRUD girl ，但真的很少 bug 。这大概归功于性格，很难学。
还有个奇葩男子，水平中上，产出率中，特技是不管写什么代码，永远零 bug 。月度总结报表里永远是零，偶尔才出个位数 bug 。。。后来他的工作方法和思考模式总结出来全组推广，都学学，都提升提升软技能。

谁说写 bug 就合理就不值得努力提高水平？

1 ，测试测 bug 是本职工作。能被测试测出 bug 的开发，只能说活该水平不够。
2 ，开发应该带着感恩的心。我司线上生产事故测试必背大锅，比开发比例还大。测试是开发的守门员，没有测试，那只好开发自己背锅。让开发自己选。
3 ，需求层面打不过测试的，只能说开发不熟悉业务。开发天然是既了解业务又洞悉本质的岗位，正常公司是产品引导、测试守门，但没有任何人能在宏观或微观层面打得过开发。
4 ，如果由于理解偏差导致的“bug”，请修改项目组 bug 定义和分类。开发常见几种觉得委屈的需求 bug：
一种是讲的不够细，每个人有每个人的理解方式。大锅扣给产品，请描述好需求。开发的责任在于：讲得不够细就多问，又闷又自作聪明的开发太多，又谨慎又多嘴好问的开发太少。
另一种是开发犯了一些常识性的错误。例如产品说这里要有个密码框，开发直接文本框明文显示了，测试认为应该掩码不能明示。如果一个 bug 是公认的常识，那不理解常识的一般是经验不足，请补。
5 ，开发不私接小需求。小需求、小变更要同步，大变更要重走完整流程。这个也是很常见的委屈“bug”来源。
6 ，某些测试可以担当 QA 角色，对于设计、体验、技术方案都能提出见解。挺合理。团队就应该人人可发言，只要有道理，即可采纳。人家水平高啊。但在一些 UI/UX 、运营等非技术角度，开发缺位是常态。太钻技术了，太少抬头看宏观。我是期望团队内所有人都应该专精本职工作的基础上具有一定跨界能力，尤其产品本身的理解，和用户角度的理解。这方面产品容易缺的是技术理解，开发容易缺的是产品思路，反而测试较容易做到期望的“一专多能”。

总之，综合来说，开发真的是天然最强势角色，至少是最容易达到。被打压出普遍委屈和不满，只能说明。。。项目经理 /团队 Leader 的锅最大。。。

“苹果双卡两个卡都会没信号”
我没看懂这个前提是什么意思。。。
我的双卡正常双待并且都可以收到短信啊。
是我理解错了吗？

cmd 窗口点击黑框区域后获取焦点会导致进程卡住。
我一直没明白这个 bug/feature 的设计意图是什么。

一个用户标识符：
应该可以唯一确定一名用户。openid ✅
一般是静态不变的。openid ✅

一个认证过程：
微信内动态获取 openid 的过程 ✅
手填的 openid ❎
静态缓存的 openid ❎

一个认证结果 /后续请求凭据：
有合适的短暂的生命周期。token ✅，openid ❎
能够充分证明请求者合法性。token ✅，openid ❎


OP 你把身份标识和身份认证给搞混了。

进页展示一个透明 1s 后渐入 100%的动画 loading 。