第一步：先搞清楚到底要做什么——需求，不是“你以为的”那个需求

很多项目出问题，不是代码写得烂，是开始就没对齐。

我们接过一个物流调度项目，客户刚开始的需求文档写得特别细：要有大屏、要有报表、要能实时看车辆位置。聊了三次之后才发现，他真正头疼的根本不是“看不到车在哪”，而是“调度员每天花两个小时手动排单，还老排错”。

所以我们的习惯是：先坐下来，看他们怎么干活。

不是拿着需求文档一条条过，是搬个小板凳坐他们工位旁边，看他们打开哪些页面、复制哪些数据、给谁打电话、在什么环节会停下来抽烟叹气。

这些才是真正的需求。页面上的那个按钮，远没有他们手边那张写满备注的A4纸重要。

最后我们没做大屏——客户自己都觉得那东西中看不中用。我们做了个智能排单引擎，把两小时的手工活压到了十分钟。上线那天调度员反而有点失落：“这就完了？我本来每天还能靠这段时间摸会儿鱼呢。”

第二步：技术选型，我们选“笨”的

技术圈有个风气，喜欢追新。

我们不太一样。如果某个新技术刚出来不到一年，我们基本不会往生产环境里放——不是不敢尝鲜，是对客户的系统负责。客户花钱买的是稳定，不是给我们当小白鼠的。

我们常用的技术栈其实挺“老”的：

• 后端主力是 Java (Spring Boot)，稳定，生态成熟，出了问题好找人

• 前端 Vue 3 为主，偶尔 React，看团队熟悉程度

• 数据库 PostgreSQL 或 MySQL，根据数据量和使用场景来选

• 部署走 Docker + K8s，方便扩展和维护

真遇到高并发或者特殊场景，再按需往上加东西。比如之前做一个秒杀类的营销工具，我们在网关层加了 Redis 缓存和限流，没动核心架构——用最小的改动解决最大的问题，这是我们喜欢的风格。

不是我们不会用新东西。是觉得技术选型这事，合适的比时髦的重要得多。

第三步：写代码的日常，没你想的那么高大上

说实话，我们写代码的过程挺枯燥的。

每天站会，各人说昨天干了啥、今天要干啥、卡在哪了。然后各自回工位，敲键盘，偶尔传来几句“谁把接口改了我这调不通了”或者“这个需求你再跟我讲一遍我没懂”。

我们用的是 GitFlow 分支管理，主干分支永远是干净的、可部署的状态。每个功能拉一个分支，开发完自己先测一轮，然后提 Pull Request，必须有至少一个人 Review 过才能合进去。

代码规范这东西我们一开始用工具强行卡，后来大家慢慢养成习惯了，也就不是个事了。现在新同事进来，前两周基本都在看代码规范文档和跟着老员工结对编程——不是故意折腾新人，是有些坑，只有亲手踩过才知道为什么要这么写。

关于加班——我们尽量不搞那种“通宵上线”的浪漫主义。真熬过几次，第二天全员魂不守舍，写出来的 Bug 比平时多三倍。现在我们的原则是：宁可晚一天上线，也不要带着疲惫上线。

第四步：测试，我们跟 Bug 有仇

我们有个不太上台面的“光荣榜”——不是表彰谁写得好，是记录谁写的 Bug 在生产环境造成了故障。

不是为了追责，是为了让大家长记性。榜上至今排第一的是我们 CTO，有一次他手抖删了一条索引，差点把整个测试库搞挂。他自己把这事写在榜上，旁边批注：“再犯请全组喝一个月奶茶。”

正经说，我们的测试流程分几层：

1. 单元测试——开发自己写，至少覆盖核心业务逻辑

2. 集成测试——测各个模块能不能好好配合

3. UI/接口自动化——用脚本跑一遍核心流程，确保改一个地方没把另一个弄坏

4. 人工验收——产品经理模仿用户瞎点一通，经常能发现意想不到的问题

还有一个环节我们特别重视：上线前的“破坏性测试”。就是故意往系统里塞异常数据、高并发请求、断网重连，看它会不会崩、崩了能不能自己恢复。

