这是一个创建于 124 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文发布在我的网站上
难以复刻的大问题
第一个麻烦是现代框架解决的是“大”问题，而个体开发者遇不上“大”问题
早些年如果你想从头学习一门前端框架，比如 BackboneJS 或者 EmberJS ，一定绕不开从构建一款 Todo 应用开始，它能让你直观感受到 model 与 view 之间是如何相互协作的。现在我们依然保留同样的传统，只不过它不在以 Todo 的形式存在，但依然会出现在文档的 Quick Start 小节中，企图用最少代码最大程度上展现技术的特性。
问题在于早些年前端代码只是作为静态站点点缀般的存在，例如控制交互，填充内容——看看这段淘宝平台 09 年的代码你就会理解我在说什么。而如今 JavaScript 代码已经可以做到接管编译、路由、渲染，将应用端到端的呈现出来。最重要的是，它已将处理复杂问题的能力内置其中。然而这些复杂问题，从高并发到匪夷所思的业务场景，Quick Start 里的 demo 无法展现它们的全貌，个体也难以模拟。
K8S 就是一个最好的例子。
去年抱着学习的心态，我把我所有部署在 VPS 上的 side project 迁往 K8S ，甚至连应用的部署方式也替换为了 ArgoCD 。但实话实话这不是一笔划算的买卖，因为从结果上看，替换为 K8S 之后花费的计算资源更贵了，维护成本（脑袋里需要记住的东西、涉及到的步骤和需要持续维护的环境）也水涨船高。原因在于当架构简单到仅需单个 cluster 就足以支撑的时候，K8S 的边际成本无法被均摊。所以吊诡的事情出现了，你发现体感上新款 K8S 还不如旧款 PM2 好用。
可不可以不关心大问题，全权委托给框架，我只管把 kubectl 命令全文背诵就好？——不行，因为 Copilot 永远记得比你滚瓜烂熟。面对 AI 的挑战，程序员无可避免的要将角色从执行者转变为决策者。
说起来有些玄学，设计方案吃经验，准确来说是“由奢入简易”：解决过大问题之后回过头解决小问题很容易，反之不成立。虽然理论上无数的工程师有无数踩过的坑有待分享，但考虑到 99% 的人并不会把这些经验整理成任何形式的内容分享出来，所以坏消息是经验还是要依靠自己打怪升级获得。
设计方案中颇为重要的另一点是定量而非定性分析。
这是另一个例子：我的播客广场网站至今已经抓取了超过了九百万的播客数据，我是应该继续使用 MySQL 作为播客统计工作的数据支撑，还是应该转投 Databricks ？我无法回答，因为我对九百万数据体量的理解是空白——这是我最近开始折腾 Databricks 感受到的最大疑惑。当下我可以很轻易的找到资源学习 MySQL 以及 Spark ，但我面临的问题不是如何编写他们，而是什么样的场景适合编写他们。这些经验，是我一个人在家里造不出来，也是课本教不了我的。
说一点由此衍生出来的我的有趣观察：判断程序员（甚至是产品经理、项目经理）资深与否的方法之一是观察他对于数值的理解。8 个人的团队多还是少？ 50 毫秒的 MySQL 查询时间快还是慢？在将浏览器加载资源耗时提升 1 秒之后留给我的空间还有多少？
They won’t fear it until they understand it. And they won’t understand it until they’ve used it.——电影《奥本海默》
理想的技术决策是用理性表达代码——这么做是因为我选择这么做，而不是我只会这么做，更不应该是我觉得该这么做。
大问题带来的挑战不仅仅是规模这件事本身，还有体量产生的副作用：拥有十万行代码应用的难点可能是混乱的代码组织和依赖关系，也可能是无处不在的坏味道，但一定不是框架本身。在我的工作经历中这是常态，同理入门教程无法带给我们这方面的训练。
你不再重要
第二个问题是，研发也许无需我再亲力亲为。
以 NextJS 为例，我对它的赞叹来自于两点：1 ）完备的功能设计； 2 ）井然有序的文档。前者依赖的是对框架职责和前端开发的充分理解，后者需要投入的维护成本和决心也不容小觑
由此产生的副作用是工作变得无聊起来，当下需要实现或者是未来需要考虑的，都可以在文档中按图索骥找到答案。以至于有时候你不得不怀疑某些 NextJS 功能被过度设计了，例如它极富层次的缓存机制。但我宁愿相信本质上这依然是我有限的眼界与大方案之间匹配错位造成的。
更重要的变化在于，十年前如果我们想要实现等价的缓存效果，尊循的是理解、设计、实现的实践；而如今 NextJS 已经为你实现，甚至 LLM 可以代替你理解方案细节，我要做的仅仅是提出问题做出选择即可。
同样的情况还发生在上面所说九百万数据的例子中，再更早之前我考虑过使用 Big Query 进行数据统计，但问题在于如何将存储在 Digital Ocean 上的数据同步到 Big Query ，是用 replica 还是日志？如今入坑 Databricks 之后利用 Azure Data Factory 无需编程就可以完成上述需求，但至于它是如何实现的我依然一无所知。
你以为它们的“魔爪”就此为止了？这才刚刚开始——当下应用和框架的关系已经悄悄发生了倒置：不再是应用去集成框架，而是应用被内嵌在框架中。
如何理解我所说的内嵌：开发一款应用需要什么？ web 框架、登录、存储、缓存；兴许还有流水线、测试环境、日志监控等等。在很长一段时间内这些是繁重且琐碎的工作，依赖团队去完成，而如今它们是市面上 BaaS 甚至是框架标配，例如你用 Deno 写完应用之后不用担心部署在哪，它们提供额度范围内的免费 hosting 服务，正如 Vercel 之于 NextJS 。下图是 supabase 的卖点，其他的 BaaS 也都大同小异
当然前提是你需要植入 SDK ，甚至使用指定的框架进行开发，也就是说只有接受平台的规训，才能发挥平台的最大潜能。这就是我所说的嵌入，你只不过是它其中的一环。
纠正一下，我不是在抱怨没有源码可以阅读，而是每当想到铺天盖地的预制菜做量大管饱，还性价比高，我做饭的乐趣就荡然无存：因为如果我选择亲手去实现，那么可以预见接下来代码产出中的大部分，已经被无数人实现过无数遍了，甚至我自己也驾轻就熟。那为何费时费力的和自己过不去呢。虽然我知道在大公司造轮子依然是正义，虽然我知道技术深度避免被 AI 取代的核心竞争力，但现状依然令人沮丧。
于是我发现自己处于一个非常尴尬的位置，向下专研技术的动力在减弱，向上没有太多的大问题有待解决，大部分时候我像是一个方案整合商。
答案在哪
我不知道该如何回答这些问题，这些年还有很多变化在潜移默化的发生，例如我们发现有客户已经在利用低代码构建大型应用。最终团队的协作方式，工作流会怎么被这些变化塑造还没有人知道，震荡在持续中。但我坚持认为 AI 还无法替代你。
至少有一件事是板上钉钉的：去拥抱它们，学习它们，观察它们。出路在探索中发现，而不是对它们视而不见。
51 条回复 • 2024-07-09 15:22:13 +08:00
 |
