今天与后端在调试接口，在过程中发现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。