好公司阿

之前不同的人用不同的框架，代码结构千差万别 v2ex.com/t/294276?p=1#r_3395030

react 到处 memo 哈哈哈

可以的

有时候感觉 react 作为一个仅仅视图层 当然有理由让人去搭配不同的 “搭配”
但能够有这么多种方式实现一个结果，是很令人意外的，这意味着 react app 和 react app 没什么相似之处

按照渲染方式，前端技术被分成客户端渲染（ SPA / 带路由的 web app ）相关的部分 and 服务器端渲染（直出 ssr 同构）相关的部分，后者虽然也是前端，但更 “靠后”

参考 https://baurine.netlify.app/2019/08/16/website-architectures/#有 next.js 但不一定有网络安全方面的考虑 比如 发送 react form csrf

后端和前端的分界线并不那么明显，尤其是网络安全的部分。在一些 react 教程，对于表格提交的部分，我用 react form csrf 搜索只看到零星的建议，在那些前端入门教程里我更是没看到这方面的内容。这是网络安全 101 的内容，是网络安全必须考虑的责任。

@abcbuzhiming
这就是牛油果的影响
v2ex.com/t/294276#r_3395750

useEffect 里面既能看到当前 render 的值，也能看到上一次 render 的值
https://overreacted.io/zh-hans/a-complete-guide-to-useeffect/

React 能做到在绘制后立即处理 effects — 并且默认情况下使你的应用运行更流畅。如果你的代码需要依然可以访问到老的 props

所以这篇文章给出的答案是 “使你的应用运行更流畅”，即使 cleanup 里面卡到了，它不会卡到 UI 渲染

这群人是这样的：买房娶媳妇是刚需，进大厂加班拼命是刚需，每个月 2 万贷款是刚需，但买人身意外保险不是刚需。

现在这群人在讨论什么是刚需。你需要被这群人教导什么是 “刚需”

当然可能你会又说到 “程序员的成长” 了。不，你没有成长。对公司项目，拿钱办事走人，就这么简单。这个行业不允许你成长，公司不需要你的成长，没什么好成长的。有时候自己刻意运用一些精妙技巧写出的一个非常小的 demo 都比那些公司项目里用大白话写的垃圾的价值高，这就是事实。你的成长需要成本，公司不会为你的成长付费。你不要指望在公司项目里成长，你做梦。

项目管理三要素：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 开发环境

很好的贴子