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