@qwezxcassd #26

看你现在方向是有了.

但只是工作了半年多.

俺觉得可以在等等, 先工作一年比较好, 在这剩下的时间里, 可以继续在你喜欢的方向上做一些积累.

然后在工作中看能不能实践你的一些想法, 如果不能实践的话, 就再忍忍半年, 也不必过于在当前工作中证明自己.(好把自己搞的好累)

过了一年后, 可以考虑其它的机会.

俺觉得最关键的是, 你现在是有自己的方向, 只是自己学习和积累的在当前工作中不好实践, 没有反馈, 就不好坚持了.

这比其它没有方向, 迷茫, 让别人指明方向的情况好多了.

就以 CRUD 为例吧, 俺觉得这其实也是可以学习到一些东西的, 比如说

1. 从业务角度: 你会了解业务, 说不定这个业务比较有通用性一些, 有通用性的业务还是值得要了解的, 它们都面面临一些共同的问题, 你可以搞明白这些共同的问题如何解决, 那么, 你就学会到了一般性的解决方案, 这是从业务角度来说.

2. 从技术角度: 你如果觉得 CRUD 很枯燥, 你可以去想一下不使用 CRUD , 还有没有其它的方案来做? 比如说 DDD? 在学习 DDD 过程中,这个点又会引申到什么微服务之类的, 你又可以学习到很多东西, 而这些东西, 俺看来是很有通用性的.

3. 从数据角度: 无论 C 端还是 B 端, 都会涉及到各种类型的数据, 你可以去思考这些数据的存储为什么会这样? 为什么有的要在 redis, 有的要在数据库? 有的要在 ES? 你可以学习去分析数据的数据量, 数据的读写冷热问题, 如果数据之间还有关系, 你要思考一致性的问题了.

所以, 俺认为, 即使你是在写无聊的业务, 也可以从多个角度去思考, 也会有收获的, 你可以有一个目标,

"如果整个业务系统由你来设计, 你会如何考虑?"

学会了以上这些, 自然就不会去做一个只些纯业务代码, 做 CRUD 的 boy 了, 你就可以从整体的一个视角来看待这些"纯业务代码了".

建议少和他们联系吧, 离远一点
你要有勇气自己独立

看了简历, 楼主很棒, 加油, 不要放弃

兄弟, 你是主播么

这单位, B 格高啊~~~

@Solidot #1 感谢提供经验, 俺看 mycat 主要对俺是黑盒子, 怕自己掌控不了. sharding-jdbc 对业务代码侵入也不是太强, 但做的比较薄, 还放心一些.

@lujie2012 #22 老哥暴躁啊~~~

它不仁, 你不义, 爆出来给兄弟们避避坑啊

还有, 俺还补充一点.

俺上面的回答其实是以一种简化的模型为前提的, 不考虑 OS 的虚拟内存以及缓存等.

真实情况肯定会更复杂, 但理解一个东西最好还是现简化模型, 抛开无关的, 否则会太复杂.

@enchilada2020 #11 哈哈, 能对别人有帮助俺就欣慰了.

其实细节很多人都记不住, 这没关系, 主要是梳理清来龙去脉, 知道它们的应用场景, 面对问题给出方案和方向就可以了嘛.

方向方案对了, 细节可以在实施过程中补充就行.

而且很多时候, 细节也不用管呢, 这些通用的, 都有成熟的实现, 咱们这些普通人, 就别想着写出更好的实现了.

别给面试官感觉是背理论,背八股文就行.
可以不必记细节.
但要回答出, 红黑树, B 树是什么? 用来解决什么问题的? 该问题如何不使用红黑树, B 树, 可以使用什么来解决?

俺比较赞同 2 楼老哥的, 你把技术演进过程串起来就很不错了.

比如说. 想以下这样回答

----------------

无论红黑还是 B 树, 都是用来解决搜索问题的, 搜索越快越好嘛.

其实最初的, 就是二叉搜索树. 如果这颗树比较平衡的话, 其搜索效率就等同于二分查找了.

但是呢? 现实是, 二叉搜索树不平衡, 如果不平衡, 你想想, 搜索效率就很差了.

所以呢? 能不能构建二叉搜索树时能让它尽量平衡一些?

于是就有了平衡二叉搜索树.

但是呢, 平衡二叉搜索树插入删除比较麻烦. 为了这种平衡, 付出代价太大(如果你就创建一次, 不经常变动也没事, 反正只有变动时才有代价)

为了即要平衡, 又不想付出太大代价, 就有了红黑树了

当然, 红黑树消除了插入删除的代价, 所以, 对于 HashMap 的某一个 bucket, 如果元素很多, 使用红黑树是很适合了.(因为 HashMap 一般经常要删除和修改)

到了这里, 红黑树还是二叉树, 层还是比较深的, 和搜索的过程是和层的深度是有关的, 每一次要到某一层的节点加载到内存来比较.

如果所有数据都在内存没问题, 但数据要是在磁盘呢? 每加载一次就是从磁盘到内存的一次 IO, 你也知道, 磁盘读写是很慢的. 所以能不能尽量减少这种 IO 呢?

B 树就可以了, B 树不是二叉树, B 树是一种多叉搜索树, 每一个节点都有多个元素.

这样, 对于全部节点固定情况下, B 树肯定比红黑树要浅了, 这样, 潜在的最大 IO 次数一定少了啊.

所以 B 树就应用在数据库的场景下.

同理, 如果你的搜索涉及到多种速度不一的存储介质, 也是可以考虑 B 树的.


-----------------------

俺觉得答成以上这样, 就很好了.

至于现场手写红黑, B 树, 或者问你红黑 B 树的细节的, 俺觉得这是面试官的问题.

你想想, 这些算法是什么人想出来的? 是数学家, 计算机科学家啊? 如果不是你自已想出来的, 你怎么可能熟记于心?

如果你能熟悉写出来, 只有一种情况, 你基本上每隔几天就写一遍, 可能自己默写了几十遍, 几百遍.

只一种算法你就要花这么多时间熟记于心, 还有很多算法呢? 你也能做到每天写一遍?

所以, 遇到什么都不问, 就让你手写红黑或细节的. 都是面试官的问题. 可能是以下几种情况

1. 面试官是天才, 其智商和数学家一样, 这些红黑树对于他们就像 1+1 一样简单
2. 面试官什么也不会, 就是最近背了几遍红黑树, 在你面前炫耀罢了
3. 面试官根本不想要你

以上三种, 这种公司不进也罢.

空洞骑士, 对手残党特友好

@Smash #117 还行啊, 不过 160+太大了, 俺还是 100 左右就满足

@Smash #23 再来几张, 再来几张, 再来几张!

@iyaozhen #11 您说的这种技术氛围, 看个人的主观能动性, 以及组织层面不设条条框框, 令人向往, 哈哈

@iyaozhen #11 感谢回复, 俺觉得这种靠自己争取, 以实力服人的方式, 很好! 也了解到百度这方面的情况, 再次感谢!