MiffyLiye

> Competition at larger scales naturally breeds cooperation at smaller scales because in order for a group to effectively compete with another group (large-scale competition), there must be cooperation within the group.

> Cooperation can also breed competition since sometimes the best way for the group to achieve its shared goals is to facilitate some healthy competition among its subgroups.

1L 已经指出来了两个大方向

补充一下要减少计算量，除了改进算法之外，还有其他选项

1. 降低资源消耗
改进算法
降低对精确度的要求：用精确度不高的算法（例如 Monte Carlo method ）
降低对实时性的要求：用任务队列异步处理
降低其他要求：需要综合很多因素权衡利弊

2. 提高资源供给
换更强的 CPU
加 CPU

NP 问题除了暴力穷举，还可以用 backtracking 或者 branch and bound

曾经写过 1 个旅行家的，用的 branch and bound，几十个岛屿的复杂地图在单机上算起来就很慢了

2 个旅行家，1000 个岛屿，考虑上 distributed branch and bound 吧

@sumarker 2012 年的第 3 版，因为是笔记所以和原文有些不一样。

The concepts an architect works with all day are likely to be modules, components, connectors, stakeholders, evaluation, analysis, documentation, views, modeling, quality attributes, business goals, and technology roadmaps.

The concepts an implementer works with all day are likely to be objects, methods, algorithms, data structures, variables, debugging, statements, code comments, compilers, generics, operator overloading, pointers, and build scripts.

@zhshch CI 改成 CD，让 CD 闯进生产服务器，是不是听起来就好多了🤔

API 名称和文档与具体行为匹配就好，不要给调用方错误的预期，剩下的如何处理就是调用方的责任了
此外不要把异常用成正常业务的流程控制手段

如果调用方的预期是总能得到正确的结果，则在无法满足外部期望的时候，应该 throw，尽早暴露问题并修复
如果调用方的预期是有些情况无法计算，则调用方应该用 Tester-Doer Pattern，或者调用返回 Option.Some / Option.None 的 API，无法计算作为正常业务场景，由调用方用 if else 去控制流程

至于性能，只要不是运行时频繁抛出来，几乎不可能成为性能瓶颈
如果你不是天才，就老老实实上 profiler 找瓶颈有针对性地去调，先学会走，再去学跑

服务端有 Electronic Arts 开源的 Orbit （ Java ）
对标 Microsoft 的 Orleans （ C#）

度量 output，还是 outcome?
用来发现问题解决问题提高效率，还是只作为 KPI ？