聊聊小型商业项目，大型商业项目，小型个人项目这三种。

大型商业项目公司内各个部分分工明确，架构师写架构，开发开发，产品提需求，各司其职。
架构一般不会混乱，因为有专门的人负责，需求也会明确，如果甲方要改需求的话需要层层审核，层层撕逼，成本较高，所以一般会决定好再处理。

小型商业项目不存在公司啦，甚至两个人就是一个开发团队。
立项的时候，只要个人水平够，自然会写出比较好的架构，形成屎山代码的原因绝对是甲方无条件改需求。
当你辛辛苦苦为项目搭建了架构，规范命名，规范代码格式，优化处理逻辑，减少容易代码，这些在甲方面前啥也不是。
甲方需求的是，成果，速度，你需要在短时间内满足他需求就够了，代码是不是屎山跟他们没有关系。
当一个程序员写好架构后，甲方改一个需求，程序员就要改架构，真的痛苦，有时候不如当时就不设计。
有人会问了，你当时写架构的就不能把甲方的需求考虑进去，这种就是废话，程序开发最忌过度设计，你永远无法知道甲方有什么奇奇怪怪的需求。
举个例子，如果我已知一个分支只有三种或一下可能性，我绝对不会把分支抽象出来然后做遍历，过度设计折磨自己，也折磨后续开发
刚开始接手这个项目的时候我也把他当作亲儿子看待，就算他很乱，很蠢，但我也慢慢修改，最终形成一个能看的架构，完成需求后交给甲方。
然后甲方：这个地方，改一下。看似只改一地方，程序设计中就是牵一发动全身。重新设计架构不如当时就不写架构。
还有一点就是代码冗余，注释不删，我个人对多余注释的代码，没有删除的习惯，但是这个习惯居然帮我省了不少时间，因为甲方经常把需求改回来。
但是对于甲方有错么，并没啥错，我提需求你改。
这就涉及到商业逻辑和程序员逻辑了。
小项目只能相互体谅吧，我不嫌你改需求，你也别嫌弃我公司没名气。

小型个人项目是自己抽空写的项目，一般是程序员自己的心血。
自己改需求的话也会斟酌是否有必要，而且刚开始设计的时候，自己对后续发展有也有数