如何避免项目越来越乱

[lagoon]

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

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

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

基本上的死循环是：

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

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

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

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

---

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

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

很无奈。

[brezp]

@taowen 看了 , 感觉不错

[mazai]

深有感触，当一个项目太过复杂以后，且没有文档与项目规范，不管是定位问题，还是改 bug，或是添加新功能，都困难无比

[hzw94]

和我们团队的目前状况差不多

[tesguest123]

两种方式，一，跑路。二，开新坑。业务一多不可避免。加个 if 下班完事。

[wunonglin]

建议参考 https://github.com/kelseyhightower/nocode

[leven87]

所以说码农连建筑工人都不如，建筑都是按照图纸作业，严格规范。代码想改哪都可以，天马行空

[pkupyx]

重构。太烂就重写 v2 。

[mamahaha]

既然是短时间内做完的项目，那整个推翻重做也没啥可惜的，做个参考就完了，何必做基础。
不花大力气重做证明公司通过实测不太看好这个项目，暂时不赔钱就留着养人，等赔钱了就放弃。

[nieboqiang]

你别把写代码当成一个神圣的事情，任何产品，系统都是有寿命的，过个几年就要准备重构了。

只要保证这几年内能用就行了，你修补的手艺再好，也不能解决业务性的问题，不能创造价值，有时候 ifelse 是最具有成本意义的写法。

任何事情都是有成本的，你做的又不是框架，只是提供服务而已，不需要考虑兼容性，大胆的写，然后大胆的重构就好了。