项目管理三要素：time, cost, scope
一个（设计 / 操作 / 安排）必须匹配你的时间估算和工期计算

抽象度过高的优点是 “满足了更大 scope ” 的情况，缺点是 如果实际上没有那么大的 scope 那么这是对工程资源的浪费

何时抽象等于浪费？就是此时
何时抽象不等于浪费？重构的时候，重新考虑所有问题，重新抽象

那么一个显而易见的结果是
1 第一版的代码总是很烂。这没有关系，这反而是好设计，是匹配当时工期计算的设计
2 第二版的代码里会出现各种设计模式 / 抽象等级比第一版高

但根据地球人类的一些经验，“第二版代码” 往往是不会出现的，是胎死腹中的。理由是：重构需要人力，而重构结果仅仅是和第一版代码（能运行）的运行效果一样。那么还重构什么呢？只有那些 long live 的项目，才有 “好心人” 来运用抽象能力给出第二版代码。这样的项目占总体项目的比例可能不到 10% ，而正是这些人总结出了设计模式这回事：写给参与 long live 项目的人 如何去重构代码。其他人：1 心安理得围绕抽象程度很低的第一版代码做事 2 去给那些愿意给第二版代码付钱的人做事，只有这些愿意付钱的人会让第二版代码不胎死腹中

it's nothing wrong to just let the shit die.

@Leonard 也可以两手准备

douban 小组发帖

@bthulu 你应该加一句 ‘.NET CLI 非常好用的命令行工具 这种 toolchain 显然对 linux 环境更友好了’

.NET 技术栈的跨平台，是部署意义上的跨平台，开发方面还是 vs IDE 在 win ，而不是 linux 开发环境

很好的贴子

try using win + g to record screen then replay it taking a screenshot

脑子发现需要脑力资源继续编，然后会 kick 到上一层 发一个 notif of 申请资源 并申请到了脑力资源，然后继续回去编
如果申请不到资源，会再往上 kick 到上一层 发一个 notif of “资源不够时候编造的东西 是否可通过 ” 并申请到了许可
// 自我允许了自我肯定
直到 kick 到最上面一层 才是 “弄醒”
// 自我允许了自我否定

还不是因为你有钱？赶紧就说自己炒股都套牢了，财不外露

直接反问回去 ‘如果是你你怎么做’ 然后看其表演，当作一个学习的机会

积累经验 下次不要有惊无险了就 OK

务实之后人家转行了 务实之后人家肉翻了

useEffect 官网示例 开销最小做法
https://zh-hans.reactjs.org/docs/hooks-effect.html

关于何为优雅
https://www.zhihu.com/question/47161776/answer/111488644#人们怎么编程: 先为对应的问题建立一个模型, 然后用代码设计出一套 DSL, 再将代码进行运算以解决问题。也就是 越符合你自己在脑海之中建立的模型，你就会觉得越优雅。这是你一个人的事，而这往往和你自己对问题的定义有关，而和问题的实际规模无关。相比优雅，对别人以优雅之名给杀鸡人推荐杀牛刀的警惕是更必要的

赚两年钱然后直接出国念书肉翻

牛油果说了 angular 和 react 一定得双修，这是白送的求职市场

流程是为了各个 stakeholder 沟通方便，不帮助增加 bug 也不帮助减少 bug ，但有助于降低甩锅率。怎么减少 bug 靠的是别的方法：可以是 coder 小团体关起门来自己讨论一下，详细列出 WBS (work breakdown structure) ，看看如何平衡 time scope cost 三者，看看如何做出 MVP (minimum viable product) 又保持 scalability 。要遵守什么 convention 。

项目走向混乱的原因有很多，有的是 milestone 划得不太对 (scope 问题)，有的是 因为一开始架构就埋雷了 后面不得不一边做新需求一边重构，有的是纯 scope 问题。

不过不要紧张， 自己搜一下 project failure rate 就知道了
https://www.objectstyle.com/agile/software-projects-failure-statistics-and-reasons

https://www.primefaces.org/primereact/editor/ react 的，UI 套装里自带 editor 了