1
yoiteshaw 124 天前
有一种似曾相识的感觉，罗永浩：现在的手机厂商都是方案整合商罢了。
所以新入场做手机的如果也是新的方案整合商，确实是在供应链掌控成熟的老前辈面前没有什么竞争力，更别提是个体进入创业了。 OP 想表达的是类似的意思吗？ |
 |
2
GeekGao 124 天前
遭遇挑战 、解决问题、 获取新技能点 vs 无挑战 、无问题需解决、无新技能点
|
 |
3
xueling 123 天前
行业发展健全的同时，也会让程序员的”工具人“属性愈加明显。越来越多的程序员都是没有基础的，而只是一种或几种的工具运用者，既不了解某种技术的由来，也不能预判未来发展的走势。程序员还是应该更多的保持思考，否则真就成了工具人了。另外，lz 也可以了解一下我的数据统计项目： https://github.com/xl-xueling/xl-lighthouse 。
|
 |
4
jones2000 123 天前  1
楼主太悲观了。
就现在这个大环境，能少上一个插件，少一个微服务就可以节流。 优化客户现有框架，去掉冗余的插件，减少运营成本，才是硬道理。这些都要有深度的技术和业务能力才可以， 不是几个毕业生能干的。 |
 |
5
arloor 123 天前 via Android 4
对于独立开发，技术是最不重要的吧。
|
 |
