win10 + wsl2 最好的 linux 开发环境

ruby on rails 这样的框架当年能一炮而红，其推广手法上是很值得学习的。你得找个大点的 demo，用框架快速搞出来，显著提升了效率，然后录制成视频，让别人 5 分钟看完。从开发者要完成的任务出发，强调帮你全搞定。

lib 的推广则是反过来的。从自己有什么出发，强调自己填补了哪一项空白。更偏向小而美。

因为书上举的例子都不是实际的业务场景。如果给一些相对真实点的例子会好一些。接口是次要的，那只是一个解决方案。得先从问题入手，你要接什么样的需求，为什么这些需求会导出你要使用接口这个解决方案。我在文章中给了一些这样的例子 https://gitee.com/taowen/modularization-examples

我也是从小记忆力就很差。活在当下吧，少一点回忆也好。

@Martox 业务写腻了，可以来搞搞 lowcode 呀 https://github.com/taowen/awesome-lowcode/blob/master/README.md

@Martox 数数自己换方向的本钱，然后拿他们去敲下一个门。good luck

Dan 的这个列表挺好的 https://overreacted.io/zh-hans/the-elements-of-ui-engineering/

能搞出一个问题列表出来，然后持续不断地把这些问题的解决方案构建成体系是一个很好的找到下一个努力方向的手段

建议从做好本职工作开始。你现在的 day job 已经做得很好了么? 有没有改进空间? 有没有持续性的总结过去的经验，自己哪些地方是做的好，哪些规律经验是你收获了的。
如果本职工作已经做得没有任何挑战性了，意味着工作给你提出的问题，你每一个都可以列出非常详尽的地图，里面是所有可能的解法，以及优缺点。那么说明你已经没有办法从当前的 day job 里获得更多技能的新鲜感。如果对于重复性地高质量输出不感兴趣。应该考虑换一个工作岗位。而换工作最大地跳板是你过去的经验总结，而不是新学习什么知识，指望这个能给你带来更多的机会。老板都希望找一个熟手来干活的，你要转方向，也得借着过去的经验来转。

```
对内容进行审核(看是否有黄暴或者攻击词汇)
筛选关键 tag
如果附带图片,图片内容审核
如果是匿名回帖还要生成随机昵称
如果是匿名私信还要处理私信内容
处理回复者和发帖人的积分变动
如果主贴超过一定回复数同步到其他社交平台等等
数据库处理入库
```

这个例子举得挺好的。把所有的这些逻辑都实现在帖子回复这个接口里的问题是什么?如果没有问题，改进也就没有收益。楼主提出了抽函数貌似也无法复用，那还需要抽函数吗? 这里有两个关键词

* 抽函数
* 复用

为什么手段一定是抽函数，为什么目标是复用? 这种一竿子写到底的写法的问题是什么? 如果问题不清楚，直接拿抽函数这个解决方案去套，就可能缘木求鱼了。

所以希望楼主或者其他回复的人，能够举一些具体场景的具体例子，这样的写法会带来的非常具体的问题。只有针对这些问题才有讨论价值。一段静态的代码文本，没有对错好坏之分。只有带入了具体的场景里，有针对性的问题，才有讨论意义。

vscode remote

已收录到 https://github.com/taowen/awesome-lowcode/blob/master/README.md

卧室窗户正好对着个红绿灯路口，期待你的成果

恰好我今天也写了这个话题，[low-code / no-code 傻傻分不清楚？]( https://zhuanlan.zhihu.com/p/163565656)

国内做 low code 的公司真挺多的，我刚整了个目录 https://github.com/taowen/awesome-lowcode

clash 用 tap 模式 https://docs.cfw.lbyczf.com/contents/tap.html 可以很愉快的使用，不用再配置 HTTP_PROXY 这样的环境变量了。

@basicthinker 算出来了工程质量的指标又能怎样呢？能不能直接换算成开发效率，进而换算成潜在的 time to market 的改进空间。然后从 as is state 到指标更好的 to be state，怎么样才能到达了，这个重构或者重写的成本是不是可以量化。

一个解决方案本身并没有对错和好坏，要看这个解决方案是解决什么问题的。我尝试列举三个问题：

* jsx / tsx 等方案的编程反馈周期慢，一个界面的修改，从改源代码到看到效果需要好几秒钟（如果 webpack 等优化不好的话）。
* 最终用户需要能够自定义自己的界面，比如店铺要装修，报表需要自定义的仪表盘。
* CRUD 写得太烦躁了，每个都差不多。但是每个又有不同。

从这三个问题出发，都有动机自己在现有的前端技术上架一层。

* 拿 JSON/XML 等方式定义一个自己的模板语言，自己写一个解释器，然后支持拖拽。所见即所得的 GUI Designer，解决了反馈周期慢的问题。
* 给用户一个店铺装修器，生成的描述文件存数据库。渲染的时候取出来，动态执行。
* CRUD 就不用说了。解释器的方案就是动态代码生成。静态代码生成是另外一条路。仅仅是生成的话，静态动态区别不大。难点在于 20%不同的逻辑，怎么指定。静态的方案要比动态的方案更好做一些。

每个不同的问题，对于最终这个方案好还是坏的定义都不同。每个问题都有自己细微的难点，比如 Gui Designer 怎么表达复杂的响应式排版，CRUD 怎么表达差异的逻辑部分等。做出一个 60 分的解决方案，可能带来的收益，还不足以支付切换解决方案带来的成本。

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 的形式。