随着时间的发展，人员不断流动，系统越来越大，业务越来越复制，代码越来越多，数据越来越多，导致的结果就是没人能了解全局了，所以这肯定不是最后一次故障，以后还是会有的。

活动 === 原价，笑死了。。。。

这个我算是有点经验，在某宝和某鱼上找过，基本上 100 左右一个页面，可以先让做几个看看效果，然后再决定要不要继续。

但是有个前提是最好有原型，如果原型上有交互逻辑那就更好了。

巅峰应该是 iphone 4 吧，肾机就是这么来的，当年刚出的时候炒到了上万一台，就这还一机难求。

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

省心

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

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

几万用户就了不起了，用 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: 其他修改（不在上述类型中的修改）例如：增加依赖库、工具等

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

早说啊

难道没有封版？

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