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

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

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

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

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

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

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

你知道负责人的责是什么责吗？ 他负责他就有权利对你提要求，你只能提意见，觉得无法接受就走人，并且像楼上说的一下反思一下自己为什么连续两家公司碰到类似的问题

这是 XY 问题
你应该解决的是标准化本地开发环境或者是 CI/CD 的问题，他们和版本控制有关但不是版本控制能够解决的问题

如果你觉得需要这些技巧是因为贵司不是靠产出而是靠看屏幕抓包网络在评估技术人员的工作绩效，我建议可以试试寻求更好的工作机会

这同时也是为了逆向淘汰不称职的管理层，净化行业环境做出的小小的努力，功德无量

@crclz 如果你觉得写代码无法做到完全避免并发冲突，那数据库代码是怎么写出来的？

不同项目的需求又不一样，我不认为这个问题有唯一正确答案，我按照楼主的标题提出了一个弊端而已

问题确实都有解决的方法，你说的数据转换层也许可以解决某些问题，但为此增加的成本和风险仍然是“弊端”，仍然需要考量如果只为了这么个事情引入一层架构是否合算。而且如果问题在于整个系统的假设（比如工号唯一）蔓延到多个模块以后被打破，可不是什么抽一层数据访问就能解决的

https://en.wikipedia.org/wiki/Futures_and_promises

> The terms future, promise, delay, and deferred are often used interchangeably, although some differences in usage between future and promise are treated below. Specifically, when usage is distinguished, a future is a read-only placeholder view of a variable, while a promise is a writable, single assignment container which sets the value of the future. Notably, a future may be defined without specifying which specific promise will set its value, and different possible promises may set the value of a given future, though this can be done only once for a given future. In other cases a future and a promise are created together and associated with each other: the future is the value, the promise is the function that sets the value – essentially the return value (future) of an asynchronous function (promise). Setting the value of a future is also called resolving, fulfilling, or binding it.

区分使用的时候，他们也是表示同一个模式的两个不同的部分，不存在两种不同的模型

@tubimasky 离职 2 次呢，至少 MySQL 肯定没有 partial unique index 这么高级的

数据库做唯一的一个风险是跟不上业务，想改回代码里处理的时候有点儿蛋疼

就比如说你举的例子就很经典，员工工号似乎是唯一的，甚至能当主键，但比如明天的业务需求就可能变成：离职员工回归后新开账号（原有数据不继承）但工号仍使用原来的工号

如果你仍然坚持用数据库的唯一来处理工号，就得改全部有关联数据的地方增加重新入职的清理逻辑，可是很多数据甚至是不能清理的，一地鸡毛。如果是代码里的逻辑，直接再插一条数据完事儿，原来的唯一检查改成入职状态下工号唯一就行了

那么比起先发出去再复制，发之前全选复制是不是效率更高呢？文本框可以直接 ctrl+a,c

@Jackyxiaoc 如果你的检测和告警质量高，别人足够信任你，就可以做自动化收到你的告警自动更换备用前端库，这样可以做到无性能损耗

这个东西除了天然会慢一次跳转（即使是第二次也不能缓存所以冷热情况下都慢）还有一个具备实用性的前提：你的 A 的基础设施的可用性高于 B/C/D……当中的最大值，地理分布也要优于 B/C/D 或者至少不能差太多，否则相当于为了 0.00 几的不稳定或者跑路的风险而让终端用户每次先绕地球跑过来找你 A 一圈再去 B 或者 C 的当地 CDN

不如做的简单一点就只做可用性检测、统计和警报就行了，比如订阅 B 这家服务中国大陆不可用超过 5 分钟 /C 这家全球任意地点 TTFB 超过 300 毫秒之类的告警（用于应急处理），以及周或者月频率的可用性和速度评测（用于选择）

@mcfog 补充一下，还得资本市场别起哄双十一最高销量没了阿里大溃败什么的就做空砸盘（好像更不可能

这里的商机就是：马爸爸取消双十一，不把一个月的销量攒一天，就按普通的年末促销玩。不过前提是东哥和拼爹也要配合，别偷跑，别恶性竞争

这样整体社会效能肯定是提升的，包括人服务器宽带都没必要搞这些乱七八糟的扩容，快递车也不会着火，仓库也不会爆仓，工厂也可以平稳的生产不用被打乱计划

现在的双十一已经是囚徒困境的全社会败局了

@goreliu “桌子上的花是红色的”是对事实的描述（陈述），对事实的陈述当然有是否符合事实，也可以基于此来判断这个陈述正确与否。但这并不叫做观点

观点解释如下
①观察事物时所处的位置或采取的态度：生物学观点丨纯技术观点。
②专指政治观点：没有正确的立场，就不会有正确的观点。
（来自 http://cd.hwxnet.com/view.do?pindex=igpafcodfiobkipf 如果有更权威的地址欢迎补充）

百度百科说明如下
一指观察事物时所处的立场或出发点，二指专指政治观点。从一定的阶级利益出发所形成的对事物或问题的看法，三指从一定的立场或角度出发，对事物或问题所持的看法。
https://baike.baidu.com/item/%E8%A7%82%E7%82%B9/972684

“因为 a 所以 b”作为一个整体也不是一个观点，是一个论证过程，b 可能是一个观点，也可能不是。 我很高兴你似乎理解了我说的观点和事实是严格隔离的，同样观点和支持这个观点的论证也是严格隔离的。对事实的描述是有正确与否的（是否符合客观），对观点的论证可能是错误的（比如逻辑不自洽），但这都和观点本身是分离的，和观点无关

重新梳理一下：因为同一个观点可以应用于不同的事实，也可以用不同的论证来支持，所以孤立讨论观点的正确性是没有意义的，我说的“观点没有正确性”精确地说是“孤立讨论观点的正确性没有意义”，或者说“不存在一个有讨论价值的‘观点的正确性’的定义，因此不应该在讨论中使用这个说法”

建议你可以先想清楚什么是观点，什么是事实，什么是论证，什么是描述，注意沟通的准确性

@Aoerz 衙门啊，比如工信部好了 :doge:

@Raven316 观点是对客观事实的看法，你可以说一个观点背后的事实是捏造的，但这不代表这个观点就没有价值，也不代表这个观点是错误的。因为你任举一个你认为正确的观点，我都可以基于捏造的错误的事实来论证这个观点，如果你觉得事实错可以推导出对应的观点错，那么相当于任何正确的观点同时都是错误的

我们说“符合”一般只会说符合某个标准或条件，如果你说什么东西符合客观事实，一般是在说这个东西也是客观事实，然而观点永远不是客观事实。如果你说的符合不是这个含义，你可以解释一下