劝你放弃纸上谈兵

引言

纸上谈兵，汉语成语，拼音是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 远程调用失败

当然，这个问题的解决过程也是很顺畅，因为网上很多人（估计大部分都是新手）都遇到了这个坑

小结

实际上，上面的这些问题都不是特别难的问题，都是我们平时开发遇到的一些遇到了随便查一下就知道的问题。但是这些问题足以证明自己是否真真正正的做过这些项目

回到正题，如果仍旧是纸上谈兵，不去切实的自己动手尝试一遍，那么这个项目又怎么愿意写在简历上呢？我们常说见微知著，其实我认为往往就是这些地方就可以见微知著