在创业公司当程序员的那些年，我学会了“在混乱中写代码”
如果你问我，在大厂和创业公司当程序员有什么区别，我会毫不犹豫地说：
大厂里你在维护系统，创业公司里你在创造世界。
我是在2019年底加入一家当时不到20人的SaaS初创公司，做的是面向中小商户的数字化运营平台。刚开始的时候，公司还没有成型的产品架构，技术团队就3个人，连一个完整的CI/CD流程都没有，更别说日志、监控、报警这些基础设施。
这篇文章不是教你什么高深的微服务设计原则，也不是炫耀我写过多少万行代码。它更像是我过去几年在创业公司摸爬滚打的真实写照——那些深夜加班改BUG的崩溃瞬间、那些一边重构又一边上线的魔幻现实、还有在资源极度有限的情况下如何“把活干出来”的无奈与智慧。
开发背景：开局一张图，项目自己搭
我们做的是一款轻量级的商家管理系统，核心功能包括门店管理、员工权限、营销活动配置、订单统计、数据看板等。
刚来的时候，老板丢给我一份原型图和一句话：“我们想要像XXX那样酷炫的后台系统，但要更轻更快。”
我内心OS：你们是要淘宝，但我只有拼多多的预算。
技术栈上，前端用React + TypeScript，后端是Node.js Express，数据库用MongoDB（后来改成PostgreSQL），部署环境是阿里云 ECS + Docker。
项目没有设计文档，只有几个零散的需求说明。最离谱的是，第一个月我还以为只是做些小模块，结果一周内就被任命为技术负责人。
真实挑战1：需求爆炸+频繁变更，代码越写越烂
初期我们采用的是敏捷开发模式，每周一迭代。可问题是，需求变更是家常便饭，而且产品经理还不懂技术，经常一句“这个很简单吧？”就要你重写整个表单逻辑。
举个例子，原本我们用了Ant Design Pro的ProTable来做数据展示，支持筛选、导出等功能。结果有一次，产品经理说用户希望“自定义字段顺序”，然后又加了一个“动态列配置”需求，最后还要求“每个角色看到的列不同”。
我当时整个人都傻了。那块代码已经是面条式的了，再这么折腾下去迟早炸锅。
解决方案1：边写边重构，用插件化架构救场
为了不让代码崩盘，我采取了两个关键策略：
将表格组件抽象成一个独立模块 TableX
这个组件内部封装了列配置、权限控制、排序过滤等通用逻辑，并提供了统一的props接口。这样不管是哪个页面调用，只需要传入配置项就能渲染不同的表格。引入中间状态层 configStore
我们用MobX创建了一个全局的数据存储，保存用户的表头偏好、当前角色权限等信息。这样一来，即使切换角色也能自动调整列可见性。
这两个改动让后续扩展变得轻松了不少。比如后来加上“字段分组”、“条件隐藏”等新功能，也只需要在TableX里加个配置项就行了。
真实挑战2：线上故障频发，无监控无报警全靠人肉盯
上线几个月后，我们开始接到客户投诉：“为什么优惠券发不出去？”、“为什么数据昨天突然没更新？”
查日志时才发现问题很多，但没人第一时间知道。运维方面基本等于零，Docker跑起来能访问就算上线成功。服务器有没有负载异常？不知道。接口有没有慢请求？也不知道。Redis连接超时？全靠用户反馈才察觉。
最严重的一次是我们用了某个第三方短信服务商的SDK，里面有一个异步回调没有处理好，在并发高的时候导致整个Node进程卡死，整点挂一次。
解决方案2：从零搭建基础监控体系
我花了一个多星期的时间做了三件事：
- 引入Prometheus + Node Exporter监控服务器状态
- 使用Winston+ELK集中收集日志
- 在API网关层加埋点，记录接口响应时间与错误码
这套东西虽然比不上大公司的SkyWalking/Apex，但对于创业公司来说已经够用了。再加上用钉钉机器人实现了报警机制，一旦接口平均耗时超过3秒就会告警，极大提升了系统的可观测性。
还有一个小技巧值得一提：我在入口处加了个request context，用来记录请求来源、trace ID和用户ID。这样排查问题的时候，能快速定位到具体用户，甚至还能复现某些特殊行为。
技术选型的权衡：别怕踩坑，关键是踩得值不值
我们在初期选择MongoDB主要是因为灵活、上手快。但随着数据量增长，发现查询性能越来越差，而且Schema管理特别乱。
最终决定迁移到PostgreSQL，并且在迁移过程中采用了双写策略：先往旧库写数据，再同步写入新库，一段时间后再切换读流量。
虽然这过程很痛苦，但也带来了几个好处：
- 查询效率提升明显
- 数据结构更清晰规范
- 后期接入BI工具也更容易
所以说，技术选型不能只看眼前方便，要考虑未来能不能撑得住业务发展。有时候看似绕了远路，其实才是最快的。
经验总结：创业公司程序员的成长节奏
在这四年多的时间里，我经历了从一线写代码，到主导架构设计，再到组建技术团队的过程。以下是一些我认为非常值得分享的经验：
1. 不要追求“完美架构”，要追求“可用架构”
创业公司的节奏决定了你不可能一开始就设计出完美的微服务架构。很多时候，先把事情做成比把事情做好更重要。
2. 尽早建立工程规范
哪怕一开始只有三个人，也要制定一套基本的开发流程：代码审查、分支策略、自动化测试。这些看似琐碎的事情，会在后期爆发巨大的回报。
3. 学会和产品经理“打架”
有时候他们提出的并不是用户真实需求，而是自己对竞品功能的简单模仿。你需要站在技术和用户体验的角度，帮助他们理清优先级。
4. 保持学习力，但别盲目追风
现在各种新技术层出不穷，但别一看到新玩意就想引入。评估成本、团队能力、长期维护才是重点。
最后的思考：在创业公司写代码，是一种修行
说实话，这段经历并不轻松，但非常宝贵。你会被迫快速成长，会被各种需求逼着学习新的东西，也会在一次次重构中理解什么是“优雅的代码”。
我也曾怀疑过，为什么要在这样一个“土作坊”里坚持这么久？
直到有一天，我们系统里的某个模块被客户夸赞“比头部品牌的体验还好”，我才真正明白：
不是只有大厂才值得写好代码，也不是只有成熟项目才能体现架构能力。
在创业公司，我们用最少的人、最短的时间、最小的成本，去解决真实的业务问题，这本身就是一种技术的艺术。
如果你想进创业公司当程序员，请做好心理准备：
你不会天天研究算法，也不会有太多时间打磨代码美学。但你会学到：
- 如何在不确定性中推进项目
- 如何在有限资源下做出决策
- 如何面对快速变化的技术生态
- 如何把一堆碎片拼成一个完整的世界
而这些，才是真正的实战经验。
如果你也是在创业公司摸爬滚打的工程师，或者正打算进去，欢迎留言交流，一起吐槽，一起成长！
写代码不易，写好代码更难。但如果我们能在混乱中写出靠谱的系统，那才是真正牛逼的事。
评论 0