奇葩需求不断的来,代码越来越乱,大家遇到这种情况么?

[Ouyangan]

一点一点看着手中的代码变成了屎,很难过,真的 , 所以只有一条路...

[paopaosa]

每天经历。

[OOXZ]

日常

[JenJieJu]

日常

[JenJieJu]

日常+1

[bzw875]

一边做需求一边优化代码结构，因为只有我维护，所以代码还是挺漂亮的。

[taresky]

奇葩需求不断的来，你可以拒绝啊。只要你承担拒绝这个需求的责任和后果。
因为产品提出需求，他就得承担当这个需求未解决问题的责任，或者更变需求的后果。

代码越来越乱，这不是你的事情吗？

[Duolingo]

最近在看一个几年了的老项目的代码
乱成狗，废弃代码多如狗
准备先完成新需求，然后慢慢改老代码了
也算是给自己的考验

[bk201]

需求与代码乱不乱好像没关系吧。是我理解问题？

[ByZHkc3]

日常+1

[Cim]

最开始的时候脑子里那架构完美，漂亮 。写着写着发现代码烂的跟垃圾样

[rokeyzki]

码农日常，特别是人员越多，需求又不断改动，已经每次迭代工期很短，就很难避免这种情况出现

[mikan]

一年后就受不了要开始重写了，然后无限循环

[zjq426]

很多时候最后归结到是一个各自坚持最后彼此理解甚至妥协的问题。

应对的方法用正常向吧：沟通，磨合，估算工作量的时候把技术调整，测试等工作量估算进去。很关键的一点是其实应该多花时间去分析需求，设计系统，最后 coding 的工作应该只是 20%－ 30%，如果上来不设计好直接就写代码，后面调整的时间可能加起来还要更多。

程度的问题：代码正确，可维护，系统健壮。但要赶得上业务变化的速度。没有业务光有代码如果您是纯技术创业团队当我没说。

[sharpy]

很多时候什么架构都是理想化
看着代码 悲从中来 干

[pynix]

架构是什么东西？能吃吗？

[learnshare]

重构，有时间就策划重构。否则越堆越容易垮掉

[busymilk]

定一个计划：提前几天做完， boss 一看，哎呦，有效率！于是下次就缩短几天，然后继续玩命做，继续缩短，死循环，结果越写越快，越来越乱。。。。。

[ferock]

@busymilk 赞

[zzNucker]

真的是日常。

[xiaoshenke]

重构。

[quericy]

日常+N
每次需求都是要求先快点简单做,然后变得越来越奇葩
需求一直不停怎么重构

[NovemberEleven]

日常+1

[murmur]

没有关系啊，只要产品失败了锅别让程序背就可以

[Infernalzero]

所以我一直觉得很多产品经理都是天生的败家娘们，特点：有钱就花，买东西不要钱

[domty]

没严格的代码规范或者人员流动频繁就会影响这个。
也有的就是完全程序员水平的问题，我就见过嵌套超过 4 个 if 语句，大括号满天飞。
也有纯粹烂需求设计的问题，有的需求你一看就知道没法写出好代码。

[webdev]

你这么有追求的人，应该到我们公司

我们公司的程序员是这样的：不 care 任何业务流程，只按照 solution doc 来写代码， Bug 出的多，没关系，只要你能修，你依然是好员工，加工资，你如果干的不爽，和老板说下，老板送你去米国散散心，或者给你加工资。如果你想移民，也没关系，和老板说下，老板半年内不给你任何任务，钱照拿。如果你想赚外快，没关系，自己拉业务做，来加班照样管饭。

[Ouyangan]

@domty 非常好的回答
@webdev 可以啊 ,哈哈哈

[SlipStupig]

@webdev 看着我都想来了

[oglop]

@webdev 这是自动桌 autodesk 么？

[realpg]

奇葩需求跟代码难看有啥关联？
之前做传销软件，那需求比你们见过的所有需求加起来都奇葩，代码也没难看哪去啊

[Ouyangan]

@realpg 关键在于以后的人接手的时候代码很难维护.

[Mirana]

刚开始的时候抽象了一些代码出来，写的好好的，突然来了个奇葩需求，导致抽象出来的代码不能复用了，这时候就悲剧了。

[Ouyangan]

@Mirana 比如单独为一个账号做个小功能就不说了 , 更奇葩的是一个账号要当两个账户使..

[annielong]

奇葩需求都是小 CASE ，就怕奇葩到能把核心流程都给改掉，当初按需求设计的时候谁会考虑核心流程来个适配功能

[realpg]

@Ouyangan 奇葩需求，不代表你的实现方式也需要很奇葩啊！多坑的需求，到好的 programmer 手里，都能做出很标准很优雅的代码