你想把扫全表变成二分搜来做 grouping 是吗？

确实可以做的。

比如说 Ruby 里有 bsearch_index 可以通过条件在数组里做二分搜，返回第一个满足条件的项的下标。
假设 times 是时间数组，降序，time2 是比较日期
year2_date = time2 - 1.year
year2_idx = times.bsearch_index {|time| time < year2_date} #找到第一个 1 年以前的日期
year3_date = time2 - 2.year
year3_idx = times.bsearch_index {|time| time < year3_date} #找到第一个 2 年以前的日期
然后把 0-year2_idx 的和 year2_idx-year3_idx 等等的 slice 切出来放进不同数组就行了。

我们代码写得不干净的话连 code review 都过不了。长期发被人喷的 PR 没多久就 PIP 送走了。
当然实际上我们这里不太会出现这种可能性，因为代码写不干净的话，连组里的 code interview 都过不了，就算过了我们的 interview ，bar 那边也过不了，所以不需要担心招进来一些写代码稀烂的人。




（除非和印度人一起写代码。）

湾区，工资低一点是指年薪$150k 左右的水平吗？

动漫 != 动画。

xxhash 挺好的，非密码安全的哈希，速度也快。

@gam2046 遇到消费者找茬要求技术支持的时候你怎么办？ Ubuntu 至少还有个公司可以做商业支持。

@ericgui 日本程序员收入和美国比是不是过分了点。虾图随随便便就是 200k ，东京你要拿 20m 那得多富啊。

一般只有程序源代码的著作权容易有争议。
心得随笔这些一般不受著作权污染影响。

至于通常用 getter/setter 而不是直接读写 field 的理由是，代码可控性。

字段是一个数据。读取和写入数据的是代码。那么这个代码，谁有最终控制权？

如果一个类只包含数据，并且有另一个你能控制的类来操作这个数据，那么这个数据类就不需要 getter/setter 。操作数据的类就充当了 getter/setter 的作用，因为这个类也是属于你全权控制的。
但是如果是交给第三方调用的类就不行了。当你要修改一个行为的时候，你需要一个一个组去协调，让别人按照你的意思去改他们的调用方法才行。

又比如你调试 bug 的时候需要监控谁在什么时候修改了你类里面的一个字段。如果有 setter ，你把日志或者断点插进去即可。没有 setter 的话，你去哪里找调用方呢。

还有一个点，就是 getter/setter 是方法，而方法是可以重载的。子类行为可以和父类不同。比如同样存储数据，父类可以存在字段里，子类可以重写然后存进数据库里。

顺便一提，上面很多人都说 C#的 property 好用。Property 就是字段+getter+setter 的语法糖，归根结底还是 getter/setter 设计方案。

是不是先明确一下你问的到底是「用 getter/setter vs 字段」还是「写 getter/setter 代码 vs 不写 getter/setter 代码」？

我随便拿 Ruby 来举个例子。Ruby 里 obj.var = value 实际会调用 setter 方法 obj.var=()，obj.var 实际会调用 getter 方法 obj.var()，而获取 field 如果不走 getter/setter 则只能通过反射。

所以 Ruby 是一个典型的，用 getter/setter 但是不需要你手写 getter/setter 方法代码的语言。

现在你这个问题有些歧义，看上去像是在问为什么要用 getter/setter ，但是却又好像在抱怨需要手写 getter/setter 而不是语言自动生成。

@magic3584 两个都不应该用。你这篇文章里提到的 cherry pick 是更差的做法。

以前的电脑，钱没花在刀刃上。现在的电脑，你知道该怎么配性价比最高。
以前品牌机惯用的高性能 CPU 配微量内存配垃圾硬盘，别说三四年以后开始卡，你买来就开始卡了。
现在的电脑，你去买 i7 配 8G 内存 500G 机械硬盘，照样卡得你不能自理。

和你同段的号都是直接扫段的。
你不会以为手机号不告诉别人别人就不能打吧……

而且这不是 GV 的问题，不管换啥号都会有人打。我手里 ATT 原生号都没事就有人扫段，从领事馆通知到顺丰快递到谷歌广告推销啥都能收到。

@dfkjgklfdjg rebase 以后 master 的变更和个人的变更是分开的，不会像 merge commit 那样既有 master 的变更，又有个人偷偷塞进去的变更。

@FrankHB 就怕有人心大直接在 merge conflict 上瞎基尔改，改完一交，神不知鬼不觉。
squash 完如果有 PR code review 的话倒还好，做个 diff 至少能看到改了点啥，但是像楼主的 team 这样愉快地打算 push -f 的就……

@edis0n0
硬解和破解是两回事。硬解和软解的区别是把算法转换成了电路结构。破解则是穷举猜测，他是有平均下限时间的。用时间可能不太容易理解，我们可以说能量。比如说破解一个 ed25519 秘钥所需要的能量比发射一艘太空船去火星还要多，这样是不是更容易理解。不管你芯片能做到多快，你都需要足够大的能量去支撑计算。

还不如期待一下量子计算机。

@dfkjgklfdjg merge 可以把不正确的仓库改动隐藏在 merge commit 里。

比如你把 master 合并到 feature 上的时候产生了冲突，一顿解决以后合并成功了，然后过几天你把 feature 合并回 master ，结果 master 上某些功能不见了。然而你回溯回去却根本不知道是哪里出了问题。因为 merge commit 里可能会包含任何更改，不仅仅是 master 的更改，也可能是 master 覆盖 feature 后又被手动改回来的更改，甚至还可能包含既不在 master 也不在 feature 上的更改。因为 merge commit 本身就非常大，不可能单独检查，这种操作就等于是在代码提交历史里埋炸弹。

或者换句话说，这种 merge 就相当于把 feature 和 master 的提交揉在一起。不出事我才觉得奇怪。

本地提交你用 git log 看？ git log 又看不了。
pull rebase 是正常操作，pull merge 才是作大死。上面甚至有个建议日常作死的大佬我也是服气。
如果你实在想要锻炼自己去用这扭曲的命令行，那也最好先装个 GUI ，像这样不知所措的情况至少 GUI 能正确显示仓库当前的状态。

因为安全所以才会短。要是不安全那还不得拼命拉长了用？（比如 RSA ）