钱，凡是离开自己的手，就要当作没了。 那种说，“过几天还的”，就是在公然要你给钱，别指望能还你。

怎么感觉讨论跑偏了。

就我个人而言，一些情况下我会主动加班，比如觉得新功能很有意思，或者实现的方式能让我学到一些东西，或者不可抗拒力导致的紧急需求或问题等等。其它时候加班，我都是不情愿的，尤其是那种很 sb 的需求，或者需求改来改去导致的工期延误。个人应对方式是向上管理，明确告诉 PM 要加时间，上线延期，我们公司还是比较 nice ，挺少加班的。

假设，我处在的公司要让员工加班，没事做也要加班，不然就会觉得你很闲。我大概会做如下措施：
1. 早点找下家；
2. ”磨洋工”，做功能我求质量，慢慢来。写完、自测、提测、修 Bug 的时候我做一些代码清理甚至是重构。高质量的完成。（但还是早点找下家）
3. 摸鱼，这种就真的“磨洋工”
4. 穿插点一些别的事情，如实现各小工具、学点什么东西。
5. PM 如果看到你的反馈后，很快又改需求，那你做好了东西就先晾着，帮他冷静一下。那种做了几版，最后选择第一版的人，职业能力真的不怎么样。不要有负罪感，你这是在帮公司省资源。个人最讨厌需求没想好，胡乱挥霍资源的产品经理。

当然，还有一些情况是无解的。就是上面常态化催着你加班，提前完成功能开发。这种我只能接受在开拓新业务，需要抢占市场的时候的加班。不然常态化打鸡血，真不是人能做到的。

有没有链接发一个？

预期的情况有两种：
1. 当你需要改动的时候，一定会产生 diff
2. 如果没有改动，则不能产生 diff

我的方案：直接用 JSON.parse/stringify 。你说的那种情况应该只有在原本的 JSON 字符串不是用 JSON.stringify 的情况下会产生。你可以先统一把已存在的文件全部重新格式化一遍，后续就不会产生 diff 。

@wdssmq 是哦！ 不过也确实少用了。

歪个楼，话说各位 js 们写业务代码还会用到 call/bind/apply 吗？我个人观点：js 里的 context bind 跟 C 语言里的 goto 一样，需要用到的场景已经很少了。

欲望变强了 + 不容易遇到契合的另一半 导致了 大部人觉得结婚不是必须的。

我总感觉一般人讲的“隐私”都是一种幻想而已，没人在意你的信息的时候，才有一定的“隐私”可言。

首先，错在这些云服务商没有一个大大的 alert 弹窗告知用户会被扫描。 其次，凡是放到脑袋以外的信息，其“隐私”都是很脆弱的，就像面壁者一样。云服务器，不管你怎么加密，只要你需要在云端解密，那你的信息都是可以轻易被窥探的。楼主如果真的在意，分级的处理这些隐私信息。普通人用云服务器的最高级的加密方案，应该是只在本地加解密，云服务器只作为转发存储。基础方案是简单加密下，不要被攻击者轻易撒网扫描到。

ps ，v2ex 的 ctrl + 回车竟然是直接回复。。

分享下个人的一些做法和观点：

1. 把机械的、高频的操作快捷键化、命令行脚本化。过于复杂、多变的需求如果没时间就没必要做了，当练手可以。
2. 谨慎脚本化生产环境的操作！举例：你可以实现个一键部署测试环境的脚本，但是生产环境要特别谨慎。生产环境的脚本需要更系统、测试更完备。
3. 学习下如何扩展自己所用的编辑器 /IDE 。未必需要熟练对应编辑器的插件开发，很多时候可以简单的转化成调用外部命令即可。
4. 个人 emacs/vim 的快捷键都用，其实还挺香。emacs 的 ctrl+a/e/n/p/f/b alt+f/b 在命令行、系统各类输入框中基本都支持（ osx ）。之前 vim 光标要切换到上下单词，上下行等很小的操作也需要切换模式，不然就要按上下左右。吸纳 emacs 的基本快捷键后，感觉爽了很多。
5. 不要太折腾，优化工具需要循序渐进。编码更重要的还是脑力活，很多情况下思考才是效率的瓶颈。只追求字符输入快的职业，感觉像是刷单手，狗头。

