@zhujinchang #1 不加还叫字节吗

个人感觉是读 历史或者 名人传记，最好是比较细致的那种， 你所遇到的问题和困境，那些青史留名的人 也曾遇到过更夸张的处境。 他们是如何面对和解决的。

同时也能安慰自己，那些大才，人生同样也是充满坎坷，所以放低期望。

@labdum #0 就是这个问题，排好的窗口会移动到别的桌面。 有时候是感觉两个显示器的窗口互换了的感觉

@LXchienne #4 M1 pro 的，我的经验来看和芯片没关系，都遇到过这个问题

@najunuoyan #1 简单看了下，能解决部分问题，不过貌似 macOS 没提供 多虚拟桌面的管理 API ，如果想把程序放置在 固定的显示器的 第三号桌面上， 还是比较麻烦

分桶是一个简单的抗高并发的思路，还要继续优化出一个复杂思路的话，感觉 innodb 处理写入操作的思路也可以参考一下。

简单来说就是把数据加载到内存， 有请求先改内存数据， 再写入到 "redolog"。 后台任务有空再把 redolog 落盘，落盘的时候没有并发，可以做得比较快。

把高并发的冲突操作改成了纯内存 + 无锁顺序写

直接 replace 或者 on duplicate key update

没理解你的疑惑，你插入数据的时候不也要组装那个 唯一键的 id 信息么。

都用 Alfred 本地搞了

代码质量和文档，实在不行 接手的人花点时间 啃啃代码也能熟悉。
说实话 这些东西真的够不上 谈替代性。

还是从其他方面考虑提升下自己的竞争力，代码文档还是该写好就写好

现成的例子，去看看那些世界流行的软件作者，都是在什么年纪写出来这些改变世界的代码的。
Java 之父 35 岁写出来 Java,
Python 之父也差不多 35 岁, Redis 之父也是 三十多岁写出来 Redis 。

笼统来讲，国内出现你说的这些现象的原因，就是国内并没有把程序员当成一个技术密集型，创意性的工作，
而是当成劳动力密集型的工作。当然这和国内大部分做得都是应用软件有关。

因此很多老板乐于让员工加班，认为和流水线计件工作一样，加班越多产出越多，功能堆得越多。
而且大量的公司（包括国内叫得上号的大厂，有一个算一个），屎山代码数不胜数，大量的时间在救火修 bug 。

你讲的现象，确实是有，而且不是少数（我就碰到不少，年龄大，职级高，但实际水平完全配不上的）。 不过我想说的是另一角度：你技术能力好， 写得代码漂亮，其实在国内，不是什么绝对的优势。因为我写应用功能，讲究的是能用，不漂亮、性能差点的代码，也能用。至于代码结构导致的 扩展性差，bug 多，这个可以靠人员加班去堆，毕竟有人口红利优势。

所以这种情况下，原本应该是越老越吃香的职业，其实有很大部分被 体力丰富能加班的年轻人 替代了。

正经来看，我觉得黄金年龄是 三四十岁，这个年龄度过了新手期，有较为丰富的经验和积累，体能精力也还不错。

@liahu #25 可能你平时不太注重这些，也有可能你理论上会，但是放到实际场景的时候想不起来。

当时很多经验学历都比较普通的人都能答上，甚至还有普通大学的 应届生，也能答上一些。

这个就看你抽象能力了。 听你的描述，场景比较典型。

你需要抽象出相同的处理流程（比如，先获取文件类型，在进行对应的逻辑处理，逻辑处理里可以进一步细化），
相似的处理逻辑（类似 都要取 A 文件 前 1-4 字节 来判断后续处理逻辑）

引擎这东西其实很多业务需要的功能并不复杂，自己也可以简单写一个
每个项目都有一个配置文件类似 {“protocol”:"A", "logic":"1"} ，需要根据业务自行设计
解析文件的时候 进行判断

if ( $config["protocol"] == 'A')
// do sth A
else ....

当然优雅点你可以用策略或者模板的 设计模式。看你自己实现

我写的一篇关于面试的文章， 希望对你有帮助

https://blog.csdn.net/zzt46245/article/details/130790452

这个我觉得最简单的办法就是看银行的利率。

利率高 -> 经济形式好,机会多 ,愿意借钱扩张
利率低 -> 经济形式差，借钱的少，存钱的多

简单查了一下，我国前几十年高速发展的时候，利率可是到过十几点的。 遍地都是机会，就很多人愿意借钱折腾
日本为什么 0 利率？ 经济停滞，没啥机会

现在国内银行的利率趋势，还用说么

@wzcloud #20 是的，资深岗位本身不多也是一个原因

@milzero #9 都还没开始聊呢

@programbao #15 1.5 是指？

@gyt95 #12 三个月了吧。 开始还是找大厂内推，发现简历过不了。 然后开始上 boss 投广州，机会也少，最近才开始投深圳的，但感觉也不是很乐观

如果要说比较大的锻炼机会的话，就是写一些底层框架 /工具，项目重构 / 0-1 的设计机会。

但是话说回来，如果水平不够的话这些事情很难落到你头上来。

所以还是要多注重平时的积累。

以下个人的后端经验，不一定适合所有人，仅供参考。
主要是实战和理论两方面并行，比如架构能力、代码扩展 /复用性等。
首先通过书籍或者课程学习相关的理论，然后非常关键的是，在日常工作中，有意识地运用这些理论进行实际锻炼。

比如没机会设计一个大工程，那么就把一个小功能当成一个架构去做设计考量。
代码的设计模式、扩展、复用性等，平时积累锻炼的机会就更多，只不过大部分人写的都是业务代码，可读性、性能、复用性差一点，其实也无伤大雅。

这样，比较理想的路线是 ： 通过平时积累锻炼 -> ld 发现你相关能力还可以 -> 尝试给你更大的挑战 ->得到更好地锻炼。

当然如果自我感觉还可以了，锻炼机会也可以自己主动去争取。不要怕搞砸，搞的时候方案让组里的大佬把把关，这种过程会是非常好的成长机会。