劝你放弃纸上谈兵
引言
纸上谈兵,汉语成语,拼音是zhǐ shàng tán bīng,意思是指在纸面上谈论打仗。比喻空谈理论,不能解决实际问题。也比喻空谈不能成为现实。
WEB 开发发展到现在,各种优秀的框架以及丰富的网络资源,让 WEB 开发入门门槛降到了很低很低,但是并不是证明 WEB 开发没有门槛了,也不能证明 WEB 开发就没有难度了
最近在学校做项目,依稀能听到这种事情:老师给了一个XXX题目,甲同学看了看题目,思考了一下,觉得这个项目挺简单的,甚至有可能看不上这个简单的项目……说实话,以前我也是抱着这种心态,觉得老师给的那些项目又简单又 low,做出来也是浪费时间,没有什么太多意义
不过,后来在我做了一个“秒杀商城”的项目以后,我就开始认真对待每一个看似简单的项目了。为什么呢?
秒杀商城
讲实话,这个项目就是纯拿来练手,为了往简历上写项目经历的项目。但是我也是在这个项目里面遇到了很多很多的问题......
期初想到这个项目的时候,我就在想,网上一大堆电商项目,也有很多高并发的商城秒杀项目供我参考,那我做这个还不是简简单单么
然后,在我真正开始做这个项目的时候,我遇到了很多很多的没有预料的甚至见都没见过的问题,我想,假如我是面试官,我想要判断一个人是否真的做过这个项目,下面这些问题就够了
在使用消息队列的时候,前端如何判断消息是否正确消费
第一次接触消息队列的时候,因为消息队列没有返回值让我挺难受的。但是在做高并发,尤其是秒杀项目的时候,消息队列仍然是首选
那么如何解决前端判断消息是否消费呢(比如订单是否已经支付完成)?
其实这个问题的答案很简单,简单到我在第一次听到这个答案的时候都有点不敢相信:轮询(即设置一个周期定时器,一直调用接口进行查询)。当然,也可以用其他的方式,这种方式只是最简单最好理解的一种
前端JavaScript的Number型与Java的long型最大长度问题
遇到这个问题的时候是因为项目里面生成全局唯一 id 使用到了雪花算法,雪花算法生成的就是一个64位的唯一 id,正好就是 Java 的 long 型最大位数。也正是因为这个算法用到了64位数字,所以就会遇到与 JavaScript 的 Number 类型数字的最大长度问题了
我们先来输出一下 Java 和 JavaScript 的最大值
public class Main{
public static void main(String[] args) {
System.out.println(Long.MAX_VALUE);
}
}
// 9223372036854775807
// 0x7fffffffffffffffL
console.log(Number.MAX_VALUE)
// 1.7976931348623157e+308
通过上面两段代码可以最直观的看出来一个问题,Java 的 long 型最大值与 JavaScript 的 Number 最大值不一样
然后我们再看一下下面这个代码:
var x = 9223372036854775807;
console.log(x)
// 9223372036854776000
这里只是把 Java 的 long 型最大值在 JavaScript 中输出出来,结果是最后三位数字变为0,倒数第四位数字进行四舍五入了。那么在开发的时候肯定就会遇到问题
这个问题解决办法其实也很好理解,做过大数相加的那种算法题的应该都知道,那就是用字符串表示数字。这个问题的解决办法就是后端传这种 long 型数据的时候使用字符串就好了
feign远程调用问题
这个问题只会让习惯不好的同学遇到(比如我),因为我在传统的 spring boot 开发的时候,一般不会在RequestMapping
接口处写@RequestParam
注解,然后在我第一次使用 feign 的时候,我仍旧在服务生产者处不写@RequestParam
注解,结果导致 feign 远程调用失败
当然,这个问题的解决过程也是很顺畅,因为网上很多人(估计大部分都是新手)都遇到了这个坑
小结
实际上,上面的这些问题都不是特别难的问题,都是我们平时开发遇到的一些遇到了随便查一下就知道的问题。但是这些问题足以证明自己是否真真正正的做过这些项目
回到正题,如果仍旧是纸上谈兵,不去切实的自己动手尝试一遍,那么这个项目又怎么愿意写在简历上呢?我们常说见微知著,其实我认为往往就是这些地方就可以见微知著
来源:juejin.cn/post/7283438991473426467