工作中什么样的需求算简单，什么样需求算复杂

需求越复杂就越简单，需求越简单就越复杂

真实

明确的简单, 模糊的复杂.

牵扯的多的就复杂 单一的就简单。

我觉得凡是能用技术话术把实现逻辑描述清楚的都算简单的。

需求就几句话

什么样的需求算简单？
多表联合查询但没有统一 ID 字段且数据量超过 5PB 要求模糊查询 10 秒内出结果

什么样需求算复杂？
你随便做一个、你看着办、我不懂呀你们定、简单的小功能啦、一个小时应该能搞定

大部分明确的需求都是简单的，模糊和留一手的最复杂，我经常碰到故意留着些点不说，挤牙膏一样慢慢挤出来的需求

我假设 lz 是开发，问的是代码项目而不是其他。
这个问题想问的，我觉得主要还是代码类项目的复杂度问题怎么衡量。代码量大就复杂吗，如果都是差不多的逻辑，一大堆的增删改查，应该算不上「复杂」。
我记得是有一些指标来衡量代码复杂度的，例如说圈复杂度（独立现行路径条数），需要判断的分支越多，就越复杂。
依赖也会带来复杂度，虽然我们希望好的设计能尽量解耦减少依赖（也是为了降低复杂度），但依赖终归不可避免。你不 include 文件改调用接口了，依赖只是换了一种形式而已。

原来我做了很多增删改查的项目，虽然随着业务的变化，很多数据看起来是需要经过一圈计算才能拿到，但核心也还是增删改查，感觉不算「复杂」。产品把业务规则说明白了，我翻译成代码就行了。

后来在去大厂搞了一些项目，比如说 API 网关的流控计费这种；几乎是不需要跟数据库打交道的，一年没写 SQL ；数据的持久化用 levelDB+raft 搭的分布式存储；一个请求，接收后，要经过七八个模块，有同步的处理有异步的处理，体感上「复杂度」就上升很多。

就是你接手的时候，梳理模块链路的文档就要写 1w 字+几张流程图；
随着业务的增长，主流程之外的补丁式的分支流程，就是各种特例和意外非常多；
整个流程很难在短时间记在脑子里从头到尾说明白；
细节部分经常忘了是怎么回事需要去回看；
出了问题很难快速定位到是哪儿的问题，不知道怎么在一天几百 G 的日志里找你要的关键词；

在这样的系统上工作，大概就是一种处理「复杂问题」的感觉，不管什么需求，都很可能牵一发动全身，所以你不得不非常谨慎反复求证，跟负责人反复探讨确认 edge case ，做完之后反复测试，上线之后一天里提心吊胆，就是复杂需求了。

@CarryOnHxy #6
把人安全送上月球，然后安全地送回来

@syubo2810 赞成，这种就得看产品经理 和 客户的实力了。。产品有时候真的。。哎

我评估的标准是：
能说一个完成时间出来，并在那个时间节点完成，就是简单的
完成时间不确定，就复杂的

让我想起我们老板,把 ai 集成到系统里,1 星期就够了吧,下下周我给客户演示

-> 我们要盖一栋三层小别墅
-> 我们需要再加盖两层
-> 加个电梯
-> 把别墅复制粘贴一套到隔壁
-> 现在我们需要把这两栋别墅改成双子塔

1. 一句话需求
2. 替业务背锅的需求，这种需求一定要把能实现的效果的边界广而告之

涉及的模块越少，需要的沟通对接的资源越少的需求就越简单。

涉及的模块甚至业务线越多，需要沟通的对接越多，甚至需求稍微变动一下就得开个会来整理变动范围的就越复杂。

在补丁糊的比本体还厚的系统上做需求复杂
在新系统上做需求简单

一种是需求说不清的，这里的复杂是指开发后反复修改的复杂，主要是心累。一种是系统经过相当多需求的迭代后，各种前后业务关系导致新来的需求牵一发而动全身，这时候的复杂就需要开发者通过模块或者架构的设计来降低业务复杂带来的影响。这里就会存在悖论，业务还没起来的时候无法预知后续的发展，怎么设计架构，那就需要开发者有一定的经验，或者在业务成熟的时候干脆来一场轰轰烈烈的重构

我来定，我看得透的就简单，看不透的就复杂

@kapaseker 点了