UI 组件就是在运行时做参数化配置，模板修改就是在编译期做参数化配置。不管是在什么时期制作参数化，前提都是高度相似。如果差异过大，就没有太大的收益了。

https://lutaonan.com/blog/declarative-programming-is-the-future 未来属于声明式编程。推荐 strangeloop 2019 的一些视频，主题是 declarative programming 的，尤其是 https://www.youtube.com/watch?v=MiiWzJE0fEA&list=PLcGKfGEEONaCToXJZ4Uk1NVW70U3C-Im-&index=53 这个才是未来主要的 computation 的形式。

业内比较先进的有 firefox 的 rr https://github.com/mozilla/rr/wiki/Recording-Firefox 和微软的 time travel debugging https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview 之前在滴滴做过一个业务上用的简单的工具 https://github.com/didi/rdebug

难点还是比较多的，不仅仅是数据量和性能问题，还包括什么叫一个完整因果链的 session 的问题。React 有一个叫 Interaction 的概念 https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16 做 tracing 的时候都需要这样的东西。这种上下文关联的事情不是纯技术手段能底层解决的，要侵入到业务代码的编写方式里。

@beizhedenglong 是一个商业产品

@beizhedenglong 还有很多其他的黑科技，比如把 TypeScript 编译成可以持久化的协程。工作地点在北京西二旗，薪酬待遇见招聘链接： https://www.zhipin.com/job_detail/?query=%E4%B9%98%E6%B3%95%E4%BA%91&city=101010100&industry=&position=

@beizhedenglong 可以了解一下我们团队，用 TypeScript 在造一个大轮子 https://zhuanlan.zhihu.com/p/74675445

english version: https://medium.com/software-engineering-problems/out-of-the-tar-pit-another-approach-b3e701e089ee

社会制度就是这么设计的： https://movie.douban.com/subject/2975682/

@xrlin 不卡，intellij 都能跑得动

lg gram 15 寸，小米 45w 电源，windows 10 + WSL + Ubuntu + VcXsrv 终于完美了

@GuuJiang 应该不是完整实现吧？看代码量并不大啊。

https://zhuanlan.zhihu.com/p/47211041 系统性地讲了一下协程在表达逻辑方面的能力，这是第一篇

更多信息可以参考我在 medium 上写的文章： https://medium.com/software-engineering-problems

没有什么是“应该的”。你要先明白自己要什么，才知道什么是“好”的。按照我的视角，好的模块划分的标准是

1、首先要让模块负责。从业务产出的角度来说，有可衡量的指标。你可以是按所谓的“功能”分，比如把处理 RPC 的中间件拆分成独立的库，让他们负责稳定性。也可以按所谓的“业务”分，比如这个模块就负责商品页的流量转化，如果流量转化效率高，他们就干得不错。
2、其次是让模块之间具有相对独立性。如果可能，一个需求需要改动的模块越少越好。参与的模块越少，就参与的人越少，就沟通越少，所以效率就会越高。
3、最后是鼓励模块的复用。好的架构是具有前瞻性的，可以今天的投资，明天拿到更多的回报。比如搞一些提高开发效率，搞一些和领域相关的中台沉淀的事情。

accountable >> autonomous > amortization

公司的代码没法写。自己的代码肯定要写。

这不是晚期么

@amon 只是把过去观察到的问题总结了一下。分析清楚问题就已经解决了一半。接下来会把这些问题展开。

@neoblackcap 就事论事，说说 module 有哪些相比中心化管理的缺点。