有根葱，想吃火锅

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

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

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

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