按照过去的以及前辈们的经验，这种代码最好不要想着重构它！！！！！

省心

上面两个字应该是大部分做出海产品的程序员的心声吧。

嗯，这就像做一把锤子，如果你自己锤子都使不好，那么你是很难做好一把锤子的。相反如果你锤子使的特别好，想做一把自己的锤子，那还不是非常简单。

几万用户就了不起了，用 node 合适。

没有，小公司很多如果真的完全按照规范，根本不赚钱。

一天开 6 张。。。。。。。。，难道真是天才？

有句非常经典的话：

说你行你就行，不行也行
说不行就不行，行也不行
不服不行

所以自己编译是不行的，别人认可的才行。

当然是 Tcp 了

前端项目，过了一个星期，我都不知道能不能编译过。。。。。

feat: 新功能（ feature ）、新特性
fix: 修复 bug
docs: 文档（ documentation ），仅修改了文档，比如 README,LICENSE, CHANGELOG, CONTRIBUTE 等
style： 格式（不影响代码运行的变动，注意不是 css 修改）仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
refactor：代码重构（即不是新增功能，也不是修改 bug 的代码变动）
perf: 优化相关，比如提升性能、体验（在不影响代码内部行为的前提下，对程序性能进行优化）
test: 测试用例的新增、修改，包括单元测试、集成测试等
revert: 回滚到上一个版本
build: 影响项目构建或依赖项修改
ci: 持续集成相关文件修改（构建过程或辅助工具的变动，改变构建流程）
release: 发布新版本
workflow: 工作流相关文件修改
chore: 其他修改（不在上述类型中的修改）例如：增加依赖库、工具等

现在前端可以一把梭了，没必要学后端语言了。

早说啊

难道没有封版？

水合？我一直觉的这个翻译不好，但是又不知道用什么代替。

黄金，永恒的资产。

读好像不难，难的是《有感情的朗读》

开源项目，其实是做产品，那么如果做出更多人想用的产品是值得思考的问题，至于技术嘛，重要也不重要。

所以呀：国内航班提前 2 个小时到机场，国际航班提前 3 个小时到机场，也不是没有道理的。

但是我每次都是掐着点到机场的，因为熟悉了。