有一次测试同事在压力测试里发现系统在某个数据量级下响应时间突然飙升，查了半天是数据库查询没走索引。这要是上了生产再发现，客户那边估计已经骂人了。

第五步：上线不是结束，是开始

系统交到客户手里，对我们来说不是“完事了”，是“终于可以看看真实情况了”。

我们每个项目都接日志监控和性能追踪。上线第一周，开发团队会轮流盯监控大盘——不是那种假装很忙地盯，是真的有报警就马上响应。

有一次凌晨两点，某客户系统的接口响应时间突然从 200ms 涨到 3 秒。值班同事爬起来查，发现是另一个客户的定时任务在同一个数据库实例上跑全量统计，把 CPU 吃满了。隔离资源、优化 SQL、调整任务执行时间，折腾到凌晨四点搞定。第二天客户完全不知道发生过这事——我们觉得这就是该有的样子。

我们也做迭代。小需求两周一个版本，大的按月来。每次发版前给客户发个更新说明，不写“优化了用户体验”这种废话，直接写“修复了导出报表时第 3 列合计数字算错的问题”或者“新增了按部门筛选工单的功能”。

客户可能不懂技术，但他们看得懂问题有没有被解决。

我们踩过的那些坑（血泪版）

说几个我们自己也栽过的跟头，给同行提个醒：

坑一：需求说得太满
有次客户问“这个功能能不能做”，我们脑子一热说“能”。后来发现涉及第三方接口，对方文档写得跟天书一样，沟通了两个月才搞定。现在我们的回答改成：“能做，但需要先调研一下第三方那边的情况，明天给你准确答复。”

坑二：低估了数据迁移的难度
帮一个客户从旧系统切到新系统，数据量几百万条，字段映射关系错综复杂。我们一开始以为写个脚本跑一晚就行，结果各种脏数据、空字段、格式不统一，整整清理了一周。现在遇到数据迁移，我们先说：“数据清理的时间可能比开发新功能还长，你有个心理准备。”

坑三：没跟客户讲清楚“定制”和“配置”的区别
客户以为买了系统就可以随心所欲改界面，我们以为他说的是改改配色和 logo。结果他要的是每个用户能自己拖拽布局、自定义字段——那是另一个量级的工作量。现在我们在合同里就把“定制开发”和“系统配置”分两条写，附上具体例子。

一些我们坚持的小原则

这么多年做下来，有几条不成文的规矩，我们自己一直在守：

1. 不接做不了的项目——如果客户的需求明显超出我们的能力范围，或者时间紧到不可能完成，我们会直接说“这个我们接不了”。比做到一半再承认要好一万倍。

2. 不跟客户玩文字游戏——人天怎么算、售后包含什么、哪些功能算额外收费，全部白纸黑字写清楚。模糊的地方吃亏的往往是双方——客户觉得被坑了，我们觉得被冤枉了。

3. 代码写清楚比写得“聪明”重要——那种只有自己看得懂的炫技代码，我们 code review 基本不让过。下一个接手的同事可能会在内心问候你全家。

4. 客户说“这个不急”的时候，我们反而更上心——经验告诉我们，客户说不急的事，往往过两天就会变成“怎么还没好”。

最后，聊聊我们怎么定义“做好”一个项目

衡量一个项目成不成功，我们内部有一个很朴素的标尺：

三个月后，客户还在用。而且用的时候不骂人。

听起来简单，做起来真不容易。这意味着系统要稳定、要顺手、要能真正帮到他们的日常工作。意味着我们写下的每一行代码，都在某个真实的场景里被人使用着，而不是躺在服务器里落灰。

我们不是什么大厂，也没有几万人的研发团队。能拿得出手的，就是认认真真把每行代码写好，把每个客户的真实需求当回事。

如果你有个想法想落地，或者有个老系统想改造，不妨来找我们聊聊。不一定非要做，喝杯茶、交换一些踩坑经验也行。

毕竟在这个行业里，真诚，是我们能提供的最高配置。