重发：

把机械的、高频的操作快捷键化、命令行脚本化。然后学习下如何扩展自己所用的编辑器 /IDE ，现在流行的 JetBrain/VSCode/Emacs/Vim 都是支持

林北不信

38.5 高烧。。。。。大哥，多喝热水。

“你肯定不是一个资深的 ios 开发，资深的 IOS 开发早就当死马了 不会抱怨 XCode 难用” 狗头

用 vim 快捷键的我，每次不能用 vi{ 快速选中整个函数，表示很痛苦。python 未来能不能兼容花括号？

强制至少 loading X 秒的体验会好一点，效果稳定。比如，至少 loading 0.3 秒，如果 0.3 秒后页面还没准备好，那就继续 loading 。

@testver 你批评吐槽其他国家领导人的时候，没什么人会反问你，你做到了吗？你有资格吗？

为什么？因为一般人不会是一个国家领导人。这种吐槽评论，看着就好像合理一点，事不关己 茶余饭后。

v 站应该算是偏技术人员的社区，所以当你只会吐槽评论的别人技术文档不全的事实的时候，别人（包括我）总不禁要问，那你做到没有？这也很合理。

我不是说责任全在打工仔身上。

分析下现状的根本原因是，市场变化太快，主要追逐快速能出成绩的目标。今天看似核心、牛逼的功能，且不知明天会如何，你写什么文档，写什么 UT 。 这种氛围下产生的文化，就变成什么都是怎么快怎么来。写文档慢且有效期短，官网留个 QQ 群则很简单，当你的团队在起步的时候，你选择什么方案？只怕你也不得不选择 QQ 群的方案。当功能稳定、用户多了之后，完备的文档、demo 自然收益会更高。

做事的方式是会有惯性的。自上而下都是如此，哪天你们公司的产品真的稳定、用户量大了之后，只怕大部分人都还是改不了起步时，那种急躁 或者说 所谓“敏捷”的行事风格。在座的诸位，能在这个时候尝试推进这些规范、文档的建立。不过很多公司可能都不能渡过这个沉淀期，盲目扩张完全用订单指导开发，不断增长内部沟通成本，对外也在提升与客户的沟通成本，那就只能 gg 。

大家讲话不要说得那么死。从一个前端的角度反驳几个楼上说的。
1. 反驳 vue 垃圾。鄙视 vue 的人，说真的 vue 算是做得比较不错的框架，快发快捷，不用做太多性能优化。你要说 vue 被一堆人盲目推崇 带节奏，这只能说你傻，这关 vue 什么事？难道尤雨溪花钱雇他们去到处吹捧的？试问这几年出来的东西，哪个没被这样带节奏？ nodejs 刚出来的时候，好像没有哪个东西时 nodejs 替代不了的。react 的 redux 到现在还有人在吹，官网也在推荐，用起来一坨屎。flutter 刚出来的时候，走到哪里都是 flutter ，一统天下的感觉。你真是有点经验，就会知道，没有什么是无敌的、全能的。另外，vue 的文档算写得不错全面了吧？

2. 反驳大主题。在前端领域，用过几个国产的库，最早 baidu 的 echarts ，饿了么的 elementui ，阿里的 DataV 、antd react 都是不错的国产库，文档不敢说比国外同类质量高，但至少是很不错的。你要是觉得它是中国人写的，用起来恶心，就要求它完美，那你就不要用。

敢问各位，你们写了没有？没写的话，有没有在公司推进相关的事情？

即便产品不对外，那有没有对内的文档？

所谓“国产” 不敢用，有没有你的一份原因？