初学摸索：边读书边落地，踩满过度设计的坑

刚工作不久偶然接触代码生成器“让程序自动产出代码”这个念头一下抓住了我一晃深耕便是十几年。那时候我对面向对象、架构分层只有模糊认知最好的学习方式就是一边看书一边动手实操。捧着C#相关书籍学到新思路立刻写进生成器验证遇到卡壳的难题再翻书寻找解法。常常出门走路还在梳理类结构、映射逻辑好几次走神错过路口。一心想把书本理论落地却接连踩了两个典型设计误区为了盲目追求抽象给所有业务类强行抽取公共父类即便完全没有复用需求也要拉出一长串继承链条。看着结构规范实际维护牵一发而动全身修改成本居高不下。后来接触特性注解急于尝试新语法直接把数据表映射、数据校验规则全部塞进业务实体。业务代码和数据库规则死死绑定后续调整字段、修改校验逻辑整份实体都要大面积改动。早期我的眼里只有“自动生成CRUD”这个表层目标只顾堆砌功能完全忽略长期可维护性也为后来大规模重构埋下隐患。那段时间我啃透了底层元数据相关内容拆解开源项目源码其中对象映射、多数据库适配的思路悄悄为后续自研数据层框架打下基础。二、数次推倒重构在否定旧方案中慢慢成长十几年里没有外部需求倒逼优化所有迭代升级都来自主动反思旧代码、一次次推翻重来。这个过程本质是不断打破自己过去局限的认知。超越别人只是外在能力敢于直面自身设计里的漏洞才是真正的自我提升。整个开发周期一直循环着一套完整路径搭建一套可用方案使用中暴露缺陷后彻底推翻融合新旧经验重新打磨完善。每一轮重构过后看待技术设计的眼光都会通透一层。简化冗余抽象砍掉无效继承我删掉大量多余顶层父类缩短臃肿的继承链路。调整完成后代码总量变少能覆盖的功能反而更广。这件事让我认清一个道理抽象是为了解决实际业务问题单纯为了炫技堆砌复杂设计只会留下难以清理的技术债务。拆分实体与元信息理清代码职责边界不再把库表定义、校验规则绑定在业务实体上单独拆分载体存放相关配置。代码职责划分清晰后续迭代调整不用再大面积改动核心业务代码。剥离硬编码SQL自研轻量化数据访问层一次和同事闲聊一句话点醒了我不该把SQL语句直接嵌在业务逻辑里。我推翻原先硬写SQL的模式将所有语句统一收纳至XML文件配套缓存更新机制依靠分层思路兼容多种数据库。早年吃透的元数据、开源项目里的对象映射思路全都在这次重构落地。2006到2007年我搭出一套轻量化数据层框架实现数据表行与实体自动转换、统一处理空值彻底告别粗糙的数据读写写法。放弃字符串拼接改用模板简化生成逻辑项目最开始所有生成代码全靠硬拼接字符串实现冗余繁杂稍有改动就容易出错。我先做了简易标记模板后续引入成熟模板语法大幅简化生成器内部逻辑。只是醒悟得太晚前期浪费了大量时间处理拼接逻辑也算一次深刻的自我审视。从重构翻车里摸索稳妥迭代方式早年重构总急于求成一次性改动大量代码那时候也没有规范的版本管理工具。一旦逻辑出错只能退回几天前本地备份数日的心血付诸东流这份遗憾我记到现在。踩过这次大坑后我定下自己的重构准则小步修改、分段验证绝不一次性大刀阔斧改动全量代码。唯独可惜的是当时没能顺势用上单元测试每次大重构都要人工反复核对校验耗费不少精力多年之后才补上这套质量保障方式。三、补齐全链路配套形成一体化开发工具持续重构优化的同时我慢慢补齐整套配套组件减少项目里大量重复开发工作先封装绑定后台逻辑的页面控件后续迭代轻量化纯前端组件灵活性、可维护性大幅提升。这套组件直接复用在视频监控网页端省去大量重复页面开发。写了一套前端自动校验工具JS遍历页面控件读取属性自动判断非空、长度、数值范围违规实时弹出提示减轻后端校验压力。配套Excel导入导出能力根据数据表自动生成模板兼顾格式校验与主外键约束杜绝脏数据。原本需要数天的业务配置工作依靠批量导入导出十几分钟就能完成在视频监控项目里发挥了很大作用。工具界面也从单一窗口迭代成多面板可视化布局左侧展示数据库表结构中间配置代码生成规则生成能力从单一ASP.NET拓展到Java、C、多框架页面代码适配不同技术栈。四、架构思路突破把整块框架拆成可自由组合的独立库迭代多年后我发现完整大一统框架弊端很多模块紧紧耦合在一起单独调试、拆分复用都十分困难。于是我做了一次关键调整把整套框架拆解成多个能够独立运行的组件库按需搭配组合使用。拆分后形成七类独立库数据访问库、元数据映射库、SQL缓存库、前端校验库、页面控件库、Excel工具库、通用基础库。这套拆分思路刚好和编程领域公认的两条实践准则契合减少重复代码、模块低耦合。拆分后的组件职责单一既能单独测试也能跨项目复用。吃透组件、库、框架三者的组合逻辑也让我后来接触大型通信框架时上手格外顺畅。很多书本只是把我们实操踩出来的经验做系统梳理真正深刻的认知永远只能来自动手写代码的过程。五、思路跨场景复用一套底层逻辑适配各类业务打磨代码生成器沉淀下来的两套核心思路不受编程语言、业务场景限制十几年间被我复用在不同项目里一是自动化代码生成思路。我用Python写过数据库代码生成工具、用Java自研配套框架、写过C#表格辅助类能通过配置生成业务代码也能从代码头文件反向导出项目文档。二十多接口的标准化项目里我也曾构思配置自动生成出入参代码只是当时项目时机不成熟最终没有落地。二是分层解耦的架构思路。这套逻辑用在智能电视系统、海外流媒体平台搭建统一第三方组件管理框架解决多模块兼容问题。各类工具形态千差万别但实操试错、复盘总结、分层拆分、迭代重构的底层逻辑始终不变。很多人觉得不要执着钻研单一工具但我这些年的体会完全不同打磨一件工具本身是很好的成长路径不必刻意回避深耕某一类技术。真正珍贵的从来不是工具本身而是打磨过程里悟出来的底层原则。工具会被新技术替代但沉淀的架构、重构、自动化思路能无缝迁移到后端、前端、嵌入式各类开发工作中。六、十余年复盘一路收获也藏两处遗憾整整十几年独自打磨这套工具回头看有两处难以弥补的缺憾。全程只有自己一人摸索缺少团队同伴交流碰撞独自试错的成长速度有限。如果当年能有人一起探讨架构、交换想法整体技术认知一定会提升更快这也是我把文章命名“一个人的江湖”的原因。另外一处遗憾当年重构踩坑吃过亏却没能及时落地单元测试长期依靠人工校验保障代码稳定迭代效率受限标准化的质量校验手段是时隔多年才补齐的。当然这段经历带给我的收获远大于遗憾。第一技术成长本质是不断修正自己。十几年没有外部竞争所有进步都来自主动推翻不成熟的设计。敢于正视自身短板、主动重构优化远比不停追逐各类新技术更重要。我们最大的对手从来都是思维存在局限的过去的自己。第二动手与复盘循环往复才能持续精进。各类架构、设计思路都不是死记硬背得来的是一次次解决问题的过程里自然生长出来的。先动手实践沉淀出经验规律再用规律指导新项目循环往复才能层层进阶。第三跳出工具本身沉淀通用解决思路。如今各类AI代码工具普及当年亲手打磨的生成器早已落后现在我只拿它当作简易数据库辅助工具。但我从不觉得这十年投入白费深耕一件工具的价值不在于工具能留存多久而在于从中提炼出不受场景束缚的通用解决办法。尾声