2490 字
12 分钟
2026.6.7 坑与坑
2026-06-07

挂了名在服务外包上,自己倒是没怎么参与,毕竟是水赛,然后顺便就找了比赛答辩的机会去南京玩几天。此时坐在摇晃的大巴上刚被晃醒,无聊途中就想想先从硬核的角度总结下这一年来技术学习的经历和弯路,以及产生的一些极其重要的教训,或者说此时的我看待早期正在按照csdiy.wiki老老实实去学CS61A和CS61B的自己,会提出怎么样的异议

那我想就从一年前说起,那时的我正在看Crash Course Computer Science这门更偏向是科普的课,里面并没有讲任何过于硬核的知识

2025.7 “Computers are not magic!”#

今天的我看来,最初的这门课带给我的启蒙是很大的,说的不仅仅是从知识层面的启蒙,直到今天我仍然高度肯定当时学这个的选择。至于为什么,首先它讲解了从最初的打孔纸带到互联网的整个计算机科学的发展,而且从中非常形象地讲述了最最最重要的一个概念“抽象”是怎么让计算机飞速发展起来的,”抽象“这个概念对于在计算机领域各个方向以后不管是学什么课,做什么项目都是一定是会频繁用到的,这是构建整个计算机世界的基石 A new level of abstraction。还有一个点是这门课涵盖了计算机的各个方面,操作系统、计组、计网、软件工程等各个方面,这让我能意识到我所做所学的内容究竟是什么方向的,各个方向上所做所学的内容又应该是什么样子的。哈其实现在有时候需要补点计组的基础知识我也会回过去看看

2025.8 关于MIT Missing Semester#

当时看csdiy.wiki接下来推荐学MIT Missing Semester,现在看来当时很明智的选择是就草草学了shell和git两节课没花精力看其他,missing semester的大多数内容只是作为补充信息差就够了,并不真正值得去投入地学,快速过一遍概念,大概知道是干嘛的就够了,然后等真正在生产中用到的时候自然就会掌握,就像没人会专门去学linux怎么用一样

一段重要的插曲:CS与SE#

在接下来的一段经历之前,需要说明的是Modo那个时候已经决定了做后端开发的方向。除此以外,还需要阐述一下一个对于新人来说非常需要知道的概念差异:CS与SE,也就是Computer Science与Software Engineering,也有认识偏CS方向的,之前其实一直暗暗能感觉到很多方面策略的不同,后来看到Mias老师的文章一条 SE 自学之路我觉得就非常清楚了,对这两个概念讲得非常透彻,总之一个是研究积木怎么造,一个是积木怎么搭

在现代社会里,包括曾经的小萌新时期的我在内,很多人会混淆计算机的各个方向,对这个巨大的世界认知往往模糊不清,认为一个人能完成整套业务需求、做web的一定会写数学算法、做理论的一定能写好项目代码等等

所有学计算机的学生大概都会分化成这两个方向,最终从事的工作基本也是。而这两个方向的学习内容和学习方法论是很不同的,这点会在接下来这段对于CS61A与CS61B的反思中体现。而我所走的后端开发方向很明显就是SE方向

2025.9 反思所谓的神课CS61A与CS61B#

那时我连着学了所谓的计算机入门“神课”CS61A与CS61B,不过61B一半就stop了后面就开始写后端去了。那时我还没有对CS与SE两个方向的学习方式差异有清晰的认识,于是就这么学下去了。当时是和另一个做底层方向的朋友一起学和讨论的,现在来看很明显他是CS方向,很多学习方式会对比SE方向,需要学院派一些。然后接下来我想谈的是CS方向与SE方向的差异在61A与61B两门课的学习上体现出来的侧重点的区别。CS61B的内容是数据结构与算法,对于CS方向,侧重点应该在各个具体数据结构的学习;而对于SE方向,侧重点应该在关注数据结构是如何被包装在实际项目里进行运用的。所以从我的角度出发,61B的后半部分讲得是具体数据结构的各种细节的部分其实并不需要细学。同样的对于CS61A,目前看来帮助比较大的是前三分之二,而后三分之一虽然当时学的时候觉得lisp语言体现出来的程序即数据的概念确实很有意思,以及元编程、尾递归优化啥的,当时花了不少时间去研究,但对于我现在的方向来说这些并不重要,或者说学它的优先级不太高。当然我也不否认这两门课对于当时刚入门的我来说确实还是有很多部分挺有用的,以及课程和练习也是非常有意思的。同时,再从SE的方向出发,或许当初其实根本就不需要学这两门课?,而是上来就直接干实际项目,不会就去查文档、问ai,在生产环境里学。所以实际上现在看来主要还是在这两门入门课上花的精力有点太多了。

2025.12 SE-工程师永远是在干中学#

那时候过完了61A 61B,然而发现一个严重的问题,大概两个月前,我说我要走后端方向,所以就拷问自己:你学了这么久会后端吗。发现自己好像除了curd好像啥都不会,也没有写过一点后端项目。然后那个时候我做了一件如今看来十分学生思维的一件事,就是开始问Veno和smallfang后端该怎么入门、怎么学web后端,当时感觉是被后端这一整个大领域唬住了,甚至开始焦虑这个问题,那时好像有几天持续处于这种莫名其妙的迷茫感中。但是到真正上手去写项目时,这些问题其实根本就不存在了,先前的这种所谓的迷茫是没有意义的。现在看来,哪怕是0基础,直接上手硬干就是了,所谓的后端的学习就应该是在实际项目中解决问题,在这个过程中不断查文档,尤其现在更方便可以问ai,然后就会写后端了,后来接触了旭哥这边项目开发也是一直听到强调“工程师永远是在干中学”的观念,想来这算是非常重要的lesson,虽然说很早之前就在说任务驱动,但是没经历过教训还是不够深刻吧,而SE的学习过程就应该是这样任务驱动的

2026.2~ 对浮于表面的技术栈袪魅#

从这段时间开始,Modo在后端开发上算是进入状态了,也是感觉自己在技术上飞速进步的一段时间,中间其实做了很多事吧,不管是最早写着玩的一些玩具后端,再到跟着一些go后端项目敲和之前写的比较难评的开源实习,不过中间很多未必能量化,就一笔带过了,然后直到现在就是写Paramer的后端。这中间没算踩到什么坑,主要幸运在一直都有前人愿意指导吧。中间很有感触的一点是对所谓的“技术栈”袪魅,什么意思呢,比如对于后端开发来说,不管是拿Java写还是Go还是Rust写,写后端很多的核心是不会变的,从业务角度上,非常核心的能力是业务开发里对需求的理解、怎么拆分、根据需求进行技术选型以及和产品经理的角色的沟通等等。技术角度上, 比如不管哪个语言写的后端总会遇到双写一致性以及高并发之类的技术问题,架构上的问题也是一样,而所谓的语言只是工具。其他的很多技术栈、各种名词也是一样的,比如所谓“会Rabbitmq”,这仅仅只是会一门工具,而其中的核心应该是能够解决消息队列在应用时会遇到的各种常见的技术问题。掌握了这些核心的东西之后,应用各种技术栈上去其实是很快的事

Now#

总之要是回到一年前那时候,我可能会快速把那几门入门公开课花一个月时间快速过一遍就好,当初看到的csdiywiki的很多东西也是未必跟得上时代了,也没有对个人情况和方向有特化,嗯然后就直接上手干实际项目了吧,那样或许会更好吧,但或许又是因为走过这些弯路吧,所以现在能清晰认识到总结出来的这些教训呢,过去的时间无法重来,我想我也无从得知了