2022年之前程序员的工位上通常有三样东西一个大屏显示器、一块贴满便签的隔板、一本翻得快散架的技术手册。那不是AI补全代码的年代也没有随手可用的云原生底座连Docker都要跟团队反复解释“为什么值得用”。我把那会儿的开发方式叫“古法软件开发”——不是贬义。恰恰是那些手配环境、手写构建脚本、手工部署上线的日子让后来所有“现代化”都变得顺理成章。这篇文章不打算写成编年史我按自己经历的工程现场来拆从软件开发的整体流程到环境搭建、调试、嵌入式联调、发布运维再到常见问题的排查思路全部按照2022年前的主流实践来复盘。适合经历过那个时代的开发者回忆对比也适合正在学软件开发流程、准备机器考试或想进入嵌入式软件开发的年轻人看看所谓“古法”里到底藏着多少今天的底层逻辑。1. 古法软件开发的整体形态流程、工具与协作方式1.1 什么是“古法软件开发”我自己的定义里“古法”大致指2010年代到2022年之前的这段时期。那时候企业级开发的主力技术栈已经相对稳定Java和C/C占据大半壁江山嵌入式领域C语言还是绝对主角移动端刚刚从Eclipse过渡到Android Studio前端也经历过jQuery到Vue/React的换代。但最明显的特征不是语言而是“自动化程度低”和“工具链沉重”。举个例子2022年前很多团队启动一个新项目开场不是初始化仓库而是先在本地把一套环境配置出来。Java开发者要手动配JDK、配Maven仓库改Eclipse的工作空间编码嵌入式开发者更苦装Keil MDK要选芯片包要办License要配置烧录器驱动。哪个环节出问题一上午就搭进去了。这种状态放到今天年轻人可能很难理解为什么不用容器一键拉起为什么不用插件帮我们自动补全配置原因也简单当时Kubernetes还在普及早期Docker虽然已经有了但很多公司的服务器环境根本不允许随便用容器。加上团队对自动化的接受度参差不齐大部分工作仍然靠“人肉”来完成。所以“古法”的核心特征可以归纳成四点第一环境配置高度依赖个人经验第二构建和部署链路漫长且易错第三知识沉淀靠文档和老带新第四代码评审、测试、发布这些环节都需要人工介入。这些特征谈不上先进但有一点无与伦比的价值——它逼着每个开发者把底层原理弄明白因为你没有办法靠工具糊弄过去。1.2 流程方案的选型逻辑瀑布、迭代与敏捷的混搭软件开发流程在2022年之前给人的感觉更像“混搭”。教科书上讲瀑布模型、迭代模型、敏捷开发但真实项目里很少有一种流程从头用到尾。我记得2017年参与一个车载固件配套工具的开发项目刚启动时需求方只给了一页纸的评估版需求大家第一反应是“先把需求文档写出来”。于是我们就用类似瀑布的做法先做总体设计画模块框图写接口定义再进入编码。这个做法在嵌入式相关项目里特别常见因为硬件联调一旦返工成本远超改几行软件代码前置的评审和确认就是省钱。而当项目推进到联调阶段需求开始频繁变化我们又自然过渡到两周一个小迭代每次迭代结束都拉上测试和硬件工程师一起评审。这个节奏其实就是敏捷的变体只是没有挂Scrum的牌子。这套打法现在的项目管理理论可能觉得“不够专业”但它背后有明确的逻辑需求确定性不高时可以用迭代拉短反馈周期需求相对明确的部分则保持瀑布式的文档和评审。2022年前的优秀开发者不会死守某个流程而是根据项目风险调整流程。这个经验放到今天依然有效因为无论Jira管理还是飞书项目协作工具只能承载流程不能替你做判断。很多人问“软件开发流程”到底是什么我的回答是它不是流程本身而是对变化和质量的应对策略。1.3 团队协作与知识沉淀没有Copilot靠的是人传人2022年前团队协作方式比现在要“重”很多。代码评审不流行在GitLab上点几个按钮常见做法是把diff贴到邮件里或者拉着椅子过来“结对走读”。分布式团队更多靠QQ群、微信群、邮件列表同步状态一份接口文档放到禅道或Confluence上更新不及时就是事故源头。知识沉淀在这个年代特别依赖两样东西一个是文档一个是口头传承。新接手一个模块第一件事是找到老同事请他把架构图和你讲一遍然后自己翻代码、查Wiki、看提交记录。遇到奇怪的问题第一反应是搜索搜不到再问群里的资深同事。Stack Overflow上同类型问题非常多很多答案质量到今天来看也不算过时。这个过程效率说实话挺低的但它培养了“自己找答案”的能力。我觉得这是古法时代留给开发者最宝贵的财富遇到问题先剥丝抽茧而不是直接让AI给一个不一定正确的答案。那段时期的文档质量参差不齐有写得很详细的设计文档也有只剩一个标题的空Wiki。但有意思的是真正有价值的文档通常不是“按流程写出来”的那种而是工程师在排掉一个难缠bug后主动补的排查记录。2022年前很多团队的经验库就是这样靠自觉长出来的没有AI帮忙归纳也没有自动知识库每一篇都是血泪换来的。2. 古法开发的核心实操环境搭建、编码调试与工程管理2.1 一天从配环境开始三件套与那些隐藏的坑古法开发的第一道门槛是环境准备。我拿Java后端开发举个例子那个年代入职第一天大概率是配环境三件套JDK、Maven、开发IDE。配JDK有讲究不能光双击安装包点下一步。系统变量里要手动新建JAVA_HOME值指向JDK安装目录再修改PATH变量加入%JAVA_HOME%\bin有些老教程还会让你配CLASSPATH。这些操作现在看起来多余但在当年IDE和构建工具都是凭环境变量去找JDK的漏配一个后面编都编不过。我还遇到过因为装了多个JDK版本导致编译报错的情况排查了半天最后发现是PATH里旧版本的路径排在了前面。这类问题没有捷径只能命令行敲java -version和javac -version逐个查。Maven也一样本地仓库默认在用户目录下的.m2文件夹第一次构建要从中央仓库拉依赖网络慢的话能卡到怀疑人生。古法开发者手里基本都有一个settings.xml模板里面配好淘宝镜像或私服地址这几乎是入职第一周就学会的“保命技能”。再往后是IDEEclipse那年头导入Maven项目比较折腾需要m2e插件有些老项目甚至要手动把依赖加进Build Path。IDEA逐渐普及后这类问题变少了但IDEA那会儿也有自己的脾气比如中文注释乱码、编码设置不统一一不小心又得调Compiler的encoding选项。这些实操在今天看来都是基础中的基础但它们解释了为什么那时候一个项目从git clone到本地跑起来能花半天时间。我也建议现在学Spring Boot或嵌入式开发的朋友即使有云开发环境也别跳过本地手动配一次环境的过程因为配置里暴露的问题能帮你理解工具链的依赖关系。2.2 版本控制迁移实记从SVN到Git的折腾版本控制是古法软件开发里最有代表性的一章。早期的公司项目用SVN居多服务器上开个仓库开发者checkout出来工作每改完一个功能commit一次。集中式版本控制的好处是权限好管理目录结构清晰tags和branches也能做到。但分支操作很别扭merge经常冲突而且有些团队的SVN仓库长期没人清理trunk和branch之间的关系乱到只有管理员清楚。Git进入国内企业主流的节点大概在2015年前后GitHub上开源项目越来越多很多开发者在个人项目里用Git已经很熟练然后推动公司从SVN迁移。我们团队2018年迁移过一次坑非常具体第一老SVN仓库里的历史提交要不要保留保留的话要写脚本做作者映射不然显示的全是svn用户名第二团队成员对新分支模型的认知不统一还用SVN的思路操作Git比如直接在master上提交代码或者“怕创建分支造成麻烦”。第三权限控制从目录级别变成仓库级别很多原来靠目录隔离的“伪多项目”仓库被迫拆成多个Git仓库。迁移之后分支模型成了新的争论点。有人推崇Git Flow功能分支、开发分支、发布分支、hotfix分支一套搞得非常齐全有人主张简单流只有master和feature分支。最后实际执行往往根据团队情况妥协。我的看法是分支模型没有绝对优劣关键是发布策略。如果团队需要同时维护多个线上版本Git Flow天然合适如果只维护一条主线且持续部署简单分支模型更顺手。这也是2022年前软件工程领域少有的、被争论但又确实有价值的话题。2.3 编码调试三板斧日志、断点和边界试探古法开发中的调试和今天用AI辅助定位Bug差别很大靠的是经验和系统方法。我总结是“三板斧”日志、断点、二分定位。先说日志。Java后端项目普遍用log4j或logback线上问题基本靠日志定位。这里有门学问日志级别怎么定普通业务留INFO关键流程和异常留WARN和ERRORDEBUG信息一般只在开发环境开。很多线上事故最后复盘发现是日志打得太少只有一行“系统异常”根本没有上下文。所以古法开发者写日志时习惯把关键参数一起打出来比如“用户ID123下单失败库存不足”这条日志的价值远高于“下单失败”。再说断点。IDE里的断点调试大家都会但古法开发者会用的高级技巧包括条件断点(比如在循环里当i500时停下来、方法断点、异常断点。在排查多线程问题时在看板上同时挂多个线程的调用栈能很快找到死锁位置。嵌入式开发则略有不同很多时候断点打在中断服务函数里会造成系统崩溃这时候只能靠串口打印或者观察寄存器值。最后是二分定位。当代码逻辑复杂、Bug难以通过阅读发现时把可疑代码区域内的一条路径分成两半先用日志或者断点确定Bug在前半段还是后半段再逐层缩小范围。这个方法跟“git bisect”是一套思想Git提供的二分查找提交功能就是自动帮你在提交历史里定位引入问题的那个commit。2022年前没有现在那么多可观测性工具这套手工排查方法就成了每个开发者必须掌握的“吃饭家伙”。3. 嵌入式与硬件场景下的开发现场3.1 交叉编译与工具链为什么Keil还在GCC也在嵌入式软件开发在2022年前就是一门“手艺活”环境门槛比纯软件高不少。拿ARM Cortex-M系列单片机来说主流的开发方式有两种一是Keil MDK二是IAR EWARM开源圈子则普遍用arm-none-eabi-gcc工具链加Makefile。很多初学者问该学哪个我的答案是工具只是入口重点是理解交叉编译。交叉编译的意思是“在一种处理器架构的电脑上编译出另一种处理器架构能运行的程序”。PC上是x86单片机是ARM所以编译器必须针对ARM指令集生成代码。这套理念对应到实际工程就是你要配置好编译器、链接器、启动文件和芯片头文件。Keil MDK把这些整合得比较好在界面里选一下芯片型号点一下下载就能烧录进去。但很多问题就出在“整合得好”上面开发者不清楚背后发生了什么遇到“Error: Flash Download failed”就懵了。相比之下Makefile加GCC的路线更透明。你能看到编译命令、链接选项、内存布局脚本(link script)里的ROM和RAM分配。2022年前很多嵌入式工程师面试题喜欢问gcc的编译过程问堆栈大小如何设置翻过来问的其实是工程构建的理解深度。我自己做固件项目时早期从Keil上手后来切到Makefile加arm-none-eabi-gcc花了一段时间适应但对链接器脚本的理解明显上了一个台阶。这个收益到今天也还在。3.2 烧录、调试与软硬件联调很灵异但真相往往是时序嵌入式开发真正痛苦的地方不在编译而在软硬件联调。一个功能在仿真器里跑得好好的烧到真机上一上电就死机这种“灵异事件”很常见。2022年前没有太多高级工具可用排查手段就那几样调试器、示波器、万用表、串口打印。调试器有JTAG和SWD两种常见接口。JTAG有四根线加复位线速度快管脚占用多SWD只要两根线节省IO适合空间受限的板子。用调试器打断点的时候有一个经典坑如果你把断点打在中断服务函数里而系统又一直触发该中断程序就会不停停在断点上看上去像死机。这时候要善用“禁用中断后单步”或者改成调试外设寄存器。更麻烦的是嵌入式程序里有一个独立于CPU的看门狗如果你在调试状态下停留时间过长狗就超时复位程序直接重启。很多新手第一次遇到以为代码跑飞了其实是调试器把狗饿死了。示波器和逻辑分析仪是排查硬件时序的重要工具。有一次我做I2C通信调试软件轮询寄存器检查通信是否完成从日志看一切正常但外设就是没反应。最后用示波器抓波形才发现SCL的频率远高于从设备支持的上限。这问题你在IDE里看一百遍代码也看不出来。古法时代的嵌入式工程师很多都是在示波器面前蹲了太多次才学会“软件问题看波形硬件问题看时序”。串口打印是最后一道保命手段。我记得很多老项目喜欢用重定向printf到UART目的就是方便看log。但要注意波特率匹配还有打印太多会拖慢实时性影响电机控制这类对时序敏感的应用。3.3 BMS这类嵌入式项目到底在学什么热词里有一个“BMS软件开发学习路线”BMS是电池管理系统的缩写在新能源行业里非常典型也是嵌入式方向里很有含金量的细分场景。一个BMS系统的软件通常要搞定这么几块电芯电压采集、温度采集、电流采集、SOC估算、均衡控制、过压欠压过流保护以及和整车控制器或充电机之间的CAN通信。学习路线可以这样规划第一步把C语言和数据结构吃透尤其是指针、数组、环形缓冲区这类基础第二步找一块STM32类的开发板跑GPIO、ADC、定时器、UART、CAN外设这是硬件抽象的具体认知第三步接触RTOS比如FreeRTOS理解任务调度、信号量、消息队列因为BMS里保护逻辑和通信逻辑需要不同优先级第四步研究通信协议CAN是最核心的要懂CAN帧结构、ID分配、DBC文件解析第五步了解功能安全和故障诊断看一些ISO 26262的基础概念。面试题方面嵌入式软件开发的常见考点非常稳定volatile关键字的作用、中断服务函数的注意事项、堆栈溢出怎么排查、static修饰符在不同位置的影响、指针和数组的区别、一个大小端转换的实现。这些问题在2022年前和2022年后几乎没有变化。因为它们考的不是知识量而是你有没有真正把C语言和单片机底层吃透。如果你正打算走嵌入式面试刷这些题比追逐新框架有用得多。4. 交付、发版与运维看不见的“最后十公里”4.1 从代码到发布测试、构建与手工部署的极限古法软件开发的最后一个环节是发版也是最容易翻车的环节。2022年前很多团队没有完善的CI/CD流水线Jenkins算比较超前的但也有大量项目仍保留“手动构建手动上传”的习惯。典型的发布流程长这样开发完成后测试人员先在测试环境验证测试环境通常是内网一台服务器由运维或开发手动把war包或jar包扔到Tomcat目录下确认没问题后再由开发打包生产版本上传到生产服务器停服、备份、替换、重启整个过程中所有人都在群里同步状态。这里最容易出问题的就是配置差异。开发环境连的开发库生产环境连接的是生产库如果配置项没分离或者application.properties里写死了内网IP上线后必然连接超时。古法团队的解决办法是维护多套配置文件打包时用不同profile切看似笨拙但比没有强得多。前端项目同样不轻松那时候构建工具从Grunt到Gulp再到webpack升级频繁。webpack的配置动辄上百行loader和plugin版本相互不兼容改一个版本要连带升好几个依赖。所以前端同学发版前一般要本地先npm run build确认能出dist目录再往测试服务器拖。2018年前后很多团队开始引入GitLab CI把构建和部署脚本化算是一次比较大的进步。4.2 机考与课程设计背后通用的能力模型“软件开发流程”“App软件开发课程设计”“通用软件开发机考”这些热词集中指向一个东西工程化基础能力。2022年前后大厂校园招聘的通用开发岗普遍有机考环节考的题目和框架无关主要是数据结构、算法、语言特性和简单的系统设计。很多人吐槽“工作又用不到算法”但从企业角度机考考察的其实是候选人在规定时间内把复杂问题拆解、实现并验证的能力。这个能力在任何软件开发流程里都是核心。课程设计也类似。一个App软件开发课程设计标准的做法是需求分析→原型设计→数据库设计→编码→测试→答辩。如果认真走完这套流程你收获的不只是“会写Java/Kotlin代码”而是了解了软件从想法到交付的整体链路。我见过很多应届生简历里写着熟悉软件开发流程但问他“需求变更了怎么办”、“数据库表设计要不要反范式”支支吾吾答不上来。这是因为他们跳过了分析设计这一步直接上来写页面。古法年代没那么多捷径反而让人把流程里每一环都过了一遍功底自然扎实。4.3 线上事故与回滚预案手忙脚乱后的教训每个古法开发者都经历过线上事故我也不例外。印象最深的一次上线一个新版本后数据库连接池瞬间被打满接口响应从50毫秒飙到10秒紧接着一堆超时重试把数据库直接压垮。当时第一反应是“赶紧回滚”但因为我们没有自动化回滚脚本只有手工备份的旧包愣是多花了10分钟才恢复。那10分钟里在线用户全部受影响。这次事故后来复盘总结了几条经验第一生产环境必须保留上一个稳定版本的包最好保留2个以上第二数据库结构的变更一定要考虑回滚脚本第三发版最好选择低峰期并安排至少两个人协同操作第四一旦出现异常先回滚再排查不要试图在生产环境调试。这些在今天听起来是常识但在2022年前很多团队连“回滚预案”这个名词都没有。现在再看那些重视发布规范、有回滚机制的老团队反而是最靠谱的。5. 常见问题与排查技巧实录5.1 编译链接问题的速查表古法开发里编译和链接报错几乎每天都会碰到。有些错误翻来覆去就那几类我把最高频的整理成了下面这张表方便参照排查。报错倾向常见原因排查思路找不到符号/包依赖缺失、类路径未配置检查Maven/Gradle依赖是否完整IDEA里的Project Structure是不是没把模块导入编译乱码/编码错误文件编码与编译器不一致统一项目为UTF-8检查IDE编码设置、Maven编译插件encoding参数内存溢出构建堆内存太小调整MAVEN_OPTS或Gradle JVM参数-Xmx1024m起步链接失败undefined reference库没有链接或函数声明与实现不一致嵌入式项目里检查头文件路径和link库顺序注意静态库依赖顺序也会导致找不到符号代码自动退后/中文注释乱码IDE的encoding和项目实际编码不匹配把IDE的file encoding全改成UTF-8重新reload工程Flash Download failed芯片型号选错、烧录器驱动异常、Flash算法不对核对Keil/IAR里的Device选项重新选择FLM文件检查调试器连接这张表看起来简单但每一条背后都有真实的加班故事。尤其是编码问题2022年前后出现过多少次因为GBK和UTF-8不一致导致的乱码数不清。我的体会是遇到编译问题不要急着改代码先看环境底层配置。5.2 运行时问题的定位流程运行时问题比编译问题难因为它不报错或只报一个笼统的错误。我惯用的定位流程是这样的第一步看日志找异常栈。日志级别不够就临时加日志重新发布如果怕影响性能只对关键方法加INFO。第二步如果是Java应用用top看进程CPU和内存占用再用jstack抓线程快照重点看有没有大量线程处于BLOCKED或WAITING状态。典型死锁场景就是这样暴露的。第三步如果是数据库相关问题慢查询日志和show processlist是直接证据很多连接池耗尽就是代码里忘关连接导致。第四步确认是偶发还是必现偶发问题要尽量保留现场比如把堆栈和当时的请求参数记录下来。嵌入式场景的运行时问题又是另一套思路。程序复位了先查电压和看门狗再查中断优先级配置还要留意硬件上拉电阻是否影响电平。这类问题没有固定套路的排查工具更多靠经验和耐心的逐项排除。我自己遇到过一次固件偶发重启排查了两周最后发现是电源模块在负载突变时产生了一个毛刺把复位引脚拉低了。软件上一行代码都没改硬件改了个电容位置问题消失。这类经历会让你对“软硬件不分家”这句话有深刻理解。5.3 团队协作问题清单2022年前协作问题很多时候比技术问题更消耗人。我遇到的典型问题有这些多人同时改同一个文件SVN和Git里的Merge冲突此起彼伏接口文档更新不及时前端按照老文档联调后端已经改了字段名测试环境不一致开发本地是好的测试环境必现崩溃代码评审流于形式没人看细节导致低级问题直接流到生产。解决办法说穿了并不复杂第一代码尽可能拆小合并批量提交、跨多个模块的大改动是冲突的温床第二接口文档必须进版本库和代码一起更新而不是放在在线文档里随手改第三测试环境无限接近生产环境尤其数据库版本、中间件版本、配置文件必须保持一致第四评审人要对变更逻辑负责而不是只点个“通过”。这些经验从2015年管用放到现在同样管用工具变了人的问题不会凭空消失。6. 从古法到智能时代经验沉淀与迁移建议6.1 2022年前后AI从“被开发对象”变成“开发助手”2022年前“AI软件开发”这个词的含义和今天完全不同。那时候说AI软件开发指的是“开发一个AI系统”要么做机器学习模型训练要么搭数据标注平台要么部署推理服务。开发者的工作重点是处理数据、调参、写Python脚本、优化推理性能。到了2022年底之后AI大模型开始以辅助编码工具的身份进入日常工作自动补全、自动生成测试用例、解释他人的代码这时候的“AI软件开发”越来越多地指“用AI辅助做软件开发”。这个转变的影响很深远。古法时代开发者写代码必须逐字推敲、自己设计边界条件这种“慢工出细活”的训练让基本功很扎实。AI辅助时代产出代码的速度变快了但审查代码的能力、理解业务需求的能力、判断设计好坏的能力反而更加重要。我见过不少人用AI生成一段代码跑通了就觉得完事却说不清为什么这么写更谈不上优化。结合我的经验AI工具最适合用来“提效”不适合用来“替思”。6.2 古法经验在今天还值不值钱有年轻人问2022年前的东西是不是都过时了我的观点是工具会过时方法论不会。比如你理解了手动配JDK和Maven的底层逻辑云IDE的容器启动在你眼里就不是黑盒你经历了从SVN到Git的迁移面对新的版本控制工具就能更快掌握你亲手用控制台定位过一次线上故障再看可观测性平台的指标和链路理解完全不一样。热词里那些“嵌入式软件开发面试题”“通用软件开发机考”考来考去其实还停留在古法时代沉淀下来的核心知识。C语言基础、数据结构、操作系统、网络协议、工程化思维这些东西都不会因为AI工具的出现而失效。它们就像武术里的基本功练的时候枯燥用的时候才知道珍贵。6.3 给后来者的个人体会我做了这么多年软件开发最深的体会是别嫌“古法”烦也别把“新工具”神化。技术迭代很快但你解决问题的思路、排查问题的步骤、把事情搞清楚的习惯才是真正能带走的能力。如果你现在刚开始学开发我的建议很简单——找一个略微过时但仍能跑的小项目手动做一遍不依赖AI工具从配环境到发布完整走一遍流程。这个过程可能会让你觉得绕远路但走完以后你会知道自己学到的东西比看十遍教程都多。最后再分享一个小技巧不管用什么工具、什么框架养成写工程笔记的习惯。把每年遇到的典型问题、排查过程、最终结论记录下来攒三年再回头翻你会发现这些笔记才是你最值钱的技术资产。 
长河君 · 2026/9/10 15:58:45 · 阅读 1.2k 古法软件开发复盘：从环境搭建到嵌入式调试的底层逻辑
2022年之前程序员的工位上通常有三样东西一个大屏显示器、一块贴满便签的隔板、一本翻得快散架的技术手册。那不是AI补全代码的年代也没有随手可用的云原生底座连Docker都要跟团队反复解释“为什么值得用”。我把那会儿的开发方式叫“古法软件开发”——不是贬义。恰恰是那些手配环境、手写构建脚本、手工部署上线的日子让后来所有“现代化”都变得顺理成章。这篇文章不打算写成编年史我按自己经历的工程现场来拆从软件开发的整体流程到环境搭建、调试、嵌入式联调、发布运维再到常见问题的排查思路全部按照2022年前的主流实践来复盘。适合经历过那个时代的开发者回忆对比也适合正在学软件开发流程、准备机器考试或想进入嵌入式软件开发的年轻人看看所谓“古法”里到底藏着多少今天的底层逻辑。1. 古法软件开发的整体形态流程、工具与协作方式1.1 什么是“古法软件开发”我自己的定义里“古法”大致指2010年代到2022年之前的这段时期。那时候企业级开发的主力技术栈已经相对稳定Java和C/C占据大半壁江山嵌入式领域C语言还是绝对主角移动端刚刚从Eclipse过渡到Android Studio前端也经历过jQuery到Vue/React的换代。但最明显的特征不是语言而是“自动化程度低”和“工具链沉重”。举个例子2022年前很多团队启动一个新项目开场不是初始化仓库而是先在本地把一套环境配置出来。Java开发者要手动配JDK、配Maven仓库改Eclipse的工作空间编码嵌入式开发者更苦装Keil MDK要选芯片包要办License要配置烧录器驱动。哪个环节出问题一上午就搭进去了。这种状态放到今天年轻人可能很难理解为什么不用容器一键拉起为什么不用插件帮我们自动补全配置原因也简单当时Kubernetes还在普及早期Docker虽然已经有了但很多公司的服务器环境根本不允许随便用容器。加上团队对自动化的接受度参差不齐大部分工作仍然靠“人肉”来完成。所以“古法”的核心特征可以归纳成四点第一环境配置高度依赖个人经验第二构建和部署链路漫长且易错第三知识沉淀靠文档和老带新第四代码评审、测试、发布这些环节都需要人工介入。这些特征谈不上先进但有一点无与伦比的价值——它逼着每个开发者把底层原理弄明白因为你没有办法靠工具糊弄过去。1.2 流程方案的选型逻辑瀑布、迭代与敏捷的混搭软件开发流程在2022年之前给人的感觉更像“混搭”。教科书上讲瀑布模型、迭代模型、敏捷开发但真实项目里很少有一种流程从头用到尾。我记得2017年参与一个车载固件配套工具的开发项目刚启动时需求方只给了一页纸的评估版需求大家第一反应是“先把需求文档写出来”。于是我们就用类似瀑布的做法先做总体设计画模块框图写接口定义再进入编码。这个做法在嵌入式相关项目里特别常见因为硬件联调一旦返工成本远超改几行软件代码前置的评审和确认就是省钱。而当项目推进到联调阶段需求开始频繁变化我们又自然过渡到两周一个小迭代每次迭代结束都拉上测试和硬件工程师一起评审。这个节奏其实就是敏捷的变体只是没有挂Scrum的牌子。这套打法现在的项目管理理论可能觉得“不够专业”但它背后有明确的逻辑需求确定性不高时可以用迭代拉短反馈周期需求相对明确的部分则保持瀑布式的文档和评审。2022年前的优秀开发者不会死守某个流程而是根据项目风险调整流程。这个经验放到今天依然有效因为无论Jira管理还是飞书项目协作工具只能承载流程不能替你做判断。很多人问“软件开发流程”到底是什么我的回答是它不是流程本身而是对变化和质量的应对策略。1.3 团队协作与知识沉淀没有Copilot靠的是人传人2022年前团队协作方式比现在要“重”很多。代码评审不流行在GitLab上点几个按钮常见做法是把diff贴到邮件里或者拉着椅子过来“结对走读”。分布式团队更多靠QQ群、微信群、邮件列表同步状态一份接口文档放到禅道或Confluence上更新不及时就是事故源头。知识沉淀在这个年代特别依赖两样东西一个是文档一个是口头传承。新接手一个模块第一件事是找到老同事请他把架构图和你讲一遍然后自己翻代码、查Wiki、看提交记录。遇到奇怪的问题第一反应是搜索搜不到再问群里的资深同事。Stack Overflow上同类型问题非常多很多答案质量到今天来看也不算过时。这个过程效率说实话挺低的但它培养了“自己找答案”的能力。我觉得这是古法时代留给开发者最宝贵的财富遇到问题先剥丝抽茧而不是直接让AI给一个不一定正确的答案。那段时期的文档质量参差不齐有写得很详细的设计文档也有只剩一个标题的空Wiki。但有意思的是真正有价值的文档通常不是“按流程写出来”的那种而是工程师在排掉一个难缠bug后主动补的排查记录。2022年前很多团队的经验库就是这样靠自觉长出来的没有AI帮忙归纳也没有自动知识库每一篇都是血泪换来的。2. 古法开发的核心实操环境搭建、编码调试与工程管理2.1 一天从配环境开始三件套与那些隐藏的坑古法开发的第一道门槛是环境准备。我拿Java后端开发举个例子那个年代入职第一天大概率是配环境三件套JDK、Maven、开发IDE。配JDK有讲究不能光双击安装包点下一步。系统变量里要手动新建JAVA_HOME值指向JDK安装目录再修改PATH变量加入%JAVA_HOME%\bin有些老教程还会让你配CLASSPATH。这些操作现在看起来多余但在当年IDE和构建工具都是凭环境变量去找JDK的漏配一个后面编都编不过。我还遇到过因为装了多个JDK版本导致编译报错的情况排查了半天最后发现是PATH里旧版本的路径排在了前面。这类问题没有捷径只能命令行敲java -version和javac -version逐个查。Maven也一样本地仓库默认在用户目录下的.m2文件夹第一次构建要从中央仓库拉依赖网络慢的话能卡到怀疑人生。古法开发者手里基本都有一个settings.xml模板里面配好淘宝镜像或私服地址这几乎是入职第一周就学会的“保命技能”。再往后是IDEEclipse那年头导入Maven项目比较折腾需要m2e插件有些老项目甚至要手动把依赖加进Build Path。IDEA逐渐普及后这类问题变少了但IDEA那会儿也有自己的脾气比如中文注释乱码、编码设置不统一一不小心又得调Compiler的encoding选项。这些实操在今天看来都是基础中的基础但它们解释了为什么那时候一个项目从git clone到本地跑起来能花半天时间。我也建议现在学Spring Boot或嵌入式开发的朋友即使有云开发环境也别跳过本地手动配一次环境的过程因为配置里暴露的问题能帮你理解工具链的依赖关系。2.2 版本控制迁移实记从SVN到Git的折腾版本控制是古法软件开发里最有代表性的一章。早期的公司项目用SVN居多服务器上开个仓库开发者checkout出来工作每改完一个功能commit一次。集中式版本控制的好处是权限好管理目录结构清晰tags和branches也能做到。但分支操作很别扭merge经常冲突而且有些团队的SVN仓库长期没人清理trunk和branch之间的关系乱到只有管理员清楚。Git进入国内企业主流的节点大概在2015年前后GitHub上开源项目越来越多很多开发者在个人项目里用Git已经很熟练然后推动公司从SVN迁移。我们团队2018年迁移过一次坑非常具体第一老SVN仓库里的历史提交要不要保留保留的话要写脚本做作者映射不然显示的全是svn用户名第二团队成员对新分支模型的认知不统一还用SVN的思路操作Git比如直接在master上提交代码或者“怕创建分支造成麻烦”。第三权限控制从目录级别变成仓库级别很多原来靠目录隔离的“伪多项目”仓库被迫拆成多个Git仓库。迁移之后分支模型成了新的争论点。有人推崇Git Flow功能分支、开发分支、发布分支、hotfix分支一套搞得非常齐全有人主张简单流只有master和feature分支。最后实际执行往往根据团队情况妥协。我的看法是分支模型没有绝对优劣关键是发布策略。如果团队需要同时维护多个线上版本Git Flow天然合适如果只维护一条主线且持续部署简单分支模型更顺手。这也是2022年前软件工程领域少有的、被争论但又确实有价值的话题。2.3 编码调试三板斧日志、断点和边界试探古法开发中的调试和今天用AI辅助定位Bug差别很大靠的是经验和系统方法。我总结是“三板斧”日志、断点、二分定位。先说日志。Java后端项目普遍用log4j或logback线上问题基本靠日志定位。这里有门学问日志级别怎么定普通业务留INFO关键流程和异常留WARN和ERRORDEBUG信息一般只在开发环境开。很多线上事故最后复盘发现是日志打得太少只有一行“系统异常”根本没有上下文。所以古法开发者写日志时习惯把关键参数一起打出来比如“用户ID123下单失败库存不足”这条日志的价值远高于“下单失败”。再说断点。IDE里的断点调试大家都会但古法开发者会用的高级技巧包括条件断点(比如在循环里当i500时停下来、方法断点、异常断点。在排查多线程问题时在看板上同时挂多个线程的调用栈能很快找到死锁位置。嵌入式开发则略有不同很多时候断点打在中断服务函数里会造成系统崩溃这时候只能靠串口打印或者观察寄存器值。最后是二分定位。当代码逻辑复杂、Bug难以通过阅读发现时把可疑代码区域内的一条路径分成两半先用日志或者断点确定Bug在前半段还是后半段再逐层缩小范围。这个方法跟“git bisect”是一套思想Git提供的二分查找提交功能就是自动帮你在提交历史里定位引入问题的那个commit。2022年前没有现在那么多可观测性工具这套手工排查方法就成了每个开发者必须掌握的“吃饭家伙”。3. 嵌入式与硬件场景下的开发现场3.1 交叉编译与工具链为什么Keil还在GCC也在嵌入式软件开发在2022年前就是一门“手艺活”环境门槛比纯软件高不少。拿ARM Cortex-M系列单片机来说主流的开发方式有两种一是Keil MDK二是IAR EWARM开源圈子则普遍用arm-none-eabi-gcc工具链加Makefile。很多初学者问该学哪个我的答案是工具只是入口重点是理解交叉编译。交叉编译的意思是“在一种处理器架构的电脑上编译出另一种处理器架构能运行的程序”。PC上是x86单片机是ARM所以编译器必须针对ARM指令集生成代码。这套理念对应到实际工程就是你要配置好编译器、链接器、启动文件和芯片头文件。Keil MDK把这些整合得比较好在界面里选一下芯片型号点一下下载就能烧录进去。但很多问题就出在“整合得好”上面开发者不清楚背后发生了什么遇到“Error: Flash Download failed”就懵了。相比之下Makefile加GCC的路线更透明。你能看到编译命令、链接选项、内存布局脚本(link script)里的ROM和RAM分配。2022年前很多嵌入式工程师面试题喜欢问gcc的编译过程问堆栈大小如何设置翻过来问的其实是工程构建的理解深度。我自己做固件项目时早期从Keil上手后来切到Makefile加arm-none-eabi-gcc花了一段时间适应但对链接器脚本的理解明显上了一个台阶。这个收益到今天也还在。3.2 烧录、调试与软硬件联调很灵异但真相往往是时序嵌入式开发真正痛苦的地方不在编译而在软硬件联调。一个功能在仿真器里跑得好好的烧到真机上一上电就死机这种“灵异事件”很常见。2022年前没有太多高级工具可用排查手段就那几样调试器、示波器、万用表、串口打印。调试器有JTAG和SWD两种常见接口。JTAG有四根线加复位线速度快管脚占用多SWD只要两根线节省IO适合空间受限的板子。用调试器打断点的时候有一个经典坑如果你把断点打在中断服务函数里而系统又一直触发该中断程序就会不停停在断点上看上去像死机。这时候要善用“禁用中断后单步”或者改成调试外设寄存器。更麻烦的是嵌入式程序里有一个独立于CPU的看门狗如果你在调试状态下停留时间过长狗就超时复位程序直接重启。很多新手第一次遇到以为代码跑飞了其实是调试器把狗饿死了。示波器和逻辑分析仪是排查硬件时序的重要工具。有一次我做I2C通信调试软件轮询寄存器检查通信是否完成从日志看一切正常但外设就是没反应。最后用示波器抓波形才发现SCL的频率远高于从设备支持的上限。这问题你在IDE里看一百遍代码也看不出来。古法时代的嵌入式工程师很多都是在示波器面前蹲了太多次才学会“软件问题看波形硬件问题看时序”。串口打印是最后一道保命手段。我记得很多老项目喜欢用重定向printf到UART目的就是方便看log。但要注意波特率匹配还有打印太多会拖慢实时性影响电机控制这类对时序敏感的应用。3.3 BMS这类嵌入式项目到底在学什么热词里有一个“BMS软件开发学习路线”BMS是电池管理系统的缩写在新能源行业里非常典型也是嵌入式方向里很有含金量的细分场景。一个BMS系统的软件通常要搞定这么几块电芯电压采集、温度采集、电流采集、SOC估算、均衡控制、过压欠压过流保护以及和整车控制器或充电机之间的CAN通信。学习路线可以这样规划第一步把C语言和数据结构吃透尤其是指针、数组、环形缓冲区这类基础第二步找一块STM32类的开发板跑GPIO、ADC、定时器、UART、CAN外设这是硬件抽象的具体认知第三步接触RTOS比如FreeRTOS理解任务调度、信号量、消息队列因为BMS里保护逻辑和通信逻辑需要不同优先级第四步研究通信协议CAN是最核心的要懂CAN帧结构、ID分配、DBC文件解析第五步了解功能安全和故障诊断看一些ISO 26262的基础概念。面试题方面嵌入式软件开发的常见考点非常稳定volatile关键字的作用、中断服务函数的注意事项、堆栈溢出怎么排查、static修饰符在不同位置的影响、指针和数组的区别、一个大小端转换的实现。这些问题在2022年前和2022年后几乎没有变化。因为它们考的不是知识量而是你有没有真正把C语言和单片机底层吃透。如果你正打算走嵌入式面试刷这些题比追逐新框架有用得多。4. 交付、发版与运维看不见的“最后十公里”4.1 从代码到发布测试、构建与手工部署的极限古法软件开发的最后一个环节是发版也是最容易翻车的环节。2022年前很多团队没有完善的CI/CD流水线Jenkins算比较超前的但也有大量项目仍保留“手动构建手动上传”的习惯。典型的发布流程长这样开发完成后测试人员先在测试环境验证测试环境通常是内网一台服务器由运维或开发手动把war包或jar包扔到Tomcat目录下确认没问题后再由开发打包生产版本上传到生产服务器停服、备份、替换、重启整个过程中所有人都在群里同步状态。这里最容易出问题的就是配置差异。开发环境连的开发库生产环境连接的是生产库如果配置项没分离或者application.properties里写死了内网IP上线后必然连接超时。古法团队的解决办法是维护多套配置文件打包时用不同profile切看似笨拙但比没有强得多。前端项目同样不轻松那时候构建工具从Grunt到Gulp再到webpack升级频繁。webpack的配置动辄上百行loader和plugin版本相互不兼容改一个版本要连带升好几个依赖。所以前端同学发版前一般要本地先npm run build确认能出dist目录再往测试服务器拖。2018年前后很多团队开始引入GitLab CI把构建和部署脚本化算是一次比较大的进步。4.2 机考与课程设计背后通用的能力模型“软件开发流程”“App软件开发课程设计”“通用软件开发机考”这些热词集中指向一个东西工程化基础能力。2022年前后大厂校园招聘的通用开发岗普遍有机考环节考的题目和框架无关主要是数据结构、算法、语言特性和简单的系统设计。很多人吐槽“工作又用不到算法”但从企业角度机考考察的其实是候选人在规定时间内把复杂问题拆解、实现并验证的能力。这个能力在任何软件开发流程里都是核心。课程设计也类似。一个App软件开发课程设计标准的做法是需求分析→原型设计→数据库设计→编码→测试→答辩。如果认真走完这套流程你收获的不只是“会写Java/Kotlin代码”而是了解了软件从想法到交付的整体链路。我见过很多应届生简历里写着熟悉软件开发流程但问他“需求变更了怎么办”、“数据库表设计要不要反范式”支支吾吾答不上来。这是因为他们跳过了分析设计这一步直接上来写页面。古法年代没那么多捷径反而让人把流程里每一环都过了一遍功底自然扎实。4.3 线上事故与回滚预案手忙脚乱后的教训每个古法开发者都经历过线上事故我也不例外。印象最深的一次上线一个新版本后数据库连接池瞬间被打满接口响应从50毫秒飙到10秒紧接着一堆超时重试把数据库直接压垮。当时第一反应是“赶紧回滚”但因为我们没有自动化回滚脚本只有手工备份的旧包愣是多花了10分钟才恢复。那10分钟里在线用户全部受影响。这次事故后来复盘总结了几条经验第一生产环境必须保留上一个稳定版本的包最好保留2个以上第二数据库结构的变更一定要考虑回滚脚本第三发版最好选择低峰期并安排至少两个人协同操作第四一旦出现异常先回滚再排查不要试图在生产环境调试。这些在今天听起来是常识但在2022年前很多团队连“回滚预案”这个名词都没有。现在再看那些重视发布规范、有回滚机制的老团队反而是最靠谱的。5. 常见问题与排查技巧实录5.1 编译链接问题的速查表古法开发里编译和链接报错几乎每天都会碰到。有些错误翻来覆去就那几类我把最高频的整理成了下面这张表方便参照排查。报错倾向常见原因排查思路找不到符号/包依赖缺失、类路径未配置检查Maven/Gradle依赖是否完整IDEA里的Project Structure是不是没把模块导入编译乱码/编码错误文件编码与编译器不一致统一项目为UTF-8检查IDE编码设置、Maven编译插件encoding参数内存溢出构建堆内存太小调整MAVEN_OPTS或Gradle JVM参数-Xmx1024m起步链接失败undefined reference库没有链接或函数声明与实现不一致嵌入式项目里检查头文件路径和link库顺序注意静态库依赖顺序也会导致找不到符号代码自动退后/中文注释乱码IDE的encoding和项目实际编码不匹配把IDE的file encoding全改成UTF-8重新reload工程Flash Download failed芯片型号选错、烧录器驱动异常、Flash算法不对核对Keil/IAR里的Device选项重新选择FLM文件检查调试器连接这张表看起来简单但每一条背后都有真实的加班故事。尤其是编码问题2022年前后出现过多少次因为GBK和UTF-8不一致导致的乱码数不清。我的体会是遇到编译问题不要急着改代码先看环境底层配置。5.2 运行时问题的定位流程运行时问题比编译问题难因为它不报错或只报一个笼统的错误。我惯用的定位流程是这样的第一步看日志找异常栈。日志级别不够就临时加日志重新发布如果怕影响性能只对关键方法加INFO。第二步如果是Java应用用top看进程CPU和内存占用再用jstack抓线程快照重点看有没有大量线程处于BLOCKED或WAITING状态。典型死锁场景就是这样暴露的。第三步如果是数据库相关问题慢查询日志和show processlist是直接证据很多连接池耗尽就是代码里忘关连接导致。第四步确认是偶发还是必现偶发问题要尽量保留现场比如把堆栈和当时的请求参数记录下来。嵌入式场景的运行时问题又是另一套思路。程序复位了先查电压和看门狗再查中断优先级配置还要留意硬件上拉电阻是否影响电平。这类问题没有固定套路的排查工具更多靠经验和耐心的逐项排除。我自己遇到过一次固件偶发重启排查了两周最后发现是电源模块在负载突变时产生了一个毛刺把复位引脚拉低了。软件上一行代码都没改硬件改了个电容位置问题消失。这类经历会让你对“软硬件不分家”这句话有深刻理解。5.3 团队协作问题清单2022年前协作问题很多时候比技术问题更消耗人。我遇到的典型问题有这些多人同时改同一个文件SVN和Git里的Merge冲突此起彼伏接口文档更新不及时前端按照老文档联调后端已经改了字段名测试环境不一致开发本地是好的测试环境必现崩溃代码评审流于形式没人看细节导致低级问题直接流到生产。解决办法说穿了并不复杂第一代码尽可能拆小合并批量提交、跨多个模块的大改动是冲突的温床第二接口文档必须进版本库和代码一起更新而不是放在在线文档里随手改第三测试环境无限接近生产环境尤其数据库版本、中间件版本、配置文件必须保持一致第四评审人要对变更逻辑负责而不是只点个“通过”。这些经验从2015年管用放到现在同样管用工具变了人的问题不会凭空消失。6. 从古法到智能时代经验沉淀与迁移建议6.1 2022年前后AI从“被开发对象”变成“开发助手”2022年前“AI软件开发”这个词的含义和今天完全不同。那时候说AI软件开发指的是“开发一个AI系统”要么做机器学习模型训练要么搭数据标注平台要么部署推理服务。开发者的工作重点是处理数据、调参、写Python脚本、优化推理性能。到了2022年底之后AI大模型开始以辅助编码工具的身份进入日常工作自动补全、自动生成测试用例、解释他人的代码这时候的“AI软件开发”越来越多地指“用AI辅助做软件开发”。这个转变的影响很深远。古法时代开发者写代码必须逐字推敲、自己设计边界条件这种“慢工出细活”的训练让基本功很扎实。AI辅助时代产出代码的速度变快了但审查代码的能力、理解业务需求的能力、判断设计好坏的能力反而更加重要。我见过不少人用AI生成一段代码跑通了就觉得完事却说不清为什么这么写更谈不上优化。结合我的经验AI工具最适合用来“提效”不适合用来“替思”。6.2 古法经验在今天还值不值钱有年轻人问2022年前的东西是不是都过时了我的观点是工具会过时方法论不会。比如你理解了手动配JDK和Maven的底层逻辑云IDE的容器启动在你眼里就不是黑盒你经历了从SVN到Git的迁移面对新的版本控制工具就能更快掌握你亲手用控制台定位过一次线上故障再看可观测性平台的指标和链路理解完全不一样。热词里那些“嵌入式软件开发面试题”“通用软件开发机考”考来考去其实还停留在古法时代沉淀下来的核心知识。C语言基础、数据结构、操作系统、网络协议、工程化思维这些东西都不会因为AI工具的出现而失效。它们就像武术里的基本功练的时候枯燥用的时候才知道珍贵。6.3 给后来者的个人体会我做了这么多年软件开发最深的体会是别嫌“古法”烦也别把“新工具”神化。技术迭代很快但你解决问题的思路、排查问题的步骤、把事情搞清楚的习惯才是真正能带走的能力。如果你现在刚开始学开发我的建议很简单——找一个略微过时但仍能跑的小项目手动做一遍不依赖AI工具从配环境到发布完整走一遍流程。这个过程可能会让你觉得绕远路但走完以后你会知道自己学到的东西比看十遍教程都多。最后再分享一个小技巧不管用什么工具、什么框架养成写工程笔记的习惯。把每年遇到的典型问题、排查过程、最终结论记录下来攒三年再回头翻你会发现这些笔记才是你最值钱的技术资产。