有点被折磨了。。。
问题抽象化大概是这样的，老板说设计个 o(n)的算法，马上要，根据现有数据规模，勉强实现出来了
老板看了后发现很满意，然后就让用这个就实现一个 100 倍现有数据的另一个功能，马上要。告诉他实现不了，然后就开始说怎么不行，这个都可以，那个差不多也可以之类的
不知道大家遇到过这种情况没有，上述问题就是当应急实现了个东西后，马上又要根据这个拓展，而这个应急写出来的本身不具有任何拓展功能，但是提需求的人不管，认为既然差不多，就应该马上实现。。。每次遇到这种问题都想 ko 他，但是每次提问题的人都是惹不起的(位置)。。。
倘若你举例，你要在原有接口做处理，
你也可以在逻辑层继承出去把“屎”包好，就不会影响到你原有的。
再恶心一点，你就加多一个参数，让外部自动传给你，或者你写个自动去判断，把逻辑分开。
代码的层次划分就很重要。
我们的一个前端 app，6 个月，大的布局变动至少 4 次，更别提小的了
所以我们的代码，里面充斥着各种 todo
一种思维模式吧。
这位大佬之前是生物专业的，后来高的计算机。他常说：“计算机什么的，比生物简单太多了”
所以不要看不起外包了
能独立从头开发的外包都有系统设计和规划以及预测新需求大方向的能力
[doge]
1 的弊端是不好掌握度，很容易过度设计。导致开销大不划算。软件工程是工程学，讲究最大性价比解决问题。
2 的弊端是对人要求高，需要你对当前业务这个行业有很强的理解。而且客户或者产品设计者的水平是参差不齐的。有可能你预测客户、产品要做个航天飞机，最不济也得是火箭，结果客户、产品经理最终需要一个窜天猴。
不考虑性能的话，光业务功能有时候能实现这种，基本上出于对业务方向的预测，但要求变化合理，并不能做到怎么变化都能达到这点。基本押错了要不就算过度设计啰嗦难懂，要不更惨给以后埋坑。
不过每个人都会碰到过需求变化听起来很简单，做起来特别难的时候。这个就是设计问题，其实是可以避免的。
对于任何业务都有个核心复杂度，这个就是“没有银弹”的基础，对业务老老实实地，不走弯路地建模是一个软下限，改需求的时候要也有这么个软下限。如果这个软下限没那么低，但也随随便便就改好了，不然是之前押对方向，不然就是抄近路。
抄近路的设计就是突破这个软下限的（用算法做类比就像基数排序，能突破常规排序下限但是加新数据类型就要重写），但是可能是隐患。
但是更多的是有问题的设计，就是既没达到省事的目的，最后还把自己坑了改起来的工作量大幅超过软下限。这个理论上是一定程度可以避免的。
总的来说，真正的大佬：
1. 并不能任何时候随便改改就合适
2. 对业务有熟悉，经常能押对方向，之所以能随便加上的原因是之前就已经对这个因素建模了
3. 不给自己添没意义的乱，即使抄近道也要有价值
不合理吗 ？ 有多离谱呢？是异常离谱
应该。。。有吧
这种大牛的高度 您觉着给开多少工资合适
我觉着请这种大牛 不是钱不钱的事了
外包项目经常这样变，甚至整个业务流程都能变，懒得推翻原有系统，直接基于原有逻辑调整一下就完事。