掘金昵称BUG有感: 我们应该怎么去开发

今天与后端在调试接口,在过程中发现node端需要嵌套三个java接口才能拿到所需的数据。 这种调用方式是很恶心的,于是找到java同学讲明这个接口是前置接口,会影响整体的加载性能。

后端同学: "业务如何,第三方如何,你们node端如何。(涉嫌公司业务,大概是这个意思)""

我表示很理解,虽然代码会写的很恶心但后端同学说的确实是实情。

但这就是业务。

为什么现在很多互联网产品都有很多线上问题

整完后,在掘金上摸了下鱼。

上班摸鱼
上班摸鱼.jpg

不知道是谁最先试出了这个掘金用户名过长的BUG,搞的吃瓜群众们班也不好好上了,连先帝创业未半...这种用户名都出来了。

那么为什么会出现这种问题?

面上看是接口未对昵称长度进行限制,导致一但绕过前端表单校验就可以填写数据库所允许的最大值。

但,我并不这么认为里子也是这样。

现在互联网产品都有一个通病,这个病就是一切以快为基调。

迭代周期能快不慢,虽然加需求但是不加时间成为常态。

测试人员是即要测试用例也要测试质量,但就是不给测试时间。

于是就如你所见,虽然互联网产品的主流程都是通的,但总是会找到那么几个404或者是500。

然而,这并不能说这不对。在快速迭代的市场中,十年磨一剑似乎在互联网行业只会是个笑话。

从2010年开始成为程序员,2011转前端开发至今已经十年了。 对待以上所事情的态度一直在变化着,从" shaX后端、shaX产品、shaX运营"到慢慢接受,再到理解。

由此也引申出一些对其它事情的看法,即然开始写了就一同写下来吧。

新技术要不要引入到已有的项目中

严格意义上讲,我是一个对新技术有一定抵触情绪的程序员,但时间久了以后又会中了真香理论。

比方说 扩展运算符...,第一次在项目中看到的时候一脸懵逼,了解后觉着无所谓,用多了真香啊。

但对新技术是一个态度,对把新技术引进已有的项目则还是另一个态度。

这些新技术与新语法,特别是像TypeScript这种改革性的技术一定要持慎重态度。 引入前需要确认是否做好重构的准备,需要充足的考虑这期间的人力消耗是否值当。

另外在引入前,需要确认自已是否已经对这套玩法足够熟悉。

任何以学习为目的,引入连自已都陌生的技术到项目中的行为都是不负责任的。

如果都没问题,引入后需要向协同开发人员进行同步。

关于上古代码的性能优化

有些项目,数据量大、页面复杂而且还带了几个动画,但就是加载快、交互流畅。

而有些项目,页面打开的同时风扇不吹上两下都觉着好像停电了。

风扇为什么会响?

那是风扇对上古代码的凝视。

那么对待上古代码的性能优化,我们又该如何下手呢?

网络上有很多文章在介绍formap,forEach的性能高出多少多少,说的有理有据。

心痒痒的去测试了下,别说还真是。

也有些上来就开始整webpack优化,上4上5上构建优化。 话说那文件打出来好几MB为单位的包,webpack表示也很无奈啊。

我认为理想的性能优化是有顺序的,这个顺序是基于改动与能效比为基调的:

  • 清理无用的资源文件
  • 公共的业务逻辑进行组件化、函数化
  • 整理常量文件,减少构建时的重复文本
  • 梳理逻辑,清理已经废弃的业务逻辑
  • 抽取函数式的工具类: 函数式编程在构建时可以很大程度的减少体积,并在抽取的过程中可以检验现有逻辑。

对于上古代码的优化,一定要注意能效比。

或者换个吃货的逻辑, 现在有一个果盘,有菠萝块有樱桃也有桃子和香蕉。

而你最喜欢的是菠萝,于是你首先把它挑出来放在了边上准备留在最后吃。

那么就洗洗手开吃吧,香蕉桃子扒拉扒拉。

等到还有樱桃和菠萝块时,你打了个饱嗝。

心想着,菠萝块明天再吃。

到了明天,你最喜欢的菠萝块坏掉了。

至于为什么要把菠萝切成块,完整的不更容易保存?这个得问下产品经理,平时需求下来的时候谁知道会不会把菠萝切成丝再放到果盘?

而我们的工作比起这更为复杂。

渐性优化,注重能效比。

对了,今天在使用公众号上传图片的时候也报了个500。

写在最后: 花了5年时候维护的跨框架表格组件: GridManager, 希望你来点个star。

推荐阅读更多精彩内容