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

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

本文章由javascript技术分享原创和收集