006、软件工程与系统开发方法论

张开发
• 2026/4/6 11:19:06 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

006、软件工程与系统开发方法论
006、软件工程与系统开发方法论：从一次深夜调试说起凌晨两点，示波器上的波形还在跳，我盯着屏幕里那个偶现的时序毛刺，已经三个小时没进展。硬件同事咬定是软件调度问题，我翻着四个月前写的任务调度代码，突然意识到：当时为了赶进度，没写状态机文档，现在连自己都看不懂那段条件判断的逻辑。那一刻我明白了——方法论不是教科书里的摆设，是救命的绳子。调试坑里的反思那个毛刺最后查出来是中断服务程序里一个全局变量没保护，两个任务同时读写导致的。问题很简单，但暴露的东西很深刻：我们团队用了“敏捷”，每天站会都报进度，但没人提技术债务；我们画了架构图，但详细设计文档停留在PPT第二页；我们做了代码评审，但大家都忙着赶下一个迭代。这让我想起早年做单片机开发的日子，那时候没那么多方法论，就是一份需求说明书加一堆.c文件。项目小的时候还行，等到系统复杂了，问题就来了——改一个串口驱动，能触发三个模块的异常。没有方法论的项目，就像没画图纸盖房子，墙歪了都不知道是哪根梁出了问题。那些真正用起来的方法瀑布模型现在经常被嘲笑“太老旧”，但我接手维护过一个二十年前的电力监控系统，就是瀑布模型开发的。文档齐全到什么程度？连当年为什么选某个滤波算法的会议记录都在。虽然代码风格古老，但新人两周就能摸清脉络。反观某些“敏捷”项目，三个月前的决策背景全靠口头传话。敏捷不是不写文档的借口。我在车载系统项目里实践过改良的敏捷：每个迭代必须产出可测试的模块，文档可以少，但接口定义、状态迁移图、错误处理流程这三样必须白纸黑字。特别是嵌入式领域，硬件依赖和时序约束文档不写清楚，后期集成就是灾难。看板在嵌入式团队特别好用。我们把任务分成“待设计”“编码中”“硬件联调”“系统测试”几列，特别加了一列“等硬件”。硬件依赖强的开发，很多时间是在等板子、等样机，看板让等待时间可视化，避免管理层误以为程序员在摸鱼。代码里的方法论说说实际编码。下面这段是那个出问题的中断服务程序最初版本：// 中断服务函数 - 最初的问题版本voidUSART1_IRQHandler(void){if(USART_GetITStatus

更多文章