xavierchow

- 理由 1: 加班不给加班费
如果理由 1 不成立，可以用理由 2
- 理由 2：我是个人，我有个人生活，不想赚加班费

我看楼主的烦恼其实不是具体的技术方案，而是人和人的关系。
良好的团队氛围应该是可以用开放的心态一起讨论问题，其实很多方案也没有绝对的好和坏，要根据场景和其他的各种因素（比如 timeline ，扩展性，成本等）综合考虑，经常要做 tradeoff 。
如果意见不一致，就直接按 owner 的想法走就可以，谁 own 谁决定，谁决定谁负责。换句话说，楼主需要事先明确这个通信方案的最终 owner 是谁，如果是这位架构师，楼主配合就可以，事后如果方案不妥当要返工楼主不背锅就行；如果 owner 是楼主自己，架构师的方案不认同就拒绝。
最怕的楼主心里的 owner 是自己，但是老板心里的 owner 是架构师...

建议找老板聊一下，但是不要先聊技术方案，而是先明确组织关系和权责。

还在做协同编辑的话，可以考虑一下 https://github.com/instantdb/instant

来个假设法，假设那天吃饭 D 也去了，本来 3 个人吃 54 的，人均不变的话 4 个人吃了 18 * 4 = 72 元, 如果这样的话啥都不用调整。但是 D 吃完后吐回去给餐厅了：）并和 ABC 说他要把 18 元充回去给餐厅，往卡里充的 18 元对应到优惠后的现金是 18 / 11 * 10 = 180 / 11 元。
因为要公平，充钱，花钱都是 4 人一起操作的，所以 D 找 ABC 每人收 180 / 11 / 4 ≈ 4.09 元

> 技术只是工具，公司是业务驱动，技术没有话语权，需要让技术在公司变得重要，这个怎么做？
> 为团队争取了什么利益？
> 如何沟通，把想法传递过去，让老板接受去做一些业务上没多大收益，但是技术团队有收益的事？

三个问题有点关联，
业务驱动是没有错，技术在你们公司是可有可无的存在，还是负责落地的关键一环？如果没有技术你们公司也可以照样赚钱，那没什么话好说；否则的话，如果你想改变现状，可以让技术垮一次，不要去牺牲工作强度、挤压开发周期和流程去帮业务兜底，人教人教不会，事教人一次会。
老板要怪罪起来，你可以说主观上大家已经尽力了，但是客观条件（比如流程规范，时间规划等等）导致了事故频出，请管理层重视一下。另外你都会说业务比较复杂，原有的人又不敢动，也不用太怵老板换人。

总之，老板只有尝到苦头才会重视你们团队的诉求，你才有可能为团队争取利益。

同意 12 楼，尽量不写复杂逻辑，if-else 也尽量少用，多用 composition 和 polymophism 。
编码层面可以尽量用抽象的思维隔离开通用和特殊的处理，
业务层面可以让产品经理或者架构设计师尽量把复杂逻辑捋清楚或者简化/统一化，最佳实践是拿着测试 case/code 和 产品对一对。

@bclerdx 另外法定的赔偿没有 N+2 这种，只有 N, N+1, 2N 三种，平时我们所的 N 是补偿金， +1 是 1 个月的代通知金。
协商解约我们这里不讨论，法定解约的话一般就是 N ，如果是合同到期前提前的话要加 1 个月代通知金。如果违法解约就是 2N 。

@bclerdx 项目绩效行不行并不能构成公司合法解约的唯一条件。《劳动合同法》第四十条第二款“劳动者不能胜任工作，经过培训或者调整工作岗位，仍不能胜任工作的” 的解约，对于公司来说是非常耗费资源和时间的，实体要件和程序要件缺一不可，大致流程如下，有一点没做好就可能导致违法解约，所以比较少的公司会选择走这条路线。

- 具有明确的岗位要求或岗位职责说明；
- 考核制度经民主程序制定且已经公示；
- 具有不能胜任工作的证据，一般是绩效考核结果；
- 实际履行培训或调岗程序；
- 具有经培训或调岗后仍不能胜任工作的证据，一般是二次考核结果；
- 将解约理由事先通知工会、听取工会意见；
- 作出正式的解约决定并向员工送达解约通知；
- 依法支付经济补偿金等。