6
iloveoovx 123 天前
在很多年前看到有人用炼丹来描述机器学习时我的感觉就是，很快，神话时代将再一次来临。
数据量、规模、复杂度都在指数级增长，很快将超过唯物机械式理解的智力所能承载的极限。对于这种情况，效率最高的方式是相信直觉 - 当然，并不是一无所知的情况下偷懒求神问卦，而是无数努力尝试后带来的直觉，就像把 AI 当作一个人，你想要了解它，通过不停和它聊天带来的直觉比你尝试去了解它的模型逻辑细节效率高太多。 神话时代也代表着各种神灵的现世降临，因为每个公司，每个团体都将加速让越来越多的判断交给 AI 处理 - 一开始只是作为参考，但当 AI 能分析足够多的现状和变量，提供越来越多的可能方案和可能发展，正确率越来越高后，在市场竞争、效率压力等各种动态发展趋势压力下，AI 的比重只会越来越高，最终把某个 logo 所代表的集体意识实体化，成为现实意义上的神灵。而且就像荣格说的：从来就不是人有想法，而是想法有人 |
 |
7
james122333 123 天前 via Android
个体开发者就是要写自己的东西
|
 |
8
summerwar 123 天前 1
我承认人应该精进技术，但是也得遇到了才能去精进，知道如何去精进，总不能凭空精进吧。
我老妈经常说农民的天职就是种好地，我说她瞎扯，农民的天职是赚钱照顾家庭，如果土地不能让你吃饱饭，你种得再好有什么用。 |
 |
9
ruanimal 123 天前
任何技术都是有成本的，很多新技术就是用更多成本解决更大的问题，个人追这些技术是很没有必要的
|
 |
10
Znemo 123 天前
一个软件能让开发觉得自己不再重要，那这个软件在这个领域还挺成功的，毕竟它是做给你老板的，而不是给你做的。
|
 |
11
Felldeadbird 123 天前
极致追求技术需要天赋，时间，资金等支持。
大部人能够做好技术搬运工作已经完成既定目标了。 这 2 年 AI 的出现，让搬运的方式从搜索引擎 到 AI 转变了。乐观点地说，以前你搜索引擎找不到的问题，AI 现在可以帮你解决。甚至还可以助力你更容易钻研技术上的深度。 |
 |
12
abcbuzhiming 123 天前
这个问题，10 年前其实就有文章提到：那篇文章是这么说的，现代系统变的越来越复杂——它举例是最新的民用航空飞机，说再顶尖的工程师也无法窥整个飞机的全貌，只能关注顶层总装，分系统的细节必须由其它人完成。这是必然的事情，这篇文章还很忧虑的说，有没有可能会有一天，整个系统的复杂程度，会复杂到哪怕只关注顶层，人脑也无法理解呢。
所以你的担心是客观事实，但是也没必要焦虑，因为这是这个时代所有工程师都必须面对的问题。 至于你说的，如何评估一个系统能够承担的工作量。这个问题更加复杂一些。因为现实中的业务是千奇百怪的。单一条件下的任务说测试出来的负载量很难适应更复杂的环境。所以你如果想挑战你的系统到底能胜任多少任务这个问题，除了做实验没有其他办法。也就是说这个东西是试出来的。哪怕是官方给出的，他自己的测试都不一定适应你所使用的使用环境。 |
 |
