@jiankaikey 在这里, 效率并不是需要考虑的主要问题.

很多老程序员急是因为见得多了那些菜鸟程序员过早优化封装, 结果就是还不如不封装; 写代码跟做其他事情一样讲究的是解决主要矛盾, 在我看来这段代码逻辑简单, 也不是什么核心代码, 楼主纠结于此并说很离谱(这段代码确实写的是不怎么样, 我可能也会顺手改了, 但不会太苛责), 那么在面对复杂的核心问题超过楼主的能力时, 这种凡是要抽象封装的理念只会带来错误和难以维护的设计, 危害会比更少设计来得大.
说到 Code Review, 讲一个笑话: 一个人去 update 一个开源代码, update 几行的时候几个核心程序员讨论了半天才 Approve; 当 update 超过几百行的时候十分钟(run 完 unit test)就接受了.

再看了一下楼主的补充, 自己也说了有"新"的需求, 新需求带来代码或者结构的变化是正常现象. 以我多年编程经验来看, 过早的优化比不优化其实危害更大, 不优化大不了重写一部分逻辑, 过早优化改的时候还得把所有优化过的逻辑拆开重装.

封装意味着多一层抽象, 会多一层心智负担, 所以需要有代码清晰度的提高或者减少重复来作为补偿(比较明显的结果就是封装后代码行数明显变短). 楼主同事的代码没什么大问题, 更谈不上"离谱", 经过优化后代码并没有明显的代码量的降低.

架构经验是慢慢积累的, 作为新人, 我觉得关注点还是多琢磨怎么写好代码上面. 先把自己用的程序设计语言相关的书看上至少两本, 一本包含所有知识点(不是为了用到所有的犄角旮旯都用到,为了看懂别人的代码), 一本包含进阶, 类似 effective java 之类的书;
了解项目用到的框架, 如果是 java 的话, 比如 pro spring, pro spring boot, High-Performance Java Persistence
然后就是怎么整体写好代码的书, 比如 clean code, clean coder, code complete (还有很多)
架构上主要还是多思考, 多看看别人的架构. 书的话也有很多, clean architecture, patterns of enterprise application, design data intensive applications, building microservices
读完书多实践, 为自己每一行代码, 每个架构决策都能找到这样写和这样决策的理由.

很多工具不错, 有没有办法跟 Alfred 一起工作呢? 比如程序支持参数化输入什么的.

持续学习, 保持为一个人才.

一个月是基本操作, 下家明显不尊重候选人.

怎么变成知乎: 分享现编的故事了...

LZ 跑一下我的 SQL 就知道了 , 为什么还在问呢?

假设表结构为 student (id, name, grade).
完整不考虑效率的 sql

select f.id as id, f.name as name, f.grade as grade from student as f where f.grade >=
(select max(e.grade) as cutgrade from
(select sum(d.acount) as count, d.bgrade as grade from
(select a.cnt as acount, a.grade as agrade, b.grade as bgrade from
(select count(id) as cnt, grade from student group by grade order by grade desc) as a join
(select c.grade as grade from (select distinct grade as grade from student order by grade desc) as c) as b
where a.grade >= b.grade
order by bgrade desc) as d group by grade order by grade desc) as e where e.count >= 10)

不专门刷题的能在半个小时做出来的程序员素质不低了, 取名字那一步会出现并列第一名的情况, 规则没说按照什么逻辑来选择.

1. 女朋友也有给 LZ 买东西;
2. LZ 也是稀里糊涂的;
3. 女方家人没毛病: 成年人要对自己负责, 知道影响学业也帮了, 既然是两个人去的, 他们也不清楚谁花了多少钱, 男的承担没毛病.

node.js 的强项是前后端可以用同一技术栈. 弱项是后端生态不完善, 第三方库质量参差不齐. CPU 密集型不合适我理解主要是指一些极端场景效率不高(但是我极度怀疑这些极端场景会用 node.js 来实现). 实时返回不代表要同步处理或者要在 node.js 层面处理, node.js 很多逻辑天生都是异步的, 放到 worker 中处理即可.

@lithiumii 不同商户 openid 不保证全局不重复的, 即使重复的概率很低.

很好奇 LZ 的业务场景, 应该不止一张用户表啊(除非是专门管客户信息的子系统), 其他业务表不用分表吗?

怎么分库分表不光是性能的需求, 还有业务的需求(比如要不要不同商户的数据隔离, 特别是大商户一般都会要求隔离).

保险的方法是按照商户分库分表(至少先做到按商户分表), spring JPA 对多商户其实支持挺好, 业务层的逻辑基本是透明的. 分析需求如果要合并表再备库到大数据平台做.

国外国内都待 5 年以上才有发言权; 地方没有好坏只有适不适合,没有什么地方是天堂. 国内也不都是 996, 外企也不是福利院. 多问问各环境成功人士, 特别是不要问 loser, 看看哪些特点适合自己发展.

移动垃圾网络高峰访问外网都是十几 k. 免费试用了两个月换回电信了的.

Notion 收费版容量没有限制, 没有标签, 有手机端; 串联比较弱, 还没到原生的 block level(Hack 方式比较繁琐, 并且没有链接的视图). 没有思维导图, 感觉更多是想集成别的 Web App 的路子.

优点: 漂亮; 功能也 okay, 可代替日记 app, 非重度的 GTD, 团队协作文档;
缺点: Table 类型的数据实现起来太重; 因为是 Web 程序, 运行起来流畅度有些欠缺;