给服务端小白的一些建议

一、技术

看视频教程入门（B站即可），看书深入，最重要的是实践。

二、怎么提问

很多新人不知道怎么提问，问了太简单的问题怕被人鄙视，更重要的是不知道问题是否简单。

其实也没有那么严格，程序员还是很愿意帮人解决问题的，可以装一下13并且很有成就感。

值得注意的是：

1. 这个问题百度、谷歌是否有答案，对着教程你试过没有，中间是遇到什么坎导致你无法解决。
2. 这个问题你是怎么想的，多多少少你会有思路和想法，有了这个基础，“请教”就变成了“沟通”。
3. 实在无法解决，请精简你的问题，精准描述，不要模糊、笼统，这样别人很难帮你。
4. 如果他人帮了你，请说谢谢，能夸一下就更好了。至于物质上的报答看个人情况。
5. 多总结，不要问重复的、类似的问题，答案不重要，重要的是解决的思路。
6. 最好将你的问题、解决方案发布到网上，比如博客，这样不仅能帮到更多人，还能方便自己复盘、回顾。

最后，有问题一定一定不要闷着！！

领导最怕的不是你有问题，哪怕很基础的问题，只要影响了你的进度，比如卡了一个小时都没解决，就去寻求帮助，不要等最后领导来问题进度的时候，你再把问题抛出来，然后说没完成。切记切记！！

三、思维

客户端往往是页面驱动，即一个页面需要哪些东西，怎么优化，跳转逻辑、层级逻辑等等。

服务端更多的是数据驱动，首先设计表，然后根据页面返回数据。现在有了领域设计，但是小白还是先放放吧。

数据

从MySQL开始学最好，首先是基本的SQL语句，最好能自己针对业务设计表，怎么优化结构、优化查询，这个可以说是服务端的基本功。

其次是缓存，先看看redis吧，然后思考下什么时候该用缓存，什么时候过期，用什么结构，怎么维护数据一致性。这个没有标准答案，重点是结合业务。

交互

怎么将数据和页面结合起来，怎么返回字段更合理，怎么减少客户端工作量的时候缓解服务端的压力：

• 并行：只是要求快，没有时序要求，可以并行工作而不是串行。
• 队列：对于有时序要求的，可以用队列排序处理。
• 异步：客户端不是立刻需要这个数据的，可以先接口返回然后自己慢慢处理。

并发

可以说是服务端的一生之敌。常用的解决方案就是两种：

• 加锁：简单粗暴但是影响效率。
• 队列：将所有请求顺序化，代码比较复杂，但是逻辑清晰合理。

四、编码（重点）

前面的说实话，干一段时间，跟几个项目基本就有体会了，但是编码，有的人可能开始就很优秀，有的人一辈子都写的很稀烂，原因就在于最开始的习惯不一样，我希望更多小白能看到。

1. 先想，用80%的时间去想、去设计，然后再写。
2. 代码风格因人而异，但是能抽象尽量抽象，不要一个函数梭哈到底。（没bug > 好维护 > 花里胡哨全是bug）
3. 提交之前一定要多看看，服务端的代码往往是牵一发而动全身，而且服务端有问题往往就是大问题，所以要反复思考会不会影响其他模块？能不能兼容，他人调用会不会崩溃？会不会有效率问题？数据量大了会不会有问题？请求量大了会不会有问题？
4. 设计的时候要方便测试，比如按天结算的按小时、分钟结算。写的时候要写单元测试。写完了要自己先过一下再发测。
5. 上线前一定要留预案。最坏的情况是什么？万一发生了我怎么办？线上有bug我要怎么调试，怎么查？如果崩了我有没有planB?
6. 不管是编码中，还是线上有问题，都要记得复盘，这很重要。不要在乎是谁的问题，要好好思考怎么避免，万一出现了怎么修复。
7. 如果有bug，尤其是线上bug，一定要找到确凿的证据（日志+复现）再改。如果重大问题，及时回滚；如果容忍线上偶发，拼命加日志，抓到了再改。千万不要觉得是某个问题就改或者打补丁！ 这就像你去看医生，如果医生看都没看就给你开药要你做手术，你怎么想？服务端改代码一定要像手术刀，稳准狠！

这些习惯，如果是小白，希望你从一开始就养成这样的认知，就觉得理应如此，我相信你能受益匪浅。

还有其他问题，欢迎评论区一起讨论。