13
drymonfidelia 123 天前
九百万条，这么少的数据怎么存不行？我们小公司注册用户都有一千多万（虽然有一部分无效用户）
|
 |
14
jeesk 123 天前
@Felldeadbird 这更加不可能了，ai 的搜索也需要资料。 如果这项技术没有太多的资料， 或者说技术太小，ai 也无法帮助你。
|
 |
15
LiuN1an 123 天前
技术市场更替，这不就和当年 php 一个理么。大家各司其职，想做应用就积极拥抱这些新时代的 infra ，想做底层就直接去研究底层。在市场轮换结束时，所有上个时代的中间岗位都会面临失业。程序员能做的就是不要固步自封，特别是别陷在所谓”底层技术“的术语里，那才是真正的孔乙己的长衫。
|
 |
16
ByZHkc3 123 天前 via iPad
建议多关注下代码之外的东西，业务不挣钱，你代码写出花来都没用。
|
 |
18
levelworm 123 天前 via Android
个人开发者本来也不用琢磨技术啊，产品更重要。但是对于其他人来说，系统编程的确是条沟濩了。
|
 |
20
afxcn 123 天前
如果你想通过技术给自己找点安全感，我认为方向就是错的。
安全感不来自技术，而是来自话语权。 |
 |
21
commoccoom 123 天前 1
8 个人的团队多还是少？ 50 毫秒的 MySQL 查询时间快还是慢？在将浏览器加载资源耗时提升 1 秒之后留给我的空间还有多少？
这一段太感同身受了，现实就是，我不知道该选择什么，或者我认知之外是否有更好的选择。而这又带来了焦虑。 |
 |
22
9 123 天前
这是两条路，一个是技术专家的路线，一个是将东西整合的路线
|
 |
23
DeWjjj 123 天前
就算是阿里的前端老大，肯定也没法说做到任何东西都自己来弄吧。
人各有侧重，而且本身前端框架就是一年一年堆出来的，能花一个月时间给他源码弄明白逻辑就已经很不错了。 非必要不研究，除非你准备从事工具链开发。 |
 |
24
spiffing 123 天前
要学的东西非常多，同时又觉得很难做一些选择，尤其是遇到系统升级。
另外学习成本也变得很贵，DevOps 要求程序员有更宽的知识面，既要又要还要 * N |
 |
25
opengps 123 天前 1
前文直击心灵般的存在，赶紧看看末尾，居然没有连接，没有卖课，没有 v 我 50
这感受简直是从自己脑子里出来的 |
 |
