写不出代码怎么办 - 我的学习小铺

一、为什么写不出代码？#

新人写不出代码，归根结底只有两个原因。第一个，也是最常见：需求没理解。

为什么这一条排第一？因为代码是为业务服务的，脱离了业务，代码就毫无意义——你写什么样的代码，取决于需求是什么。 需求都不明确，你要写什么代码自然也不明确，写不出来才是正常的。

但偏偏这一步，是新人最容易跳过的，常见两种情况：

一种是看两眼文档，觉得“大概懂了”，立马开始写，结果写两行就卡住——因为你根本没真正理解，只是感觉自己理解了。

另一种更常见：其实没看懂，但不好意思问。怕导师觉得你菜、怕问出来显得自己笨，就硬撑着、对着文档发呆。结果时间白白耗掉，需求还是一团雾水。

记住：问需求不丢人，做出来的东西完全跑偏才丢人。导师宁愿你花十分钟问清楚，也不想看你憋两天交一坨错的东西。

真正理解一个需求，至少要能答出这几个问题：

这个功能干什么？ 最终实现什么效果？
谁在用？ 运营、管理员、还是普通用户？
输入是什么？ 前端传什么参数？
输出是什么？ 返回什么数据、页面展示什么？
正常流程是什么？ 请求进来后会发生什么？
异常情况怎么处理？ 参数为空、查不到数据、用户被禁用……

举个具体的例子，比如需求是根据用户 ID 查询订单列表，你得能答出：

干什么：传一个用户 ID，查出这个用户的所有订单
谁在用：后台运营人员，在管理页面查某个客户的订单
输入：userId、pageNum、pageSize（要分页）
输出：订单编号、金额、下单时间、订单状态
正常流程：校验参数 → 查库 → 返回分页列表
异常情况：userId 为空、查不到订单、用户被禁用

能这样答出来，才算真正理解了需求。只要有一个答不上来，那就不是”不会写代码”，而是根本不知道要写什么代码。这时候硬写没意义，正确做法是：

再看一遍需求文档和原型图
把不确定的地方记下来
找产品或导师确认

二、需求理解了，为什么还是写不出？#

因为你不会拆分问题。

新人最容易犯的错，就是脑子里装着一整个功能（比如”做一个订单查询接口”），然后开始发呆——因为这问题太大，大到不知道从哪下手。

这时候要做的不是继续想，而是拆，拆到自己会为止。

三、不会写，就继续拆#

假设需求是”根据用户 ID 查询订单列表”，怎么拆？要分两种情况：

情况一：项目里有高度相似的功能（最常见）

大部分需求，项目里都有”长得像”的现成功能。这时别自己设计，直接找最像的那个，照它的结构拆：

它有 Controller，你就建一个 Controller
它有 Service，你就建一个 Service
它的入参叫 XxxQueryReq，你的就叫 OrderQueryReq
它的方法叫 pageList，你的也叫 pageList，只改里面的表名和字段

照着抄结构，只改业务细节——这是真实开发里最常用、也最靠谱的拆法。

情况二：没有高度相似的功能，只能参考分层骨架

这种情况少，但会遇到（比如做一个全新模块）。这时候虽然没有”像”的功能可以照抄，但分层骨架和命名规范永远能参考——整个项目都在用 Controller→Service→Mapper 这套结构，DTO/VO 也是统一的命名。你就照这个骨架，把功能拆成一个个能动手的动作：

建接口：新建 Controller——会吧？
定入参：定义 Query 对象，放 userId、pageNum、pageSize——会吧？
定返回：定义 OrderVO——会吧？
写 Service：定义查询方法——会吧？
写 Mapper：写数据库查询——会吧？
返回结果：DO 转 VO——每一步，都是你已经会的。

无论哪种情况，结论都一样：原来不会的是”做订单查询接口”这个大问题，拆开以后每一步你都会。所以不是你不会，是你没拆到足够细。

如果拆出来的小问题你还不会，那就继续拆——一直拆到”新建一个类、写一个方法、定义一个字段”这种粒度，你就一定能动手。

四、真实开发中的万能流程#

看起来步骤不少，其实就是下面四步的细化。以后拿到需求，按这个顺序走：

第一步：看需求 —— 搞清楚做什么、给谁用、输入什么、输出什么。（这一步过了，你才知道要拆什么。）

第二步：按上面的拆法，把结构搭出来 —— 有高度相似的，照抄结构改字段；没有的，按项目的分层骨架和命名规范来。无论哪种，先有结构，再谈逻辑。

第三步：搭空架子 —— 不管结构是怎么来的，都先把三层空壳搭好、把链路跑通，再往里填逻辑：

1
// Controller：先把接口和入参出参定下来，方法体先空着
2
@PostMapping("/pageList")
3
public Result<List<OrderVO>> pageList(@RequestBody OrderQueryReq req) {
4
    return Result.success(Collections.emptyList());
5
}

1
// Service：先写空实现，确认链路通
2
public List<OrderVO> pageList(OrderQueryReq req) {
3
    return Collections.emptyList();
4
}

先用 Postman 跑通（请求能进、能返回），再回头填业务逻辑。

第四步：一层层补逻辑 —— 不要一次写完，每完成一步就测一步：

第一轮：接口能调通
第二轮：参数能接到
第三轮：SQL 能查出数据
第四轮：自测

这样出问题时，你只需要检查刚刚改过的那部分代码。

五、不会的时候，该问谁？#

到底问 AI 还是问同事？判断标准就一句话：换家公司还存在吗？

存在 → 问 AI。 比如 Stream 怎么转 Map、MyBatis 动态 SQL 加循环条件怎么加、Spring 事务怎么用等。这些是通用知识，问 AI 效率最高——而且最好保证它告诉你的东西，你下次能用上：就算记不住具体怎么写，至少得记住”有这么个东西，下次遇到能想到它”。

不存在 → 问同事。 比如 status=3 代表什么、为什么必须调用户中心接口、为什么不能直接查库、这表为什么这么设计。这些是项目特有的东西，AI 根本不知道。

但有一点必须强调：问 AI 是为了学，不是为了代劳。 尤其是新人，千万别图省事把整个功能甩给 AI 让它直接生成。问题要自己拆、骨架要自己搭、逻辑要自己写，AI 只在你卡在某个具体小问题上时给个提示。能自己动手的尽量自己动手。等你把基本功练扎实、有了独立写代码的底气之后，再让 AI 来写、你来监工。

六、一个重要的认知#

很多新人迟迟不敢动手，不是因为不会，而是想一步写出完美代码——怕命名不规范、怕方法拆得不优雅、怕被导师喷。

但真实开发不是这样。哪怕工作五六年的程序员，拿到需求也是先写出能跑的版本，再优化。

能跑通的代码，永远比脑子里完美的代码更有价值。

第一版丑一点没关系。先跑通、先验证、先保证有可交付出去的东西。

音乐