https://zhuanlan.zhihu.com/p/25650431 服务注册发现与调度

@muchan92 既然你使用了数据流向这个词，那应该了解一下 https://jpaulm.github.io/fbp/ 。这种写法都是把尽可能多的代码写成时序无关的形式（以某种依赖订阅的方式来描述因果关系）。从而让尽可能少的代码是 temporal coupled 的。做到极致就是所有的代码都是 side-effect free 的，也就是 http://curtclifton.net/papers/MoseleyMarks06a.pdf 中描述的 functional relational programming 。实际上也就是 event sourcing 的写法。

@Redbeanw 什么书？ https://autonomy.design/ 吗？

@muchan92 看过了你的 git 仓库。你有了解过 vue 的写法吗？ https://cn.vuejs.org/v2/guide/computed.html 感觉两者是比较类似的

https://lobste.rs/s/2ijdt3/reasoning_about_code_is_scam 所谓的让代码更可读，就是一场骗局

https://talkgo.org/t/topic/31 讲解 golang 的协程调度实现

不是把产品经理写的中文文档，翻译成英文代码的过程么？一对一翻译？

1 、商业价值问题：为什么要让最终用户定制？或者让第三方开发者定制？商业上可行吗？
2 、怎么实现动态化技术：从最简单的 eval，到实现一个页面模板的运行时解释器。采用什么技术来实现动态化，晚绑定，运行时装配。需求是仅仅要视觉展示上的动态化，还是包括业务逻辑的动态化。
3 、怎么利用动态化达到商业目的：最简单做法，让用户能够定制页面并存储到数据库里。或者回调一个 url，让这个 url 后面的算法来动态决策界面和逻辑。怎么利用，也就是怎么把这个东西包装成商业上有价值的产品。

https://autonomy.design/

robinhood 连 cash buy 正股都不允许，这个就过分了。

运维开发主要解决两个问题，发布变更，监控。这两个领域都有非常成熟的轮子了，prometheus 和 k8s 。如果不是大厂，基本上直接用开源的也就够了。如果是大厂的话，还有一些在线压测之类的活。建议小厂就不要去做运维开发了，没有多少问题给你解决。工作没挑战，自然也没成长。

https://zhuanlan.zhihu.com/p/335309652 如何让前端程序员没有后端也能完成项目? https://zhuanlan.zhihu.com/p/337185052 开个通用的 HTTP 接口，让前端写 SQL 咋样?

markdown 嵌入 html 的 table 标签 https://stackoverflow.com/questions/28508141/code-block-inside-table-row-in-markdown

user service 封装 user 可以做的一切事情，那啥事 user service 是不管的？

code review 只是一种给反馈的手段而已。如果能尽早提出改进意见，没必要等到 code review 的时候来做。cr 时候提一堆意见去返工，浪费也挺大的。

@afewok 业务架构的目标都是优化新需求的实现过程。什么是需求，什么算新，都很难采集数据。静态扫描的问题是缺少需求，以及需求变更的记录。静态结构从业务架构来说是没有好也没有坏的，需求不变，咋写都可以。

@mikulch 所有的读操作都可以放外边去，写操作中存在彼此有竞争关系的写操作放在 entity 中。例如两个操作都会修改 status 字段，把这两个写操作放同一个文件中就便于阅读。判断标准就是一次修改大概率需要同时查阅的代码放得尽可能近。

@mikulch 不应该放在 user entity 里。因为这样会导致 user 这个类很大，但是你每次修改的时候只需要关心其中很小一部分，其余的强行塞进来的功能都是阅读上的噪音。从指标上来说，这么做就是降低了自主性。user entity 的负责开发经常要去开各种不想关功能的需求评审会，提高了沟通成本，降低了自主性