这是我的第一篇有关于工作中遇到的技术问题的周期性回顾，所以本期的技术回顾主要是总结长期以来的经历，为以后的技术回顾开一个好头。
来公司工作了快半年了，最近我从客户端开发转成了后台开发。这是我希望的，但其实不是我要求的。因为个人感觉，在中国科技行业目前的职业生涯规划中，后台开发可以探索的东西会稍微多一些，接触问题的规模也会大很多。其实客户端也大有可为，我的第一个比较成熟的开源项目GpgFrontend就是一个客户端项目。我在其中投入了大量的时间，解决了大量的问题。尤其是编译问题、平台兼容性问题、稳定性问题。其探索的深度，问题的难度，都是不小的。我目前觉得，为什么客户端和后端开发会被分出高下来，那是因为心没静下来，总想着往上爬。另外，对于技术的追求本来无所谓客户端、前端或者后台，他们背后的技术思想本质上是通用的，但是目前将职业看得太重，反而以职业分工来将技术划分地分明。我觉得这是不好的，所以虽然我是目前是一个后台开发，但我绝不能认为我仅仅是个后台开发，其他技术看都不看，学都不学，自己把自己的思维框起来。
现在职位转成了后台开发，我反而不知道该怎么做了。后台开发，我目前记得，我自己写过的最早的后台项目，是我15岁的时候用Nodejs写的一个天文论坛 Stelescope 。用了当时流行的Express框架。现在我还记得，当时第一次接触MongoDB、登录登出的状态保存、异步回调等等技术概念。我印象最深的是异步回调，当时用了很久才理解。因为我当时连进程、线程的基本概念都搞得不是很清楚，更别说什么异步回调和闭包了。那时，网上还在争论Nodejs和PHP孰优孰劣，Nodejs到底适合什么场景，然后就是异步回调和多进程并行孰优孰劣等等。当时记得异步回调不能被阻塞，如果遇到阻塞操作会使用一种非阻塞的API，这种API能够立即返回，将阻塞操作放到一边处理，主线程依然能够继续处理后续的代码。等阻塞操作处理完了，就会通知主线程执行回调函数来处理阻塞操作的结果。
后续，我还接触了Python的后台开发，写了一个简单的班级学业考勤管理系统（SP）。在这里，我接触了MVC的思想，我理解为模型、视图和控制器。这是一种重要的思想，那时候前端的概念还不是很明细，前后端分离还不是主流思想。在当时，服务器负责动态页面的生成，由请求触发控制器做出响应。控制器基于模型进行计算，并最终通过模板引擎将模型渲染成页面，而后页面被返回到用户浏览器。就这么一个过程。记得当时，会在服务端定义很多模板，模板里选一些地方镂空，待会存放数据。或者是定义一个小的卡片控件，放在for语句中，待会用模板引擎生成出很多卡片出来。在当时，我作为后台开发要考虑方方面面，包括页面漂不漂亮，数据安全，响应快不快等等。
然后大一下开始，我就接触了Spring框架，具体用的就是SpringBoot。这个时候，才真正了解到了关系型数据库。原来我对于关系型数据库的理解，仅仅是会安装，配置。记得很深刻，当时接触到了前后端分离的思想，觉得这是个好东西。拿出来和王老师讨论，说我们的全员育人管理系统用前后端分离最好。王老师非常开明，和我聊了很多，同意了我的方案。前后端分离，顾名思义，就是将动态页面的渲染放到用户那边，服务器仅仅负责数据的处理和存储。这样有助于分工和解耦，虽然当时网上也有很多质疑的声音，我还是觉得这是趋势。当时害痴迷于一种RestfulAPI的接口规范，觉得如果这样做我们连写项目文档也可以免了。但是现实很骨感，在实践中对于一些复杂的情况就难以保持RestfulAPI的风格。
通过与SpringBoot打交道，我学会了很多有关后台的东西，目前我也在用这些原来的经验。我在大学本科生涯中，写了很多的SpringBoot项目。到现在，我进了公司发现部门的技术栈就是Java，新的项目用的框架都是SpringBoot，反倒用上了。虽然说我当时很厌恶Java，觉得它臃肿与繁琐，包括现在也没有什么好感，但是Java的生态确实是很强大的，想找个什么组件很容易，而且Java组件都是成熟的、良好维护的并且文档齐全。Java技术栈对于面向生产的后台项目来说，确实是个省心、好找工作的技术栈。
在公司工作半年，其实算上实习都快一年了。总的来说，对于后台这块，我一直在捣鼓优化、缓存、线程这些东西。每天都在分析各种告警，有些是业务上的，有些是技术上问题。对于业务上的问题，只能好好地了解背景。对于技术上的问题，需要扩展自己的知识面，静下心来研究。包括一些目前自己感觉难以解决的问题，比如说在容器化部署过程中，总有一些容器存在偶发的超时问题，一直不能确定到底是容器的问题还是后台应用的问题。我现在思考，这一块需要一些更加深入的知识，比如说CPU、内存、网络的虚拟化问题。
今天先这样吧，还有点其他事情要做。