26
sun2920989 123 天前
面对 AI 的挑战，程序员无可避免的要将角色从执行者转变为决策者。
很有意思的一句话.另外个人拙见,一些程序研发领域正在脱离原本的简洁明了而披上玄学的外衣. 比如大模型,大模型给我带来了非常大的生活和工作效率提升,但是却总让人觉得这是一个巨大的黑箱.所以跑模型也被称之为炼丹(笑 举个例子比如图片 AI 消除路人功能,消除路人时也多消除了主角的一只胳膊.有什么研发人员可以立即定位并且精准解决吗.我想应该是没有的.都是对相关参数进行各种调整和阈值设定. |
 |
27
taine 123 天前
除非是研究技术，更多尽可能多关注解决实际需求和问题。
|
 |
28
jonsmith 123 天前
我几乎在面向 AI 编程，复杂的代码、sql 查询等都交给 chatgpt ，并不是不会写，只是这样更高效、更方便。
技术总是为了解决实际业务问题，选择更高效、廉价的技术方案，才更有竞争力。看过很多公司用着很 low 的技术，赚着丰厚的利润。 作为开发者，可以有技术情怀，去专研、探索更深的技术。但是面对实际业务，该如何选择合适的技术方案，就要思考下了。 |
 |
29
Giannis 123 天前
产品能用就行了，不需要纠结于技术
|
 |
30
grayfox 123 天前
个人觉得作为个体开发者在拓展技术深度不是那么重要，重要的是如何构建一个好产品
|
 |
31
suuuch 123 天前 1
这个真实，我曾经也为此焦虑了很长一段时间，各种看书、学习、报各种课程。
最后收效其实一般。。 我现在只能把这个问题归结为广度和深度的问题，这两者是相辅相成的。 当单独追求深度达到一定程度时，会觉得自己会的技术栈过于单一，没有足够广袤的视野，明明有成熟的方案，结果发现自己在哼哧哼哧的从头写，结果还不一定有别人的好。 当单独追求广度的时候，又会觉得自己的技术不够深入，很多原理不清楚，遇到特殊问题的时候很抓瞎。 我给自己的最后安慰就是，深度是需要的，广度也是需要的，两者相辅相成，目的是要形成自己的技术知识体系。 这一体系是为了帮我理清各种技术栈的优劣，形成一套客观的评判标准和架构思路。 比如说按照项目管理的角度去思考技术带来的风险和价值，用时间、质量、成本去评估自己的架构设计是否合理。 对于技术优化方面，重构这本书里面有一句话 “过早的优化是万恶之源” ，追求性能的时候加上这句话看看。。 对于评价一个数据库的优劣的时候，先看看评价指标有哪些，再用 docker 快速模拟一个环境，横向对比不同的数据库，把模拟的场景的尽可能贴近项目中的实际场景，然后对比看看。。这样大概能自己一个心里预期。。 |
 |
32
Martens 123 天前
不要为了升级而升级，系统不出问题就不动它/doge
|
 |
33
Steaven 123 天前
产品能做出来卖出去，才是硬道理。前司 10 几年前开写的产品，后端还是 php5 ，前端如文章说的 backbone.js ，但是不妨碍它被世界 500 强的公司购买使用。
|
 |
34
NightFlame 123 天前
@suuuch 我还在焦虑中
|
|
35
suuuch 123 天前
@NightFlame 看看工程类的书，纯看技术类的解决不了焦虑的问题。像项目管理相关的，软技能 这种书，然后一些市场营销之类的经典书籍都可以看看。。看多了就会觉得，技术之外其实还有更多的内容要了解。。。
|
 |
36
th3ee9ine 123 天前
8 个人的团队多还是少？ 50 毫秒的 MySQL 查询时间快还是慢？在将浏览器加载资源耗时提升 1 秒之后留给我的空间还有多少？
这段话，最近贼有感触。最近系统因为接入的服务越来越多，调用量上来后，服务的性能问题一下子暴露出来。之前对量的问题没有一个大概的概念，现在对于某句 sql 大概是否会产生慢 sql ，拖垮数据库，有了一个大致的判断，这种事情在你没有经历过，是真的很难有一个清晰的判断的。就好比你没有吃过榴莲，让你去形容榴莲是什么味道，大概率只能说它很臭吧。 |
 |
37
amon 123 天前
很好的文章，诸多观点很有共鸣。
对于普通开发者来说，技术可能不那么重要了，快速应用技术才是关键，尤其是独立开发者。 |
 |
38
Mrun 123 天前
现在大部分技术开发，已经变成了没活硬整；纯粹就是为了高速大家，我有一个玩意，很 coooooooool
|
 |
39
echoless 123 天前
你想想当年汇编程序员
想想手动挡司机 |
 |
40
checkcai 123 天前
大部分项目，瓶颈都不在技术，我想 OP 说的是不可避免的趋势。至于如何应对，也许是不仅要关注技术，还要关注技术之外的事情。
|
 |
41
yb2313 123 天前
'当然前提是你需要植入 SDK ，甚至使用指定的框架进行开发，也就是说只有接受平台的规训，才能发挥平台的最大潜能。这就是我所说的嵌入，你只不过是它其中的一环。'
这不是好事吗? 在别人的框架下开发不好吗? 如果没有任何框架, 开发会很痛苦吧, 我认为 |
 |
42
Immortal 123 天前
写的挺好
博客不支持 RSS 吗 |
 |
43
wetyq 123 天前
技术不值钱，及格就行。跳出程序员的思维看待问题，解决问题，提升综合实力才是最重要的
|
 |
44
kyznever 123 天前
技术的深入需要对应的业务场景
|
 |
45
UIXX 123 天前
说说个人理解。
拓展“demo 之外的技术深度”，本来就是靠业务推动的。做小众产品的人觉得大框架不好用，正常，本来就是不同赛道的东西，适应过程能不发生碰撞吗？ [有问题的是“技术也有贵贱”这种全民意识]，为什么都在学 K8S 这些玩意儿？因为大公司、所谓的牛人自筑壁垒鼓吹的是它，教培媒体贩卖焦虑鼓吹的是它，业界群体口耳相传不明觉厉的也是它，很少从实际出发去讨论它的价值。当我们脱离业务需求去试验它时就会有疑惑：它好像不能提升效率解决问题。 把这层矛盾转移到“探索技术深度”上无异于“锤子肯定是好用的，但就是缺少钉子，早知道多买点钉子了。”从务实的角度，最优先要考虑的应该是“有没有东西需要修补”，“要修补的到底是瓦顶还是衣服”。 “大问题”实际上是“规模业务问题”，从个体开发到规模运营，就是事物发展的递进过程。个体开发者起步时本就不应该遇上“大问题”。如果是，那说明此时的 IT 技术开发正处于初级阶段，程序员需要花很多心思去解决原理性的涉及基础学科的问题。大框架屏蔽底层，不是架空了程序员使其脱离技术深度，而是加速了程序员的跨界进程，让这个群体有更多的生产力释放到对人、对钱的关系中，从程序员生存的角度看不是坏事。 其实 AI 就是多元社会带来的其中一个挑战，它很现实地提出程序员群体的恐惧：“只拥有单一特长的人难以避免“抗风险弱”——“被操弄”——“工具化”诸如此类渐进矮化的历程。” |
 |
46
ixoy 123 天前
既然是方案整合商，发现问题，找到解决方案才是关键。
把技术当成方案粘合剂。 等哪天生活无忧闲暇时再考虑技术深度的自由探索。 其实技术深度的扩展也需要真实业务提供场景和验证的机会 |
 |
47
yuwen4012 123 天前
人类发展史也是工具进化史，所以我认为这种担心是多余的，核心是解决问题的能力，不在具体的手段如何
|
 |
48
wizzer 123 天前
举例：小电子商城，你没有成品定制开发要 1-2 个月时间，报价 5-6 万，而别人有成品简单改造即可，报价 5 千。
|
 |
49
yunpeng2015 122 天前
没必要过度“焦虑”，也没必要过度优化“屠龙技术”，最好的技术是满足你需求和场景的技术，选择合适的工具、技术来快速解决业务问题就好。。 例如：K8S 之类可能很多时候不适合个人开发者的项目。。
|
 |
50
chenliangngng 122 天前
技术的学习，来自于好奇心，而不是有用
如果赚钱是有用的话，多研究公司业务比纯卷技术有用多了 不要刻意学用不上又不想学的一个精美玩具，因为那种行为不过是被焦虑驱使的随大流 |
 |
51
junefan 122 天前
作为一个小公司的职员，我的感觉和你是一样的，我现在觉得技术不是重点，重点是业务，业务本身涉及逻辑，原理才是我们应该关心的，有些人关心性能，是因为性能在他们的业务里很重要，有些人关注组件的通用性，是因为他们的组件是给很多不同的团队做的，而类似像我这样的码农，做着 curd ，也没很多学习高级技术的机会，是因为公司本身的业务如此，我觉得，关注新技术这点，更多是为了进入更好的公司，应付面视，或者你需要给团队定技术方向，普通人不用太过关心，我觉得花时间理解业务，加入新业务，发现新业务，成为新业务里的专家更有意义。
|
Select Language