gopher china是go语言实践的线下分享，旨在促进go语言在国内的发展。今年本人有机会参加了一次。主讲的工程师来自于滴滴、知乎、哔哩哔哩等互联网公司。这里结合个人的工作经验谈谈我的感悟。

1.着眼于细节

我以前不管写代码还是设计表结构，并没有深入地考虑一些细节，比如表的命名是否能自释义、字段含义是否与别人的认知有偏差、代码是否易于理解、执行顺序是否直观、抽象是否恰当。这样或多或少挖了一些坑，比如多个逻辑处理有少许相似之处，就强行写成一段代码，这样虽然可能减少了部分代码量，但是非常不利于后期的维护和扩展。
本次gopher china有工程师分享了一些代码，这些代码有的其实是很简单的，但是重要的是为什么这么做。举个例子，redis的操作随便找个第三方库就可以实现，但是不建议在业务代码中直接引用redis第三方库，最好再引入一层中间层，业务代码调用中间层，中间层调用redis第三方库，这个中间层可以是一个接口，抽象出最基本的redis操作即可。其实不加中间层也可以实现业务功能，但是仔细思考，如果我们需要hack下redis的读写操作(不要以为用不到)，修改第三库当然是一种解决方案，但不是最佳方案，可能还会带来一些问题，将hack的代码侵入到业务代码显然也不合适，这时中间层的作用就体现出来了。再细想下，如果底层redis的第三方库更换了，或者redis服务本身升级了(新版的总是会在性能方面有优化，并且还引入了一些新的特性)，第三库的协议不能支持最新协议(这里是举个例子，一般而言都会向下兼容，但是新的特性第三方库就很可能就不支持了)，那么就面临着底层驱动库的更换，如果不引入中间层，业务代码可能需要大面积的改动，有中间层，就可以在业务代码无感知的情况下完成替换。我工作工程中也遇到了类似的例子，当时情况是需要对memcached实例做迁移，考虑缓存预热的问题，需要对新实例进行数据写入，当时并没有合适的数据迁移方案，所以同事采用了双写的方案。如果没有中间这一层，想要优雅地解决memcached双写的问题是比较难的。这个事是我同事操作的，你当然也可以从中学习点东西。
上述的例子中实现的代码确实是很简单的，简单到我们直接就忽略了，拿来就用，但是背后的细节慢慢咀嚼，总会有一些味道的。本次gopher china很多工程师都分享了一些代码的细节，从代码实现难易程度来讲，拿来面试可能都不够格，但是这里面的细节我们需要关注，为什么这么做，可以避免什么问题，都是值得借鉴学习的。

2.基础很重要

操作系统、网络、算法、计算机语言这些都要了解一点，这样当bug来临时才不会感觉到无从下手，另外一方面当需要对程序进行性能优化时可以准确地定位瓶颈。
gopher china 有位探探的工程师分享了他们技术团队对minio的实践，讲述了如何搭建minio服务，完成对小图片存储性能的优化。在实践过程中遇到了一些问题，测试环境与线上环境的性能差异较大，测试环境比较完成，上了正式环境rt翻倍，是什么造成这种差异的？持久化存储服务和磁盘读写相关，磁盘读写又和os cache相关，是不是测试环境下的os cache命中率非常高，但是生产环境的命中率比较低？还是测试环境的磁盘读写较快，那么是不是测试环境中是顺序读写，生产环境是随机读写，磁盘都是ssd吗？这些都是可能导致差异的点，了解操作系统，可以让自己站在更高的角度看待这个问题。
面试是比较注重基础的，所以有面试造航母，工作拧螺丝一说。业务实现层面可能不需要太多的基础知识，但是了解下总是有好处的。

3.完善知识体系

后端工程的知识体系涉及很多，比如数据库、redis、缓存、队列、搜索等等，尽可能都去深入了解一下，并且需要了解这些技术是为了解决什么问题。目前为止我还未深入接触过微服务架构、k8s，这些事实上已经成为部分互联网公司技术体系重要的一部分，本次gopher china也有好几场在谈微服务架构。
不管何种技术架构，上述提到的基本都会在互联网公司用到，所以学会这些，到哪都是通用的。语言方面需要深入掌握一门，语言与语言之间的差异最好还是能多了解下，尝试用不同语言实现相同的一段代码。框架方面也需要了解一些业界常用的。