如何避免项目越来越乱

[lagoon]

之前呆过某家互联网公司，需求总是拍脑门（没有经过思考和设计）+明天就要，日积月累，后台越来越乱。（ ps.不是产品设计人员的错。领导明天就要，产品能设计一周吗？）
导致后台动不动就炸，改点什么，异常困难。

最后公司不说死在这上面，但发展也深受拖累就是了。

后来渐渐发现，项目无法摆脱这种糟糕的情况。

基本上的死循环是：

1 、第一个项目往往是新团队。领导也没底，不放心给超长时间把第一版做好。都希望尽快先出点成果，好交代，也好考察员工能力，万一做不出来也好调整。（明明第一版是最重要的基础）
于是第一版总是混乱赶工。这种混乱不单是技术混乱，而是从需求，到开发，到测试的整体赶工混乱。

2 、混乱的第一版完成之后，基础已经歪了。但这时候，其实可能是获得表扬的。超出预期达到了 xx 目标。
这时候，需要大重构而不是修 bug 式的小重构。 这时，“第一版+大重构”的时间，远远大于“好好做第一版”的时间。
显然不可能。

3 、迭代开始了.....

4 、项目质量越来越差.....

---

这个死循环不知道怎么破。

对于领导来说，新员工新团队，怎么可能放心给半年以上的时间去做一个东西呢？万一做不出来怎么办？

很无奈。

[ericgui]

离职，找一个新工作，涨薪 50%+

[mapoor]

"设计系统的架构受制于产生这些设计的组织的沟通结构。"
——M. Conway


什么样的公司结构就会产生什么样的系统，根本原因就是没有任何规则能约束领导的嘴。

[ghostsf]

做更多减法
不断调整优化代码

[ericgui]

@mapoor 是，本质还是管理层的问题，码农能做的事有限

[Jinxxxx]

依业务看除非是 2B 公司且公司有钱，有耐心有要求愿意慢慢打磨。不然以国内 2C 的环境，慢慢把第一版产品打磨出来可能市场早就没了，所以第一版往往都是赶工做完推向市场抢占用户。这是业务决定的，毕竟没有业务谁都没饭吃。
你要是真的想摆脱这类情况，可以看一些做 2B 做得比较好的公司，这种情况不说完全没有，但起码会好一些。

[hbolive]

楼主你说的这种情况是普遍存在的。
就拿京东来说，当年最开始就是 asp 做的，那时候的情况估计也是类似你描述的，一天一小改三天一大改。。但强哥能忽悠来投资啊，可以支撑后来的重构。。

[fwee]

第一步就有问题，需求多时间少必然越来越乱，应该直接砍需求只做 MVP 。不过根本原因还是领导不行，只能换公司了。

[2379920898]

我见过。非要 1 个月就上线的。。说是怕失去市场。。但是往往这种老板都是无经验的，都做不起来。。我也见过好几个月出项目的老板。。人家对市场也不着急。。但是项目上线之后慢慢也运营起来了。。给你个角度去思考。你不如先考量领导的经验能力上来思考。。一般比较急上线的都是创业经验很少的领导。。。

[tikazyq]

删库走人

[kingzeus]

找个靠谱的团队很重要

[arthas2234]

定时重构，剔除掉一些冗余的功能，我现在就在做这个事

[manami]

不要用框架

[wanguorui123]

没有代码规范、代码审核，很难做到代码的可维护性，大多数公司要求能跑就行了，也没有什么规范和审核之内的。
很多细枝末节的东西还得靠精细化管理和团队自律，不然早晚都会乱写的。

[MonoBiao]

代码重构专员

[Otho]

靠管理和自律的事儿，又不算 KPI 啥的，那基本无可避免。

[stleee0n]

熵增过程是一个自发的由有序向无序发展的过程

[charlie21]

这有什么值得苦恼的？

[baiyi]

《 Clean Architecture 》开篇就讲了这个问题

“研发团队必须从长远的利益出发与其他部门抗争，软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。如果忽视软件架构的价值，系统将变得越来越难以维护，成本也会越来越高。终会有一天，系统将变得再也无法修改。”

[azcvcza]

想啥呢，代码质量又不算 KPI，能用多少 if else 就用多少 if else，没人会知道哪天来的新需求，就把之前重构过的给打乱了。还是去面向 B 端的企业好点，至少不像 C 端这样需求多变

[conanjun]

纯粹个人看法：这个问题其实不仅仅在代码领域出现，其他领域也有。例如：刚刚发布的新显卡爆出频繁黑屏事件，刚刚发售的新手机爆出屏幕问题事件、电池事件，刚刚发售的游戏因为 bug 多获得各种差评，等等。 如今即使是国际大厂也避免不了出现这种问题。 我觉得问题就在于当今社会真是一个快节奏社会。一个产品想存活就要尽量压缩成本，尤其是时间成本。比别人慢一步就会失去很多市场。