因为工作需要，最近开始接触后端开发，主要是自己的主要技能客户端开发在公司已经被边缘化了，没办法，得重新找点活儿干，正好后端有同事离职，人力有点紧张，所以给了客户端同事一些转后端的机会。

公司的后端技术栈主要是 Java+Spring+Mybatis，我对这三者都有了解，但不熟，而且也没有从头到尾开发过项目，刚开始接需求的时候还是挺慌的。

作为客户端开发，之前日常和后端对接主要就是对接口。我记得很久以前我刚入行的时候，觉得后端是一项很高深的工作，现在再看的话，当然基本已经祛魅了，不过还是对后端的一些实现比较感兴趣。

后端的开发本质上是数据处理。处理用户传上来的数据，同时下发一些客户需要的数据。在 Web2 时代，数据是中心化存储在服务器上的，现在流行的 Web3 则是将数据分布存储在所有备份的电脑上。这意味着，你发的信息永远不会被某个中心化服务器删除。我自己还是挺期待 Web3 发展的，这意味着用户对自己的数据真正有了使用的权力。不够现在 Web3 发展的很慢，而且很多技术应用在金融领域里，涉及一些不太合理的行当，给人观感不太好。

后端开发一个重要的感受就是，有点类似刷算法题。因为都是各种数据的处理，也不涉及界面，如果碰到复杂一点的需求，在处理数据的过程中思考应该使用哪种数据结构，这个思考过程和刷算法题真的很类似。虽然客户端也有类似的需求，但相对而言，还是少。所以我也明白为什么后端的面试会面很多比较多的算法题（卷啊）。

具体说说我接的第一个后端需求：从第三方平台获取数据，然后将拿回来的数据和我们平台的用户数据进行匹配，将两个平台的数据聚合起来，返回给后台展示。

听起来似乎并不麻烦，不过开发过程确非常坎坷。

之前开发客户端的时候也接过第三方 SDK，通常都挺顺利，这次开发后端接第三方 SDK 的时候，发现对方接口文档和真实的接口返回值有挺大的出入，而且和对方客服沟通也比较费劲，这个过程挺磨人。

调试的过程也很费劲，因为第三方平台数据都是真实的用户数据，而我们日常调试是开发服，都是一些假数据，所以想要真实用户数据的话，需要在开发调试的时候将代码部署到预发服务器上，然后登录阿里云后台去看日志，因为是第一次接触，感觉看日志不像本地看日志那么方便。

接口的开发反而没有话太多的时间，就是各种数据结构操作，不过我这次实现具体逻辑的时候实现的不够简洁，很容易出问题，被后端同事指出来之后，优化才好。而且第一次写 Java 程序，调试的时候一堆空指针异常，有点类似 C 语言开发的感觉，因为 Objetive-C 语言里给 nil 发消息是不会抛异常的，Swift 就更别说了，引入了 Optional 可选类型后对 nil 的处理更优雅了。写 Java 感觉总是在担心可能出现的空对象，要不断的判空。

同时后端对一些校验要求的比较严格，防止客户端传过来一些异常数据，污染服务器数据存储，甚至造成安全隐患。这点也是和客户端开发有很大区别的，客户端拿后端数据如果出现问题，可以要求后端改，但是后端是不能这么要求客户端，毕竟谁都可能向服务器发请求。

最后开发完毕验收的时候，产品觉得响应速度很慢，所以又重新替换了第三方的请求接口优化了一版，我才直观体验到，原来客户端一个请求发到后端，后端可能需要发 N 多个请求才能将客户端需要的数据聚合在一起。而且这里涉及一个点是，尽量不要在 for 循环里发请求，会很慢（废话），我刚开始的时候因为没有这个意识，被同事指出来之后才改过来，而且也将原来的单个id的请求，替换成批量查询的请求，总之不能光完成逻辑，还要提升接口的响应速度。

磨了三天需求终于上线了，还是挺感慨的。就还是那句话，很多事情没有想的那么难，也没有想的那么简单，还是得小马过河，自己多去尝试才知道深浅。

客户端转后端有一个好处是，能从前端角度去进行接口设计，我们听完需求之后，基本上就能定出接口，而且也基本上大差不差。

开发语言层面其实也都差不多，来回也都是那些数据结构，只不过语法有一些不同，掌握数组，字典的一些基本操作语法，基本上就能处理很多场景了。不过 Java 和别的语言有很大的一点不同是，有很多的注解，有的注解并不是很明白，这也是以后学习的一个方向。

后端开发也给我提供了一个新的视野去审视之前的接口设计，我们作为客户端有的时候会抱怨，为什么后端的接口数据不给的更加舒服一点云云。但是后端也有后端的一些考虑，所以这次有了后端视野之后，以后制定接口规范可能会更加合理。

后端开发是有趣的体验，让我的工程师经历更加丰富，以后吹牛逼也有素材了，很好。不过也不能停止学习，后端的东西还有很多，这次开发只是接触了个皮毛，路漫漫其修远兮…

---

关注我的微信公众号，我在上面会分享我的日常所思所想。