如何避免项目越来越乱

[lagoon]

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

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

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

基本上的死循环是：

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

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

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

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

---

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

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

很无奈。

[ychost]

把自己那份代码搞好，别人代码看不惯不要动，最多写个 adpater 包装一下

[wupher]

时时勤拂拭 勿使惹尘埃

[byte10]

@yule111222 领域驱动设计，一般人搞不了， 太难了，想的东西 比写的东西多

[forYou]

几乎所有的初创团队都有这个问题

[xingguang]

看看人月神话就懂了，所有这些都是无法避免的。除非找到外科手术团队模式的开发团队。

[dany813]

没事就小范围重构吧，小步快走

[jsnjfz]

趁早走人，公司迟早要完，只顾需求实现不管底层基础的并且说不通的都是垃圾。反正亏的不是你的钱，功能明天就要，钱明天就亏

[Terry05]

歪个楼，大家有没有好用的 code review 工具

[halk]

@Terry05 gitlab 等自带的就挺好用
关键是人和流程，不是工具

[jsjgjbzhang]

基于时间和成本考虑，一切都不是问题

[1534853288]

@hhyyd 有道理

[micean]

一个卡车公司的销售做不出业绩，往往会从自己身上找原因
一个互联网公司的市场做不出业绩，往往会从产品上找原因
机器产出是固定，而人力产出却是弹性的，所以脑力密集行业就是一个天生压榨自己的行业
所以需要一个懂得做市场的人才和一个懂得管项目的人才，有长远的规划，才能破这个局
而不是一周做个玩意儿，挨个问“您要不要？”

[th00000]

当然可以避免, 怎么做, 参考大型开源项目的做法
你见过 JDK 推倒重来的吗
你见过 Linux 推倒重来的吗
人家是怎么保证项目代码质量的,
无非就是严格的代码质量约束, 严格的 code review

[Mithril]

@th00000 当你占领市场以后当然可以对需求说不，体量没那么大的话自然是用户要啥你就得改出来啥。
你看.NET Core 对 Apple M1 支持的晚点都有人喷不积极，这还是体量相当大的开源项目了。

[new123]

当有一天 bug 修改的进度和修复进度，远远超出领导的忍受阈值时，领导会问你如何改进，这时候重构才有它的意义。

[yule111222]

@byte10 也没那么难，就算不用 DDD，需求一样要分析的，面向对象设计一样要做的，这只是提供了一套方法论教你怎么更好的做

[charlie21]

@Mithril
Surface Pro X 是 ARM 架构，微软的优先级是 先让 自家 SDK 支持 自家的 ARM 设备、再让 自家 SDK 支持别家的 ARM 设备。所以 喷吧 随便喷，有人理算微软输

[byte10]

@yule111222 不难的话，全世界都用 DDD 了，面向对象编程 本来就难以理解，构建模型一般小朋友 不好理解。还是面向过程写的快，清晰。所以 DDD 才流行不起来。不过最近微服务把它 整热了一遍，未来还得凉。起不来的。

[zypy333]

我觉得看技术 leader,选择什么样的架构,怎么安排开发计划,如何砍掉不必要的需求,如何保证代码规范的执行

[taowen]

可以参考一下 https://github.com/taowen/modularization-examples