一、技术
看视频教程入门（B站即可），看书深入，最重要的是实践。
二、怎么提问
很多新人不知道怎么提问，问了太简单的问题怕被人鄙视，更重要的是不知道问题是否简单。
其实也没有那么严格，程序员还是很愿意帮人解决问题的，可以装一下13并且很有成就感。
值得注意的是：
- 这个问题百度、谷歌是否有答案，对着教程你试过没有，中间是遇到什么坎导致你无法解决。
- 这个问题你是怎么想的，多多少少你会有思路和想法，有了这个基础，“请教”就变成了“沟通”。
- 实在无法解决，请精简你的问题，精准描述，不要模糊、笼统，这样别人很难帮你。
- 如果他人帮了你，请说谢谢，能夸一下就更好了。至于物质上的报答看个人情况。
- 多总结，不要问重复的、类似的问题，答案不重要，重要的是解决的思路。
- 最好将你的问题、解决方案发布到网上，比如博客，这样不仅能帮到更多人，还能方便自己复盘、回顾。
最后，有问题一定一定不要闷着！！
领导最怕的不是你有问题，哪怕很基础的问题，只要影响了你的进度，比如卡了一个小时都没解决，就去寻求帮助，不要等最后领导来问题进度的时候，你再把问题抛出来，然后说没完成。切记切记！！
三、思维
客户端往往是页面驱动，即一个页面需要哪些东西，怎么优化，跳转逻辑、层级逻辑等等。
服务端更多的是数据驱动，首先设计表，然后根据页面返回数据。现在有了领域设计，但是小白还是先放放吧。
数据
从MySQL开始学最好，首先是基本的SQL语句，最好能自己针对业务设计表，怎么优化结构、优化查询，这个可以说是服务端的基本功。
其次是缓存，先看看redis吧，然后思考下什么时候该用缓存，什么时候过期，用什么结构，怎么维护数据一致性。这个没有标准答案，重点是结合业务。
交互
怎么将数据和页面结合起来，怎么返回字段更合理，怎么减少客户端工作量的时候缓解服务端的压力：
- 并行：只是要求快，没有时序要求，可以并行工作而不是串行。
- 队列：对于有时序要求的，可以用队列排序处理。
- 异步：客户端不是立刻需要这个数据的，可以先接口返回然后自己慢慢处理。
并发
可以说是服务端的一生之敌。常用的解决方案就是两种：
- 加锁：简单粗暴但是影响效率。
- 队列：将所有请求顺序化，代码比较复杂，但是逻辑清晰合理。
四、编码（重点）
前面的说实话，干一段时间，跟几个项目基本就有体会了，但是编码，有的人可能开始就很优秀，有的人一辈子都写的很稀烂，原因就在于最开始的习惯不一样，我希望更多小白能看到。
- 先想，用80%的时间去想、去设计，然后再写。
- 代码风格因人而异，但是能抽象尽量抽象，不要一个函数梭哈到底。（没bug > 好维护 > 花里胡哨全是bug）
- 提交之前一定要多看看，服务端的代码往往是牵一发而动全身，而且服务端有问题往往就是大问题，所以要反复思考会不会影响其他模块？能不能兼容，他人调用会不会崩溃？会不会有效率问题？数据量大了会不会有问题？请求量大了会不会有问题？
- 设计的时候要方便测试，比如按天结算的按小时、分钟结算。写的时候要写单元测试。写完了要自己先过一下再发测。
- 上线前一定要留预案。最坏的情况是什么？万一发生了我怎么办？线上有bug我要怎么调试，怎么查？如果崩了我有没有planB?
- 不管是编码中，还是线上有问题，都要记得复盘，这很重要。不要在乎是谁的问题，要好好思考怎么避免，万一出现了怎么修复。
- 如果有bug，尤其是线上bug，一定要找到确凿的证据（日志+复现）再改。如果重大问题，及时回滚；如果容忍线上偶发，拼命加日志，抓到了再改。千万不要觉得是某个问题就改或者打补丁！ 这就像你去看医生，如果医生看都没看就给你开药要你做手术，你怎么想？服务端改代码一定要像手术刀，稳准狠！
这些习惯，如果是小白，希望你从一开始就养成这样的认知，就觉得理应如此，我相信你能受益匪浅。
还有其他问题，欢迎评论区一起讨论。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
