95% 的程序员都是 CRUD 仔，但这没什么不好

## 一、一个被挂掉的大厂候选人 前几天面试一个人，履历挺亮眼——某大厂出来的，技术栈张口就来： "Kafka 底层源码我看过，K8s 调优是我的强项，高并发设计模式我能倒背如流..." 你猜怎么着？ 我把他挂了。 不是因为他技术不行。恰恰相反，他太行了。行到满脑子都是"我要上最牛逼的技术"。 我问他："业务方下周急着上线试错一个新项目，初期日活大概几千，你打算怎么搞？" 他眼睛一亮，给我整了一套豪华套餐： - 微服务拆分 - 全套链路追踪 - 分库分表 - Redis 集群 我看着他狂热的眼神，心里只有四个字：**公司药丸**。 ## 二、架构师的真相：不是扫地僧，是居委会大妈 很多程序员对架构师有一种特别中二的幻想。 觉得架构师就是团队里的扫地僧——平时不怎么说话，遇到难题了，戴上降噪耳机，噼里啪啦敲出一段绝美代码，拯救系统于水火，深藏功与名。 **但真正在一线干过架构的人都知道，现实根本不是这么回事。** 架构师的本质是什么？ 不是追求完美，是**协调和妥协大师**。 还是那个面试题：业务下周要上线，日活几千，你怎么搞？ 真正的架构师会咬咬牙，选个最单体、最老的框架，甚至直接在现有系统里硬拉个分支，三天跑通上线。 为什么？ 因为他知道这玩意儿下个月商业模式要是跑不通，整个项目就裁了。你花一个月搞的高可用架构有个屁用？ **技术永远是给商业兜底的。** 能在屎山上雕花，并且保证三年内这座屎山不塌，这才是架构师的核心能力。不是动不动就推翻重写。 ## 三、见不得屎山的人，当不了架构师 程序员都是有技术洁癖的，这很正常。 我刚工作那会儿也一样——看到祖传代码就浑身难受，恨不得当场重构。注释不规范？重构！变量名起得烂？重构！设计模式没用对？重构！ 但后来我发现，**这种洁癖在架构师身上是病，得治。** 为什么？ 因为商业世界不是实验室。你不能说"等我把这个系统重构完美了再上线"。 市场不等人，竞争对手不等人，投资人的耐心更不等人。 架构师要做的，是在一堆约束条件下找最优解： - 时间不够 - 人手不够 - 预算不够 - 技术债一堆 这时候你怎么办？ 硬着头皮上，在屎山里找出一条能走的路。然后记录下来：这里有个坑，那里有个雷，三年后如果项目还活着，记得来还。 **能在屎山上雕花，并且保证它不塌——这才是真本事。** ## 四、CRUD 怎么了？ 圈子里有个特别烂的风气：写底层的看不起写业务的。 很多人开会的时候，产品经理一讲业务背景和变现逻辑，就在下面玩手机；一聊起技术实现，个个跟打了鸡血一样。 **但只要你还觉得写业务 CRUD 没技术含量，你就跟架构师无缘了。** 为什么？ 因为离开业务谈架构，纯粹是耍流氓。 公司的核心是怎么赚钱。你连你们公司的核心转化漏斗在哪都不知道，哪条链路挂了五分钟也不影响收钱你也不清楚，明年这块业务量会翻十倍还是原地萎缩你也没概念—— 你怎么做降级？怎么做高可用？怎么分配手里那点可怜的服务器资源？ **架构是跟着业务长出来的，不是坐在工位上拿画图软件画出来的。** 我见过太多架构师，画了一堆精美的架构图，结果上线三个月，业务量涨了十倍，系统直接崩了。 为什么？因为他们根本没理解业务的增长模式。 真正懂业务的架构师，会在设计之初就问： - 这个功能的峰值会在什么时候？ - 如果失败了，回滚策略是什么？ - 哪些链路可以降级，哪些必须保证？ 这些问题的答案，不在技术书里，在业务方的脑子里。 ## 五、架构师有一大半时间在吵架 这是最劝退 80% 码农的一点。 如果你觉得戴上耳机安静敲一天代码是最爽的事，那你千万别当架构师，你会抑郁的。 一个架构方案出炉，画个 UML 图顶多两天。 **剩下的两个月你在干嘛？** 在各大部门之间当交际花和居委会大妈。 - 跟产品砍需求："这个逻辑太复杂，性价比太低，砍掉。" - 跟兄弟团队拉扯边界："凭什么这个脏活要放在我这？扔给你们网关去做！" - 跟老板忽悠资源："不加机器双十一肯定扛不住，挂了别找我。" - 安抚开发兄弟："这期排期太紧，代码先写得恶心一点，先把业务对付过去，下期我请大家喝奶茶，咱们一定重构——虽然大概率没有下期了。" 绝大多数程序员都有点社恐，天然排斥人际冲突。 拉不下脸去吵架、没法把不懂技术的老板忽悠瘸、抗压能力差的人，根本坐不稳这个位子。 **架构师不是技术岗，是技术+管理+销售的混合体。** ## 六、坑位就那么多 职场是很现实的。 一个 100 人的开发部门，满打满算需要几个架构师？ **两三个顶天了。** 因为底层逻辑就决定了：盖一栋楼，不需要 100 个人都去想地基怎么打。只需要两三个人画图纸，剩下的 97 个人，只要能老老实实、高效率地把砖砌好就行了。 老板花钱，买的就是你的熟练度，而不是你的架构思维。 这不是贬低 CRUD。恰恰相反，**能把 CRUD 写得又快又稳又不出错，是稀缺能力。** 我见过太多人，一心想当架构师，结果高不成低不就—— 架构思维没练出来，代码能力又荒废了。最后 35 岁被优化，简历上写着"曾任架构师"，却连一个完整的模块都写不利索。 ## 七、你到底适不适合当架构师？ 如果你非要往架构师那条道上挤，别天天啃技术书。 试试这几件事： 1. **多听听产品和运营在吵什么** 他们吵的往往就是业务的痛点，也是架构的出发点。 2. **主动接跨部门的烂摊子项目** 大家都嫌烦的那种。这是练协调能力的最好机会。 3. **给完全不懂技术的老板讲明白一个技术方案** 能用三句话讲清楚，才是真懂。 做完这些，如果你觉得： "卧槽搞这些太恶心了，我只想安安静静地写牛逼的代码" **那就安心做个高级开发，挺好的。** 不是每个人都适合当架构师，就像不是每个人都适合当管理者。 **找到自己的位置，比硬挤进不适合的位置更重要。** ## 八、跳出代码看系统 最后送大家三句话： > **跳出代码看系统，跳出系统看业务，跳出业务看商业。** 这是架构师的视角，也是每个程序员都应该有的视角——哪怕你只想写好 CRUD。 因为当你理解了业务为什么需要这个功能，理解了公司怎么靠这个功能赚钱，你的代码自然就会写得不一样。 你会在关键路径上加缓存，在非关键路径上省资源。 你会在容易出错的地方加监控，在不影响收入的地方做降级。 **这不是架构师的专利，这是每个专业程序员的修养。** --- ## 写在最后 95% 的程序员干到退休也就是个 CRUD 仔——这句话不是贬低，是现实。 但 CRUD 仔和 CRUD 仔之间，差距可以很大。 有的只是机械地完成任务。 有的却能跳出代码，看到背后的系统和业务。 **后者，哪怕职位上不是架构师，思维方式已经是了。** 而这，才是职业发展的真正分水岭。 --- *你觉得自己更适合做技术专家还是架构师？欢迎在评论区聊聊你的经历和想法。*