开发环境的一些思考：一个天通苑前端在公司倒闭后的技术复盘
去年十月的一个周五晚上，北京的天气已经开始转凉。我坐在天通苑那间月租3500的出租屋里，电脑屏幕还亮着，但眼神已经放空了。微信弹出一条消息，是我们CTO发来的：“兄弟们，公司撑不住了，下周一起不来了。”
那一刻，我没有哭，也没有砸键盘——不是因为坚强，而是连情绪都麻木了。上个月刚交完房租，信用卡还欠着8000多，老婆在老家带孩子，电话里她轻声说：“没事，大不了回老家。”可我知道，回老家意味着什么。我28岁，前端三年经验，简历上写着“精通Vue/React”，但实际上连Webpack配置都是复制粘贴改改参数。
而就在那天下午，我还卡在一个开发环境的问题上：本地启动的Springboot后端服务死活连不上数据库，报错信息翻来覆去就那一行：
java.sql.SQLException: Access denied for user 'dev'@'localhost'
现在回头看，那个看似微不足道的环境问题，其实早就是整个项目混乱状态的缩影。
一、从“能跑就行”到“根本跑不起来”
我们公司做的是一个数据采集平台，核心功能之一是用爬虫抓取公开网页数据，然后通过Springboot API提供给前端展示。听起来挺高大上，对吧？但现实是：整个开发流程就像用胶带缠着漏水的水管——勉强能用，但随时可能爆掉。
最开始，后端小李（就叫他小李吧）把Springboot项目丢到GitLab上，README里只有一句：“本地启动：mvn spring-boot:run”。没人告诉我数据库怎么配，也没人说Redis要不要装。我问：“测试账号密码是多少？”他说：“哦，你连本地MySQL，用户名dev，密码123456。”
我：“……那数据库表呢？”
他：“你自己跑sql脚本啊，在/docs/init.sql里。”
我翻遍整个仓库，根本没这个文件。
最后花了三天，靠反向工程+日志+猜，才勉强搭起一个能调接口的环境。而这时候，产品已经催着要联调了。没办法，只能硬着头皮上。结果前端页面刚跑起来，后端突然说：“哎呀，爬虫那边改了字段结构，你得同步一下。” 我问改了哪，他说：“你去看最新commit。”
这种“协作”，与其说是开发，不如说是各自在黑暗中摸象。
二、爬虫、Springboot和前端：三座孤岛
我们的技术栈名义上是“前后端分离 + 微服务”，但实际上，三个模块之间几乎没有契约。
- 爬虫团队：Python写的一堆脚本，每天凌晨跑，数据扔进MySQL。但他们从不通知字段变更，也不维护文档。
- Springboot后端：用MyBatis直接查库，接口返回格式随心所欲，今天是
{data: [...]}，明天变成{result: {list: [...]}}。 - 前端我：每次接口一变，就得手动画mock，或者求后端临时开个本地代理。
最离谱的一次是，爬虫偷偷加了个字段叫is_valid，但没告诉任何人。结果上线后，所有列表页全空白——因为后端默认过滤了is_valid = false的数据，而前端压根不知道这个逻辑存在。
我当时在办公室拍桌子：“你们能不能搞个OpenAPI文档？哪怕Swagger也行啊！”
后端老大慢悠悠地说：“文档？代码就是文档。”
呵，代码要是真能当文档，那全世界程序员早就失业了。
三、环境即契约：我后来才明白的事
公司倒闭后，我花了整整一个月找工作。那段日子特别焦虑，每天刷BOSS直聘到凌晨两点，投出去的简历石沉大海。有天晚上，老婆问我：“是不是技术不行？”
我说：“不是技术不行，是之前那套‘野路子’根本经不起面试官拷打。”
痛定思痛，我开始系统性地补课。其中最重要的一课，就是重新理解“开发环境”的意义。
以前我以为开发环境就是“让代码跑起来的地方”。但现在我明白了：开发环境本质上是一种团队契约的具象化。它回答了这些问题：
- 新人第一天入职，要装哪些软件？
- 数据库 schema 由谁维护？如何同步？
- 接口变更是否自动触发前端告警？
- 爬虫输出的数据格式是否有 Schema 校验？
举个例子：我现在参与的新项目，用 Docker Compose 一键启动整套环境。docker-compose.yml 里定义了：
- MySQL 容器（带初始化脚本）
- Redis
- Springboot 应用（自动连DB）
- 甚至一个 mock 的爬虫服务（返回固定 JSON）
前端只需要 npm run dev，所有接口自动代理到本地容器。更关键的是，我们用 JSON Schema 定义了爬虫输出的数据结构，Springboot 启动时会校验入库数据是否符合 Schema。如果不符合？直接抛异常，不让脏数据污染系统。
这种设计下，前端再也不用担心“字段突然消失”。因为契约被固化在代码和工具链里，而不是依赖某个人的记忆或口头承诺。
四、技术分享不该只是“秀肌肉”
说到这儿，我想吐槽一个现象：网上太多“技术分享”文章，标题动不动就是《基于Springboot + Vue3 + Webpack5 的高性能架构实践》，点进去一看，全是配置截图+版本号罗列，却不说清楚“为什么这么选”、“踩了什么坑”、“团队协作成本如何”。
真正的技术分享，应该包含上下文。比如：
“我们团队有5个前端、3个后端、2个爬虫工程师，大家分布在三个城市。所以我们选择用 OpenAPI 3.0 作为接口契约，并集成到 CI 流程中——每次后端提交代码，CI 会自动生成 TypeScript 类型定义并推送到前端仓库。”
这样的分享才有价值。因为它暴露了约束条件，而不仅仅是最终方案。
我在前公司倒也不是没人想搞规范。有次我提议：“咱们用 Docker 统一环境吧？” CTO 摆摆手：“太重了，小公司搞不起。”
我说：“那至少弄个 .env.example 文件？”
他说：“你直接 copy 别人的 .env 改改不就行了？”
你看，问题从来不是技术，而是对协作成本的漠视。
五、从天通苑到未来：我的新认知
现在我在一家还算稳定的创业公司，月薪从15k涨到了22k。虽然还是住在天通苑，但心态变了。我不再把“开发环境”看作累赘，而是把它当作团队信任的基础设施。
具体来说，我坚持三件事：
- 环境可复现：新人入职，30分钟内必须跑通全栈 demo。做不到？那就是流程有缺陷。
- 契约显式化：爬虫输出、API 接口、数据库变更，全部要有 Schema 或文档，且纳入版本控制。
- 失败快速反馈：本地开发时，任何环境错误（如DB连不上、依赖缺失）必须给出清晰指引，而不是一堆堆栈。
最近我们甚至用 Springboot 写了个简单的“环境健康检查”端点 /health，前端启动时自动调用。如果后端没跑、DB没连、爬虫mock没启，页面上直接显示红色提示：“请先启动以下服务：xxx”。
这听起来很基础，对吧？但正是这些“基础”，决定了一个团队能走多远。
六、写给同样在挣扎的你
如果你也像曾经的我一样，在混乱的环境中疲于奔命，请记住：
糟糕的开发环境，从来不是你的错，但改善它，可以是你的机会。
不要等着老板或CTO来推动改变。你可以从小事做起：
- 在 README 里写清楚本地启动步骤
- 给爬虫输出加个 JSON Schema 示例
- 用 Postman 导出一套接口集合分享给前端
这些动作花不了多少时间，但传递了一个信号：“我重视协作，也尊重他人的时间。”
公司倒闭那晚，我其实删掉了所有工作相关的代码。但唯独保留了一个文件：local-setup-guide.md。那是我熬了两个通宵整理的本地环境搭建指南，虽然从未被团队采用，但对我自己而言，它是从“码农”走向“工程师”的起点。
技术会过时，框架会更迭，但对清晰、可靠、可协作的开发环境的追求，永远不会过时。
最后，如果你也在天通苑租房，月租3500，每天挤5号线，偶尔怀疑人生——别怕。我们都在泥泞中前行，但只要脚下有路，眼里有光，就还没输。
共勉。
评论 0