系列说明这是《从一段能跑但脆弱的 WinForms 代码说起》的终篇。前四篇讲了线程、进度模型、重构分层、数据库操作都是术。这一篇讲道技术之外这次重构带来的认知升级是什么工程师的 level 差距到底在哪所有代码和业务均已脱敏。文章目录一、 先讲一个真实的小故事二、 从能跑到可维护的鸿沟三、 工程师 level 的三个分水岭Level 1能实现功能会写代码Level 2能做出正确决策会选方案Level 3能沉淀方法论会抽象四、 什么时候信任框架什么时候自己兜底五、 决策点上的为什么选它而不是另一个六、 经验复利这次的结构能套用到哪些场景七、 给 3 年前自己的三条建议建议 1不要等到必须重构才动手建议 2命名比实现更重要建议 3每次解决一个问题都问这一类问题怎么解八、 终篇小结系列回顾一、 先讲一个真实的小故事重构进行到一半我发现原代码的备份逻辑是这样的publicstaticvoidBackUpDataBase(){// ...for(inti0;itb.Rows.Count;i){ExcuteSQL(rename table mDbName.tbName to newDbName.tbName,);}// ...}方法名叫BackUpDataBase备份数据库但实际执行的是rename table——把原库的表搬到备份库。执行完之后新库里有了数据 ✅原库里空了❌这不是备份这是迁移。如果有人以为这是备份功能某天点了一下数据就没了。而且这个方法名还会让接手的人根本不会怀疑它有问题。这一个 bug 教会我的比前面四篇加起来都多。它让我意识到写代码这件事真正难的不是让它能跑而是让它在别人手里、在半年后、在意外情况下依然安全。二、 从能跑到可维护的鸿沟很多工作几年的人会有一个困惑“我写的代码明明能跑功能都对为什么老被说’代码质量不行’”因为能跑和可维护之间有一条看不见的鸿沟。用这次重构的代码举例维度能跑的代码可维护的代码命名button1、ExcuteSQLbtnFixFlow、ExecuteSql结构全塞在Form1三层分离线程同步卡死或DoEventsTask.Runawait进度static progressMessage 定时器IProgressT异常catch { return null; }分层处理语义BackUpDataBase做 renameBackupDatabase做复制连接每次现算连接字符串封装进DbHelper能跑关注的是现在、这台机器、这次操作、成功路径。可维护关注的是半年后、别人手里、异常情况、失败路径。而工程师的 level 差距主要就体现在你关注的是前者还是后者。三、 工程师 level 的三个分水岭结合这次重构我把工程师的成长分成三个 levelLevel 1能实现功能会写代码特征拿到需求能写出能跑的代码。遇到问题会搜、会问、会试。关注点是怎么把它做出来。典型表现// 需求点击按钮备份数据库privatevoidbutton1_Click(objectsender,EventArgse){BackUpDataBase();// 能跑但 UI 卡死}这个 level 的人能完成任务但代码是一次性的换个人接手、改个需求、出个异常就崩。大多数工作 1~3 年的人在这个 level。Level 2能做出正确决策会选方案特征同一个问题知道有几种解法。能说出每种解法的代价而不只是哪个好。关注点是为什么选它而不是另一个。典型表现遇到进度刷新问题Level 2 的人会这样思考方案优点代价适用场景Invoke直接可控样板代码多业务被污染更新点少定时器 全局变量易上手全局状态、延迟、结束消息不可靠内部小工具DoEvents写法简单重入风险临时测试IProgressT线程切换自动化业务干净需改方法签名推荐Level 2 的人不会说XXX 是最好的而是说在这个场景下我选 XXX因为……。大多数工作 3~8 年的人在这个 level。你这次重构已经站到了这里。Level 3能沉淀方法论会抽象特征解决一个问题后能抽象出解决一类问题的方法。能把自己的经验传递给别人。关注点是怎么让团队、让未来的自己少踩坑。典型表现解决完这个项目的进度问题后Level 3 的人会写一份《WinForms 进度刷新模型选型指南》或者抽象出重构七步法步骤做法1. 先跑通确认现有行为2. 识别边界UI / 数据 / 业务3. 分离关注点拆类4. 统一线程模型Task.Runawait5. 命名反映语义改命名6. 异常分层处理底层抛、中层记、上层提示7. 小步验证每改一层编译一次Level 3 的人输出的不只是代码还有认知。工作 8 年以上的人如果还在 Level 2会很危险——因为你的竞争力只是经验多而经验是可以被时间追平的。真正拉开差距的是能不能把经验抽象成方法。四、 什么时候信任框架什么时候自己兜底这次重构里有一个贯穿始终的判断什么时候信任框架什么时候自己动手。场景选择理由连接管理信任连接池自己维护长连接会引入超时、线程安全、状态污染线程切换信任ProgressT手写Invoke容易出错异步调度信任await手写ContinueWith是回调地狱异常处理自己兜底框架不知道你的业务语义备份语义自己判断框架不知道备份和迁移的区别命名自己把关框架不会帮你起名字分层自己设计框架不知道你的业务边界规律机制性的东西连接复用、线程调度、异步调度→信任框架。框架的通用实现比你自己写更靠谱。语义性的东西业务含义、命名、分层、异常策略→自己兜底。框架不懂你的业务。“信任框架不是偷懒而是不重复造轮子还造得更差”。“自己兜底不是不信任框架而是框架不知道你要什么”。这个判断力是 Level 2 和 Level 3 的分界线之一。五、 决策点上的为什么选它而不是另一个回顾这次重构我做了这些决策决策点我的选择为什么不是另一个进度刷新IProgressT定时器有全局状态、延迟、结束消息不可靠Invoke污染业务代码备份语义CREATE INSERTrename是迁移会导致原库丢失连接管理短连接 连接池长连接会超时、线程不安全代码组织三层分离全塞在Form1改一处动全身错误处理抛异常 上层提示return null无法区分空结果和出错控件命名btnFixFlow等button1半年后看不懂备份进度带计数{index}/{total}不带计数用户不知道还有多久每一处改动背后都有理由。这就是工程判断力的体现——不是我知道怎么做而是我知道为什么这么做也知道为什么不那么做。如果你能在技术评审时对每个决策点说出我选 A因为 B不选 C 是因为 D你的 level 就藏不住了。六、 经验复利这次的结构能套用到哪些场景这次重构的成果不是改完了这个项目而是得到了一套可以复用的结构。以后遇到类似的场景几乎可以原样套场景可直接复用WinForms 里做 Excel 导出Task.RunawaitIProgressTWinForms 里做批量导入同上WinForms 里做上传/下载同上WinForms 里做长查询同上WinForms 里做日志分析同上任何耗时 进度的 WinForms 场景同上数据库操作的结构也通用场景可直接复用换数据库MySQL → SQL Server只改DbHelper改备份策略全量 → 增量只改BackupService加新数据操作在MainForm写 3 行走DbHelper写单元测试传假IProgress进BackupService这就是经验的复利一次重构的投入会在未来 N 个项目里产生回报。七、 给 3 年前自己的三条建议如果能让 3 年前的自己看到这次重构我会给三条建议建议 1不要等到必须重构才动手能跑就行是一个陷阱。代码不是一次性的。今天写的button1半年后就是自己的噩梦。每次写新功能时顺手把能跑改成可维护比事后集中重构更省力。建议 2命名比实现更重要命名是写给未来自己的文档。BackUpDataBase做 rename 这件事如果方法名叫MigrateDatabase一眼就能看出问题。命名对了很多 bug 在写的时候就能避免。建议 3每次解决一个问题都问这一类问题怎么解不要满足于这次搞定了。这次解决了进度刷新下次遇到批量导入还是同样的问题。把每次解决的具体问题抽象成一类问题的解法才是真正的成长。八、 终篇小结层次关注点典型问题Level 1 能实现怎么把它做出来“这段代码能跑吗”Level 2 能决策为什么选它“为什么选 A 不选 B”Level 3 能抽象怎么让一类问题都好解“下次遇到类似问题怎么办”一句话总结工作 8 年真正的核心竞争力不是会写多少 API而是在每个决策点上能说出为什么选它而不是另一个。这次重构练的不是语法是判断力——什么时候信任框架什么时候自己兜底什么时候该抛异常什么时候该复制而不是迁移。这些东西不会写在任何教程里只能从改自己的旧代码里长出来。系列回顾五篇走完从技术到认知篇目主题关键词第一篇线程 UI消息循环、await、SynchronizationContext第二篇进度刷新模型Invoke、IProgressT、定时器、DoEvents第三篇重构分层、职责分离、重构七步法第四篇数据库操作连接池、短连接、参数化查询、异常分层第五篇工程判断力Level 分水岭、技术决策、经验复利前四篇解决怎么做第五篇解决怎么想。如果这个系列对你有帮助欢迎转发给身边正在被祖传代码困扰的人。每一个 Level 2 的工程师都是从 Level 1 的代码里长出来的。系列完。
【WinForm 代码反脆弱系列】05 工程判断力 —— 这次重构教会我什么
系列说明这是《从一段能跑但脆弱的 WinForms 代码说起》的终篇。前四篇讲了线程、进度模型、重构分层、数据库操作都是术。这一篇讲道技术之外这次重构带来的认知升级是什么工程师的 level 差距到底在哪所有代码和业务均已脱敏。文章目录一、 先讲一个真实的小故事二、 从能跑到可维护的鸿沟三、 工程师 level 的三个分水岭Level 1能实现功能会写代码Level 2能做出正确决策会选方案Level 3能沉淀方法论会抽象四、 什么时候信任框架什么时候自己兜底五、 决策点上的为什么选它而不是另一个六、 经验复利这次的结构能套用到哪些场景七、 给 3 年前自己的三条建议建议 1不要等到必须重构才动手建议 2命名比实现更重要建议 3每次解决一个问题都问这一类问题怎么解八、 终篇小结系列回顾一、 先讲一个真实的小故事重构进行到一半我发现原代码的备份逻辑是这样的publicstaticvoidBackUpDataBase(){// ...for(inti0;itb.Rows.Count;i){ExcuteSQL(rename table mDbName.tbName to newDbName.tbName,);}// ...}方法名叫BackUpDataBase备份数据库但实际执行的是rename table——把原库的表搬到备份库。执行完之后新库里有了数据 ✅原库里空了❌这不是备份这是迁移。如果有人以为这是备份功能某天点了一下数据就没了。而且这个方法名还会让接手的人根本不会怀疑它有问题。这一个 bug 教会我的比前面四篇加起来都多。它让我意识到写代码这件事真正难的不是让它能跑而是让它在别人手里、在半年后、在意外情况下依然安全。二、 从能跑到可维护的鸿沟很多工作几年的人会有一个困惑“我写的代码明明能跑功能都对为什么老被说’代码质量不行’”因为能跑和可维护之间有一条看不见的鸿沟。用这次重构的代码举例维度能跑的代码可维护的代码命名button1、ExcuteSQLbtnFixFlow、ExecuteSql结构全塞在Form1三层分离线程同步卡死或DoEventsTask.Runawait进度static progressMessage 定时器IProgressT异常catch { return null; }分层处理语义BackUpDataBase做 renameBackupDatabase做复制连接每次现算连接字符串封装进DbHelper能跑关注的是现在、这台机器、这次操作、成功路径。可维护关注的是半年后、别人手里、异常情况、失败路径。而工程师的 level 差距主要就体现在你关注的是前者还是后者。三、 工程师 level 的三个分水岭结合这次重构我把工程师的成长分成三个 levelLevel 1能实现功能会写代码特征拿到需求能写出能跑的代码。遇到问题会搜、会问、会试。关注点是怎么把它做出来。典型表现// 需求点击按钮备份数据库privatevoidbutton1_Click(objectsender,EventArgse){BackUpDataBase();// 能跑但 UI 卡死}这个 level 的人能完成任务但代码是一次性的换个人接手、改个需求、出个异常就崩。大多数工作 1~3 年的人在这个 level。Level 2能做出正确决策会选方案特征同一个问题知道有几种解法。能说出每种解法的代价而不只是哪个好。关注点是为什么选它而不是另一个。典型表现遇到进度刷新问题Level 2 的人会这样思考方案优点代价适用场景Invoke直接可控样板代码多业务被污染更新点少定时器 全局变量易上手全局状态、延迟、结束消息不可靠内部小工具DoEvents写法简单重入风险临时测试IProgressT线程切换自动化业务干净需改方法签名推荐Level 2 的人不会说XXX 是最好的而是说在这个场景下我选 XXX因为……。大多数工作 3~8 年的人在这个 level。你这次重构已经站到了这里。Level 3能沉淀方法论会抽象特征解决一个问题后能抽象出解决一类问题的方法。能把自己的经验传递给别人。关注点是怎么让团队、让未来的自己少踩坑。典型表现解决完这个项目的进度问题后Level 3 的人会写一份《WinForms 进度刷新模型选型指南》或者抽象出重构七步法步骤做法1. 先跑通确认现有行为2. 识别边界UI / 数据 / 业务3. 分离关注点拆类4. 统一线程模型Task.Runawait5. 命名反映语义改命名6. 异常分层处理底层抛、中层记、上层提示7. 小步验证每改一层编译一次Level 3 的人输出的不只是代码还有认知。工作 8 年以上的人如果还在 Level 2会很危险——因为你的竞争力只是经验多而经验是可以被时间追平的。真正拉开差距的是能不能把经验抽象成方法。四、 什么时候信任框架什么时候自己兜底这次重构里有一个贯穿始终的判断什么时候信任框架什么时候自己动手。场景选择理由连接管理信任连接池自己维护长连接会引入超时、线程安全、状态污染线程切换信任ProgressT手写Invoke容易出错异步调度信任await手写ContinueWith是回调地狱异常处理自己兜底框架不知道你的业务语义备份语义自己判断框架不知道备份和迁移的区别命名自己把关框架不会帮你起名字分层自己设计框架不知道你的业务边界规律机制性的东西连接复用、线程调度、异步调度→信任框架。框架的通用实现比你自己写更靠谱。语义性的东西业务含义、命名、分层、异常策略→自己兜底。框架不懂你的业务。“信任框架不是偷懒而是不重复造轮子还造得更差”。“自己兜底不是不信任框架而是框架不知道你要什么”。这个判断力是 Level 2 和 Level 3 的分界线之一。五、 决策点上的为什么选它而不是另一个回顾这次重构我做了这些决策决策点我的选择为什么不是另一个进度刷新IProgressT定时器有全局状态、延迟、结束消息不可靠Invoke污染业务代码备份语义CREATE INSERTrename是迁移会导致原库丢失连接管理短连接 连接池长连接会超时、线程不安全代码组织三层分离全塞在Form1改一处动全身错误处理抛异常 上层提示return null无法区分空结果和出错控件命名btnFixFlow等button1半年后看不懂备份进度带计数{index}/{total}不带计数用户不知道还有多久每一处改动背后都有理由。这就是工程判断力的体现——不是我知道怎么做而是我知道为什么这么做也知道为什么不那么做。如果你能在技术评审时对每个决策点说出我选 A因为 B不选 C 是因为 D你的 level 就藏不住了。六、 经验复利这次的结构能套用到哪些场景这次重构的成果不是改完了这个项目而是得到了一套可以复用的结构。以后遇到类似的场景几乎可以原样套场景可直接复用WinForms 里做 Excel 导出Task.RunawaitIProgressTWinForms 里做批量导入同上WinForms 里做上传/下载同上WinForms 里做长查询同上WinForms 里做日志分析同上任何耗时 进度的 WinForms 场景同上数据库操作的结构也通用场景可直接复用换数据库MySQL → SQL Server只改DbHelper改备份策略全量 → 增量只改BackupService加新数据操作在MainForm写 3 行走DbHelper写单元测试传假IProgress进BackupService这就是经验的复利一次重构的投入会在未来 N 个项目里产生回报。七、 给 3 年前自己的三条建议如果能让 3 年前的自己看到这次重构我会给三条建议建议 1不要等到必须重构才动手能跑就行是一个陷阱。代码不是一次性的。今天写的button1半年后就是自己的噩梦。每次写新功能时顺手把能跑改成可维护比事后集中重构更省力。建议 2命名比实现更重要命名是写给未来自己的文档。BackUpDataBase做 rename 这件事如果方法名叫MigrateDatabase一眼就能看出问题。命名对了很多 bug 在写的时候就能避免。建议 3每次解决一个问题都问这一类问题怎么解不要满足于这次搞定了。这次解决了进度刷新下次遇到批量导入还是同样的问题。把每次解决的具体问题抽象成一类问题的解法才是真正的成长。八、 终篇小结层次关注点典型问题Level 1 能实现怎么把它做出来“这段代码能跑吗”Level 2 能决策为什么选它“为什么选 A 不选 B”Level 3 能抽象怎么让一类问题都好解“下次遇到类似问题怎么办”一句话总结工作 8 年真正的核心竞争力不是会写多少 API而是在每个决策点上能说出为什么选它而不是另一个。这次重构练的不是语法是判断力——什么时候信任框架什么时候自己兜底什么时候该抛异常什么时候该复制而不是迁移。这些东西不会写在任何教程里只能从改自己的旧代码里长出来。系列回顾五篇走完从技术到认知篇目主题关键词第一篇线程 UI消息循环、await、SynchronizationContext第二篇进度刷新模型Invoke、IProgressT、定时器、DoEvents第三篇重构分层、职责分离、重构七步法第四篇数据库操作连接池、短连接、参数化查询、异常分层第五篇工程判断力Level 分水岭、技术决策、经验复利前四篇解决怎么做第五篇解决怎么想。如果这个系列对你有帮助欢迎转发给身边正在被祖传代码困扰的人。每一个 Level 2 的工程师都是从 Level 1 的代码里长出来的。系列完。
