今天与后端在调试接口，在过程中发现node端需要嵌套三个java接口才能拿到所需的数据。 这种调用方式是很恶心的，于是找到java同学讲明这个接口是前置接口，会影响整体的加载性能。
后端同学: "业务如何，第三方如何，你们node端如何。(涉嫌公司业务，大概是这个意思)""
我表示很理解，虽然代码会写的很恶心但后端同学说的确实是实情。
但这就是业务。
为什么现在很多互联网产品都有很多线上问题
整完后，在掘金上摸了下鱼。
那么为什么会出现这种问题？
面上看是接口未对昵称长度进行限制，导致一但绕过前端表单校验就可以填写数据库所允许的最大值。
但，我并不这么认为里子也是这样。
现在互联网产品都有一个通病，这个病就是一切以快为基调。
迭代周期能快不慢，虽然加需求但是不加时间成为常态。
测试人员是即要测试用例也要测试质量，但就是不给测试时间。
于是就如你所见，虽然互联网产品的主流程都是通的，但总是会找到那么几个404或者是500。
然而，这并不能说这不对。在快速迭代的市场中，十年磨一剑似乎在互联网行业只会是个笑话。
从2010年开始成为程序员，2011转前端开发至今已经十年了。 对待以上所事情的态度一直在变化着，从" shaX后端、shaX产品、shaX运营"到慢慢接受，再到理解。
由此也引申出一些对其它事情的看法，即然开始写了就一同写下来吧。
新技术要不要引入到已有的项目中
严格意义上讲，我是一个对新技术有一定抵触情绪的程序员，但时间久了以后又会中了真香理论。
比方说 扩展运算符...，第一次在项目中看到的时候一脸懵逼，了解后觉着无所谓，用多了真香啊。
但对新技术是一个态度，对把新技术引进已有的项目则还是另一个态度。
这些新技术与新语法，特别是像TypeScript这种改革性的技术一定要持慎重态度。
引入前需要确认是否做好重构的准备，需要充足的考虑这期间的人力消耗是否值当。
另外在引入前，需要确认自已是否已经对这套玩法足够熟悉。
任何以学习为目的，引入连自已都陌生的技术到项目中的行为都是不负责任的。
如果都没问题，引入后需要向协同开发人员进行同步。
关于上古代码的性能优化
有些项目，数据量大、页面复杂而且还带了几个动画，但就是加载快、交互流畅。
而有些项目，页面打开的同时风扇不吹上两下都觉着好像停电了。
风扇为什么会响？
那是风扇对上古代码的凝视。
那么对待上古代码的性能优化，我们又该如何下手呢？
网络上有很多文章在介绍for比map,forEach的性能高出多少多少，说的有理有据。
心痒痒的去测试了下，别说还真是。
也有些上来就开始整webpack优化，上4上5上构建优化。 话说那文件打出来好几MB为单位的包，webpack表示也很无奈啊。
我认为理想的性能优化是有顺序的，这个顺序是基于改动与能效比为基调的:
- 清理无用的资源文件
- 公共的业务逻辑进行组件化、函数化
- 整理常量文件，减少构建时的重复文本
- 梳理逻辑，清理已经废弃的业务逻辑
- 抽取函数式的工具类: 函数式编程在构建时可以很大程度的减少体积，并在抽取的过程中可以检验现有逻辑。
对于上古代码的优化，一定要注意能效比。
或者换个吃货的逻辑, 现在有一个果盘，有菠萝块有樱桃也有桃子和香蕉。
而你最喜欢的是菠萝，于是你首先把它挑出来放在了边上准备留在最后吃。
那么就洗洗手开吃吧，香蕉桃子扒拉扒拉。
等到还有樱桃和菠萝块时，你打了个饱嗝。
心想着，菠萝块明天再吃。
到了明天，你最喜欢的菠萝块坏掉了。
至于为什么要把菠萝切成块，完整的不更容易保存？这个得问下产品经理，平时需求下来的时候谁知道会不会把菠萝切成丝再放到果盘？
而我们的工作比起这更为复杂。
渐性优化，注重能效比。
对了，今天在使用公众号上传图片的时候也报了个500。
写在最后: 花了5年时候维护的跨框架表格组件: GridManager, 希望你来点个star。
