？你和产品说测试没测出来就不是背地说别人了？
测试被捅刀子了去和产品解释情况反而变背地说人了？

这事情就是你不懂怎么做事情。平时被口头改需求恶心了那么好的机会，和产品把逻辑对清楚了，这时候就该和产品说清楚啊，你改需求太随意了导致容易出这种错啊，下次改需求要同时维护文档啊，要周知测试啊，想怎么怼怎么怼，你偏偏怂不敢当面说，扯不在场的人乱甩锅

没有同感，我要是哪个仓库 fork 比 star 多而且还没有合理的 pr 的话，我会反省自己找错受众了，怎么就惹上一群用不来 github 的人了

还有，文章里截图的 repo 不是什么开源软件，虽然放 GitHub 没啥问题，但我还是希望这样的 repo 越少越好

fzf

@TomVista
我不太理解什么叫用 graphql(或 restful)实现数据库操作
你觉得不可行，但找不到理由为什么不可行的话，可以倒过来想想，这样做（比其他做法的）的好处在哪里，沙子造芯片是可行的，机器码写业务也是可行的

观察两家知名的 graphql 接口服务商脸书和 github，他们用 graphql 都是非常合适的

- 他们的后端（开放）接口 consumer 数量巨大，协作困难（不如说因为是提供给大量第三方，不可能单点和某家 consumer 协作）
- 支持更多的 consumer 对他们是有利的，形成生态的，他们有动力去改善 consumer 的开发体验（ DX ）
- 他们的业务核心逻辑和关系稳定多年不变（脸书的用户、好友关系、feed 流，github 的 repo、star 等），又有大量的字段、自资源、关联等情况，又愿意或者需要提供这些能力给外部

好的，所以国内几乎不存在满足上述条件的公司，就算国外我也想不到第三家了

哦，对接部门多到爆炸的大公司的某些核心部门的内部 API 网关可能也还能考虑用吧，但这种用了也不一定会有分享让外界知道

不知道楼主的整体是否很好地总结概括了这本书的风格。如果是的话，不推荐读这样的书，窜味儿，难受

别说出来啊，进了培训班面试手册怎么办，快删掉快删掉.jpg

你觉得 sofarpc 了不起，有解决 bug 的 pr 就很厉害了，面试官不那么认为

如果你不甘心，下次可以说具体一点，我解决了 sofarpc 里一个如何如何的疑难杂症，虽然我并不推荐

2FA 是帐号密码的一部分，如果光凭证号密码就能关闭已经打开的 2FA 岂不是没有意义了

找客服吧，应该需要其他方式验证账号的所属权，之前处理过 github 丢 2FA，是通过关联的 ssh pubkey 验证的

不不，不是你的谷歌云被攻击，而是你从你的谷歌云攻击别人

我就是因为没有同步功能所以用谷歌的，绑定时自己把绑定用的二维码（其实就是个 uri ）离线备份就行

@a62527776a next 仍然多余

提供这样一个不上不下的功能没啥意思，不如给用户完全控制框里的渲染和逻辑的方式
随便说几个场景吧：
a)取消也要异步 block 住
b)block 过程中用户希望在按钮上显示菊花 /其他文字
c)block 过程中用户希望改变框内主体的展示，变灰加字进度条都有可能需要
d)失败场景可能的需求有：框仍然消失 /框消失并通知外部改变状态 /框保留按钮变回可点 /框保留按钮状态改变 /弹第二个 alert 框告知用户失败并组合上述任意交互等等
不管你的默认行为怎么写，总会有其他需求，诱惑你再加更多 option 和 callback
问题的根源可能在于你没想清楚自己的组件的边界在哪里。我能猜到加这个 wait 的机制能满足你多数的需求，提高你的效率，但放到开源组件里，这个选项满足别人一半的需求，逼迫别人要么魔改 hack 要么不用，就是“不好用”的组件了

总体还行，挑些毛病的话：

已经 promise 和 async await 都上了还用 wait 这样的回调参数来做“后续干啥”，甚至这个回调参数里还有个 next callback 看着难受

活动页弹个窗这种小事还带上 vue 难受

有根葱，想吃火锅

产品要插手技术（架构）设计甚至是实现，相当于兼职架构师，你可以把他当架构师来问，问不倒的话就真的按他说的做就是了

基本不认同楼主所有观点，从第一句（技术人员多数喜欢技术？ 极少数才是）到最后一句（怜悯能力卑微的领导？ 怜悯什么是能力都不清楚的自己吧）

他说的都对，我们都是新一代的纺织工，都只是等着被淘汰，只有他才是新世界的救世主

@honmaple 不一定是技术上的问题，也可能是你在面试 offer 入职的过程要对下家的技术水平没有做好一个基本的把握，也可能是你其他方面的一些缺陷导致你无法拿到更适合你的技术水平的公司的 offer

关于技术上的问题，你可以和负责人沟通，提意见，如果他的回复中有东西让你学到你就好好学，如果你认为这方面难以沟通无法理解，那就默默按他的套路来做事，出了问题他是负责人，让他来组织怎么解决就行（说不定他就能比你更轻松的搞定呢，谦虚点跟着学咯）。当然，同时可以在外面看新的机会，但前提是你得想明白，真的就是公司不行负责人不行，你的问题真的是不会挑公司，否则问题大概率循环出现

说架构的话题的话，架构的大多数问题都是权衡和资源分配，没有免费的午餐，扩展性是要用初期开发速度，团队人员能力，上手难度等等来换的。如果给我一堆低水平的开发让我带又禁止我换人，那我就会考虑教会他们怎么在一个良好（而不简单）的架构下写扩展性好容易长期维护的代码合算，还是快糙猛简单直接的结构，就靠人工测试，不断重新堆积面条代码来实现需求，也许反而更合算。这种时候我设计架构的目标就是不看扩展性，只追求低耦合，确保任何一坨面条坏了都尽量少影响其他面条，能更便宜地堆人力上去重写

@hantsy ？这和平庸还是优秀有什么关系，我的观点是责任和权力对等啊

负责人平庸，那是老板的问题，最后输出不佳也是老板拿钱兜着，楼主觉得自己优秀所以受气，那还是自己面试入职考虑不周

负责人优秀，楼主无法理解和沟通导致误解，那还是楼主的问题，尤其是连续两次说明不是偶然，所以我很赞成让楼主自己反思问题在哪里

我只说楼主是因为这里只有一方的观点，在这里评价负责人或者公司既做不到客观又产生不了价值和意义，评论楼主则有可能让他变得更好，不是吗？