标签：多参数 飞机 设计图 修改 现象 返回 ash 产品设计 参数
（没有黑任何人的意思，不喜勿喷，纯属娱乐）
在实际开发中，普遍会遇到的一个问题：改需求。
这是不可避免的，原因有很多，大致总结一下：
场景①：因为人的想法是经常变的，表现到客户或产品经理或测试甚至或别的开发上。打个比方：设计了一套UI，开发照着做了，结果以上人员第二天就觉得UI不好看了，改！但是服务（后台接口）不需要改，但，前端，改。
场景②：因为不同的人对事物的理解不同，反应到开发上，就是前后台甚至UI甚至产品经理甚至客户等对需求的理解不一样。打个比方：客户想要一只老虎，产品经理或UI觉得像猫，于是让UI画了一只猫；后台觉得就是个能吃喝拉撒的动物，于是写了个动物；而前端就是要用给的动物的接口和UI画的猫的样子，做一只老虎出来。但是老虎的叫声和猫的不一样，甚至动物里都没设计叫声的属性，那么现在就会有几种结果：后台改、前台改，不按UI做，或者不让它叫。至于最终是哪种结果，就要看公司团队文化和沟通过程了。
最常见的也就是上边两种原因了，当然还有很多别的，比如，技术瓶颈，版本更新和功能完善，产品设计时考虑不够全面，时间因素，甚至是外界因素等等。
上边说了那么多改需求的原因分析，现在要说的一个是改需求的现象，一个是改bug方面。
就拿需求来说，一开始如果设计的不好，比如设计没有留有扩展和修改的余地，做完一个版本之后，如果想扩展，那么就会花费很大的精力，也很容易出现很多的bug。就拿工作中的现象来说，现在有个需求，要在一条河上架一座桥，让人可以从河的这边到达那边。
设计者（某某某）的想法：找一根木板，河宽乘以人的肩宽（后台接口设计），搭在河两岸，搞定（想做的简单）。于是前端找了两个合适的位置，用后台给的木板，搭在上边。
好，此时需求做完了，人可以在木板上边走。版本一完成。
用了一段时间，客户想要可以双向通行，那么此时木板的宽度就明显不够了，于是后台觉得，如果继续使用木板，也不是不能达到目标，比如，两个人相向走到一起的时候，让他们侧着走，然后再正常走。于是，前端就要去改了，加个条件，两人重合的时候，侧着走，2个以上，等待。
又过了一段时间，用户想让车也可以过去，那么此时木板就更不行了，于是要把木板加宽加厚，甚至可以考虑建造真正意义上的大桥。但是桥的构造明显比一块木板复杂的多，于是开始全部都改。后台给了原料，UI给了设计图纸，前端开始搭桥。（真正的造桥我也不懂，这里纯靠想象的）首先要考虑好，都有哪些要素，比如，要桥面，要桥墩，要栏杆等等。原料还没来的时候，前端开始搭架子，把各种需要的都搭好了，想象着后台会给你桥墩、桥面、石板、栏杆等等。然而等到接口写好了，原料到了，才发现原料（接口）只有水泥。理由是，前端可以用水泥造桥墩、栏杆等。于是。。。最后造完了，发现水泥不好用，经常挂掉，规格参数又乱，经常有气泡（返回null），需要前端自己去用别的材料（接口）补（查），于是就经常出现，一个模块、页面动不动就需要查十几个接口，然后数据进行各种前端处理（动态桥面有木有，动态补坑有木有）。
桥的使用过程中，一旦出现问题，由于原料（接口）只有水泥，所以都是要前端去改结构，只靠改结构不行的，就后端改改水泥的配比（接口的参数），然后前端照着新的配比水泥去重新修补。
这个例子可能有点夸张，但事实确实如此。而到测试手里之后呢，就需要测桥了。比如，测一测飞机大炮能不能过，测一测坦克航母能不能上（夸张了，哈哈）。比如，试一试走边缘会不会翻车。前端虽然做了很多栏杆（各种条件各种场景的兼容），而一旦翻车呢，比如，栏杆中间缝隙大了的话，小玩具车翻车了。而此时与后台没直接关系呢，因为就是一个提供水泥的。于是前端去加密栏杆。飞机大炮坦克航母的马力足，撞烂水泥翻车了，后台顶多就是给些更坚固的水泥，然后前端去加固栏杆。走着走着迷路了，前端去加指路牌，走着走着找不着北了（参数获取不到），前端去造个指南针（用别的接口查），甚至还想要飞机场。。。。。。
甚至还有场景：后台给了N条路，比如，人走人路，车走的路，飞机大炮坦克车走的路。然后前端去判断是人还是车还是啥来走不同的路。虽然目的都是一样，过河。但是呢，和设计确完全不一样。设计就一座桥（一个页面），而有N条路，但是桥该有的桥墩、栏杆等等（参数）都没有，照着图纸做吧——没有材料，所以很多地方都没有，到最后丑的要死。照着接口做吧，把很多参数去掉，最后页面还是丑的要死。次数的后台不是应该把重点放在各个参数上，而不应该是给一堆没有任何意义的接口吗？
而想要避免这种现象，其实也不难啊：后台多给几种材料（接口参数丰富些完善些，别动不动就是null，能不给的就绝不给那种），设计的时候考虑全面些（别只想着我就不改）
……
啊，感想太多了，做下总结。
说了这么多，我想表达的意思就是，很多时候，不能只想着怎么简单怎么做，而是要从设计开始就考虑全面些。这些和个人的经验有直接的关系，这就是经验比较充足的开发做出来的东西普遍比应届毕业生做的东西好用的原因；
其次就是，在配合方面，大家不能只想着自己怎么简单怎么来，不顾别人的死活。这个一方面是沟通，一方面是人的工作习惯，一方面是企业和团队文化氛围。比如有些人已经老咸鱼惯了，怎么沟通都没用，甚至跟领导说也不改。这就不好了。
标签：多参数 飞机 设计图 修改 现象 返回 ash 产品设计 参数
原文地址：https://www.cnblogs.com/ljwsyt/p/11287747.html
