https://b0weny-qwq.github.io/Blog/tags/%E5%AD%A6%E4%B9%A0%E8%B7%AF%E5%BE%84/Recent content in 学习路径 on BlogHugo -- gohugo.iozh-CNMon, 01 Jun 2026 00:00:00 +0000https://b0weny-qwq.github.io/Blog/p/traditional-development-modern-development-gap/Mon, 01 Jun 2026 00:00:00 +0000https://b0weny-qwq.github.io/Blog/p/traditional-development-modern-development-gap/<h1 id="传统开发和现代开发之间差的不是会不会写代码">传统开发和现代开发之间，差的不是会不会写代码 </h1><p>我最近越来越觉得，很多人学嵌入式，问题不在于不努力，而是一开始就被带进了一条很旧的路。</p> <p>最典型的情况就是：一入门就去 <code>B</code> 站找视频。</p> <p>这件事本身没问题。视频对初学者很友好，能让人很快看到一个东西怎么跑起来，也能压住刚接触硬件、寄存器、外设、开发板时的恐惧感。问题在于，很多人找视频时不看年份，不看适合什么基础阶段，也不会判断这套教程背后的工程方式是不是已经落后。</p> <p>路径依赖就这么形成了。</p> <p>别人用什么软件，他就用什么软件；别人怎么建工程，他就怎么建工程；别人怎么点 <code>Keil</code>，他就怎么点 <code>Keil</code>；别人怎么复制例程，他就怎么复制例程。短期看起来是在学习，实际上很可能是在把自己训练成旧流程的执行者。</p> <p>再往后，这种依赖会把人和现代开发方式直接隔开。</p> <h2 id="教程会教你怎么用但很少教你怎么看工程">教程会教你怎么用，但很少教你怎么看工程 </h2><p>很多教学视频最大的问题，是只告诉你“怎么用”。</p> <p>怎么新建工程，怎么点按钮，怎么配置外设，怎么把例程跑起来，怎么照着老师的步骤把灯点亮、把串口跑通、把屏幕刷出来。</p> <p>这些东西对入门有用，但远远不够。</p> <p>真正决定工程能力的，不是你能不能照着教程把某个外设跑起来，而是你能不能看懂一个项目为什么这样组织：目录为什么这么分，驱动为什么这样抽象，接口为什么这样暴露，模块之间为什么不能乱依赖。</p> <p>这些视野，普通入门视频很少会给。</p> <p>因为它的目标往往只是让你“跑起来”，而不是让你理解一个项目如何长期维护、如何多人协作、如何跨平台迁移、如何被工具链和 <code>agent</code> 接管一部分重复流程。</p> <p>如果长期停留在这种学习方式里，工程能力和协作能力都会被压低。</p> <p>你会很熟悉某个视频里的步骤，但离开那个模板就不会做；你能改一个例程，却不知道怎么设计模块；你能把功能堆上去，却不知道怎么控制复杂度。最后写出来的东西能跑，但不能碰。</p> <h2 id="很多传统习惯已经不适合现在了">很多传统习惯已经不适合现在了 </h2><p>我不是要全盘否定传统嵌入式开发。</p> <p>在过去，很多习惯是有现实原因的。比如反复仿真、在 <code>Keil</code> 里盯寄存器、一步一步单步调试，这些在当时完全可以理解。早期开发板、芯片、下载器、调试环境都没现在这么方便，<code>Flash</code> 擦写次数也确实是一个需要考虑的因素。</p> <p>那时候谨慎一点、慢一点、靠仿真多确认几遍，很正常。</p> <p>但现在是什么年代了？</p> <p>很多小工程里的静态错误、函数报错、类型问题、依赖缺失、拼写错误、配置问题，根本不需要人一直在 <code>Keil</code> 里来回点。你完全可以让 <code>agent</code> 看编译日志，让它跑静态检查，让它根据报错定位问题，再由人判断修改是否合理。</p> <p>构建、检查、修明显错误，本来就应该自动化。</p> <p>不是所有问题都需要上来就进仿真器，也不是所有问题都值得人肉盯寄存器。寄存器当然要会看，底层当然要懂，但不能把所有开发问题都退化成“我打开 IDE 手动调一遍”。</p> <p>现代开发要做的，是把重复动作交给工具，把人放回判断层。</p> <p>如果一个人一直停留在传统流程里，把大量时间消耗在低级重复劳动上，那他的工程能力提升会非常慢。因为他每天都在处理表层问题，而不是在训练自己理解结构、边界、抽象和系统。</p> <h2 id="入门视频可以看但不能一直靠视频">入门视频可以看，但不能一直靠视频 </h2><p>入门视频可以看。</p> <p>刚开始学的时候，视频能帮你建立基本直觉：开发板长什么样，工程怎么打开，代码怎么烧进去，串口怎么打印，外设怎么验证。这些东西如果完全靠文档硬啃，确实会让很多人卡在门口。</p> <p>但视频只能当入口，不能当长期学习方式。</p> <p>到了一定阶段之后，必须从被动看教程，切换成主动读文档、主动搭工程、主动查资料、主动设计接口。</p> <p>尤其是嵌入式开发，真正重要的信息往往都在官方文档、芯片手册、SDK 说明、开源项目、构建脚本和代码结构里。只会看视频的人，很容易养成一种很危险的习惯：没有教程就不会写，没有例程就不会动，没有别人演示就不知道下一步。</p> <p>这不是学习，是依赖。</p> <p>现代工程师必须学会从文档开始工作。看到一个新芯片、新 SDK、新 RTOS、新库，应该能自己读说明、看示例、拆结构、建最小工程、验证接口，而不是第一反应去搜“有没有保姆级教程”。</p> <p>保姆级教程看多了，人也会被养成保姆级工程师。</p> <h2 id="要从优秀开源工程里学工程">要从优秀开源工程里学工程 </h2><p>想提升工程能力，光看教程不够。优秀开源工程必须多看。</p> <p>不是只看它某个函数怎么写，而是要看完整结构：项目目录怎么组织，模块怎么分层，驱动怎么抽象，接口怎么命名，平台相关代码怎么隔离，配置系统怎么处理，测试怎么放，文档怎么写，构建系统怎么把这些东西串起来。</p> <p>工程能力不是单点技巧，而是一整套判断。</p> <p>为什么这个模块不应该依赖那个模块，为什么这个文件应该拆出去，为什么这个接口不能暴露太多细节，为什么这个实现要留出可移植空间，为什么一个功能不能随便塞到全局变量和宏定义里，这些东西都需要长期观察、模仿、实践和复盘。</p> <p>看优秀工程，本质上是在训练工程审美。</p> <p>你要逐渐建立一套自己的工程准则：代码要可读，结构要清晰，接口要稳定，依赖要克制，平台差异要隔离，重复逻辑要收束，文档要能解释边界，构建要能复现。</p> <p>写屎山绝对不应该被纵容。</p> <p>不是说代码一开始就要完美，而是你不能把“能跑”当成唯一标准。能跑只是底线，可维护、可扩展、可协作，才是工程的要求。</p> <h2 id="软件和硬件都需要审美">软件和硬件都需要审美 </h2><p>我一直觉得，软件和硬件其实很像画画。</p> <p>刚开始照猫画虎当然有效。别人怎么画，你先跟着画；别人怎么写工程，你先模仿；别人怎么设计电路，你先照着理解。这个阶段很正常，因为人一开始都需要参照物。</p> <p>但如果想往高处走，迟早要有自己的创作和风格。</p> <p>你要知道什么样的结构是干净的，什么样的接口是克制的，什么样的布局是可读的，什么样的封装是有意义的，什么样的复杂度是危险的。</p> <p>这就是审美，不玄。</p> <p>工程审美不是玄学。它来自大量阅读、大量实践、大量踩坑，也来自你对系统边界和长期维护成本的敏感度。</p> <p>一个只会复制粘贴的人，也许能把功能堆出来，但他很难成为系统工程师。因为系统工程师要负责的不只是某一段代码能不能跑，而是整个系统能不能被理解、被维护、被扩展、被交给别人协作。</p> <p>这也是我区分 <code>CV</code> 工程师和系统工程师的标准。</p> <p><code>CV</code> 工程师只关心哪里有现成代码，怎么复制过来，怎么让它先跑起来。系统工程师会关心这段代码放进来之后，项目结构会不会被污染，接口会不会变乱，依赖会不会失控，后面的人还能不能读懂。</p> <p>一个在拼功能，一个在建系统。</p> <h2 id="现代开发要求人主动升级">现代开发要求人主动升级 </h2><p>传统开发不是完全错误，它只是有时代背景。</p> <p>但如果到了现在，还把所有经验都停留在旧 IDE、旧教程、旧流程、旧例程里，那就不是“基础扎实”，而是没有升级。</p> <p>现代嵌入式开发已经不只是写寄存器和调外设。它包含工具链、构建系统、文档开发、自动化测试、开源协作、架构设计、跨平台抽象，也包含 <code>agent</code> 介入之后的人机协作方式。</p> <p>人不该被低级流程绑住。</p> <p>该看视频的时候看视频，该读手册的时候读手册，该用 <code>agent</code> 的时候用 <code>agent</code>，该自己判断架构的时候自己判断。不同阶段要用不同方法，而不是拿入门阶段的方法用一辈子。</p> <p>如果只满足于“我照着教程能跑”，那最多只能停留在执行层。</p> <p>真正的提升，是从会用工具，到理解工程；从复制例程，到设计结构；从修局部错误，到把握系统边界；从照猫画虎，到形成自己的工程风格。</p> <p>到了这一步，才能说自己不是单纯的 <code>CV</code> 工程师，而是在往系统工程师的方向走。</p>