2025/8/20 16.24 将雨

本项目从6月末想法初见，到7月12号写下第一行代码，时至今日，已经度过两个月的时间。

其中70％的内容，由augment code完成，15%的内容由copilot完成，5%的内容由我自己完成，剩下的10%由cursor、claude code、豆包平分。

最开始，我把想法告诉了豆包，让它给我生成了《DevEnv 智能开发环境部署工具：从策划到部署》，并丢给刚刚相识的augment code，由此迈出了DevEnv的第一步。

这是我在开发过程中汲取的教训

一、前期规划与文档建设的重要性

• 教训1：缺乏详尽的架构与设计文档，导致后期无序迭代
  日志中多次提到“从一开始就没有规范的架构文档和设计文档”，导致功能“一点一点加、一点一点改”，后期维护困难。
  👉 启示：项目启动前必须完成核心架构设计、功能边界定义和流程规范文档，避免“想到哪做到哪”。

• 教训2：未明确功能优先级，核心价值功能被忽视
  开发后期才发现“核心功能（脚本安装和环境配置）未完成”，却花费大量时间在次要功能（如模板收藏、头像审核）上，导致产品核心价值缺失。
  👉 启示：需通过“MVP（最小可行产品）”思路，优先实现核心功能，再迭代补充次要功能。

二、开发流程与规范的必要性

• 教训3：开发流程不规范，版本管理混乱
  存在“更新代码无日志、commit信息随意、无规范的版本控制”，甚至“数据库修改未同步到初始化脚本”，导致部署时需重复调试。
  👉 启示：必须建立规范的开发流程，包括提交日志规范、版本控制（如Git Flow）、数据库变更同步机制（如迁移脚本）。

• 教训4：多版本管理失控，增加维护成本
  最初设想“开发版基于开源版”，最终演变为“两套独立代码”，导致维护成本翻倍。
  👉 启示：多版本/分支设计需在初期明确依赖关系（如通过模块化、抽象层隔离差异），避免后期分裂。

三、工具与依赖的合理使用

• 教训5：过度依赖Agent（AI工具），导致自身能力停滞
  日志提到“agent编码能力远超自己，导致懒惰和技术止步不前”。虽然工具提升效率，但过度依赖会削弱自身解决问题的能力。
  👉 启示：工具应作为“辅助”而非“替代”，需保持对核心技术的理解和实践，避免沦为“工具操作者”。

• 教训6：过度依赖单一第三方工具，抗风险能力弱
  因“augment锁区、插件停更”导致开发受阻，暴露了对单一工具的强依赖风险。
  👉 启示：关键工具需预留替代方案，避免因第三方变动导致项目停滞。

四、环境与配置管理的疏漏

• 教训7：开发/生产环境隔离混乱，部署效率低
  日志多次提到“开发环境调试日志未清理”“docker环境切换未系统化”“生产/开发/开源三套代码环境混乱”，导致部署时问题频发。
  👉 启示：提前规划环境隔离方案（如通过配置文件区分环境变量、构建脚本分离），确保开发、测试、生产环境一致且可切换。

• 教训8：数据持久化与配置管理缺失
  数据库文件未映射到宿主机，导致“容器重启丢失数据”；SSL证书管理分散（服务器路径与项目文件混杂），增加维护成本。
  👉 启示：核心数据（如数据库、用户上传文件）必须通过容器卷映射到宿主机；配置文件（如证书、环境变量）需集中管理并纳入版本控制。

五、测试与问题跟踪的不规范

• 教训9：测试不充分，依赖“部署后调试”，效率低下
  大量问题（如前端显示异常、接口500错误）在部署后才发现，本地调试不彻底，依赖“重启容器”排查，浪费时间。
  👉 启示：建立本地完整测试流程（单元测试、集成测试），模拟生产环境验证，减少“部署即报错”的情况。

• 教训10：日志与问题跟踪分散，排查困难
  日志分散在“与copilot/augment的聊天记录中”，问题列表不独立，导致“很多问题需要回头翻聊天记录”，排查效率低。
  👉 启示：使用专门的问题跟踪工具（如Jira、GitHub Issues）记录bug和任务，日志需按模块、时间归档，避免依赖碎片化记录。

六、安全与部署的前置考量

• 教训11：安全意识薄弱，忽视基础安全措施
  存在“注册无限制、缺乏防重复注册机制”“安全隐患多”等问题，且未提前规划服务器资源（如“服务器资源紧张需升级”）。
  👉 启示：安全设计（权限控制、输入校验、注册限制）应与功能开发同步进行；部署前需评估服务器资源、网络安全（如SSL配置）。

• 教训12：部署流程不规范，数据与配置迁移困难
  数据库初始化脚本未整合、容器部署未自动化，导致“新机器部署需手动调整”。
  👉 启示：通过Docker Compose或CI/CD工具（如Jenkins）实现部署自动化，确保“一键部署”；数据库初始化脚本需包含全量必要数据。

七、版本与依赖管理的教训

• 教训13：依赖升级与兼容性考虑不足
  因Spring Boot版本升级（2.7→3.4）意外解决了“500错误”，但未提前评估升级风险，说明依赖管理随意。
  👉 启示：依赖升级需提前做兼容性测试，记录升级影响范围，避免“盲目升级靠运气解决问题”。

• 教训14：开源版与商业版的边界模糊，导致维护分裂
  最初设想“开发版基于开源版”，最终因设计缺陷沦为“两套独立代码”，增加维护成本。
  👉 启示：多版本开发前需明确“公共核心模块”与“版本差异模块”，通过抽象接口隔离差异，避免代码完全割裂。

这些教训覆盖了项目全生命周期（规划、开发、测试、部署、维护），核心可总结为：“前期规划定方向，流程规范保效率，工具依赖需理性，核心价值不偏离”。

（好吧其实这些教训也是我让豆包生成的）

总之，开发过程中走了很多很多弯路。吃一堑，长一智吧。

在这段时间里，我同时也经历了很多很多其它的事情

回想起来，这两个月里，我有一半以上的时间都是在对这个项目修修改改。

前几天看了讲扎克伯格的《社交网络》，最近又在看美剧《硅谷》，看到第二季第二集了。​

看到这些天才或因为创新的思维、或因为聪慧的大脑，创造出一个又一个改变世界的应用，我便不禁想象我的 DevEnv 是否也能创造相同的奇迹。​

很显然，绝无可能。​

我自知我绝非天才。我既没有扎克伯格那种在哈佛宿舍里敲几行代码就能搅动社交领域风云的敏锐嗅觉，也没有理查德面对硅谷资本围猎时始终攥紧算法核心的偏执底气，更没有那群怪才程序员在集装箱办公室里用披萨盒当键盘托也能写出颠覆性代码的疯狂灵气。我的 DevEnv 里存着的，不过是改了又改的 bug 记录、抄了半本的技术文档，还有深夜调试时不小心落在键盘上的烟灰 —— 它们更像是我这个普通开发者的生活注脚，而非撬动世界的支点。

但我相信我会找到我的一隅。
即使DevEnv不能创造奇迹，我也会继续创造出其它作品。